Talk:C++/Archive 10

Archive 5

←

Archive 8

Archive 9

Archive 10

Archive 11

Archive 12

"Bloated" and "complicated"

I've found and added a nice reference for the existing wording in the article from a Niklaus Wirth's quote:

C++ is a language that was designed to cater to everybody’s perceived needs. As a result, the language and even more so its implementations have become monstrously complex and bulky, difficult to understand, and likely to contain errors for ever.[1]

However, the problem is that from the article text it appears as if Stroustrup refutes this:

I have even seen the C++ version of the 'hello world' program smaller than the C version.

However, he doesn't: Wirth - as well as most C++ critics, presumably - is talking about the language and its implementation, and not about the resulting executables. GregorB (talk) 01:07, 8 August 2009 (UTC)

The problem with this quote is that it is extremely subjective and inaccurate. Take the bit about errors: While bugs in e.g. gcc occasionally do surface, they seem no more common than what I see in many other language implementations, likewise I find writing C++ no more bulky than writing in many other languages, including such languages as Haskell or Java. Nor is the standard particularly long, if that is what is meant with bulky. Difficult to understand is, of course, a function of the user, and a lot of people seems to have few or no problems understanding C++. Mental faculties do wary, of course. As for the Stroustrup quote, there is a more pertinent quote right on the wiki page under the criticism. What annoys me about these criticism is that there is plenty of /valid/ criticism (e.g. the inclusion of the throws declarations, the heavily overloaded "static" keyword, or the way enums pollute the owning class), but apparently the critics would rather flung subjective mud :/ Esben (talk) 15:54, 7 November 2009 (UTC)

Do we need this retarded criticism page?

Did anyone read this? Im talking about this: [2]. This is full of bs, i checked the linked subpage, containing infos about references, and the writer totally doesnt know what hes talking about. Its ok to criticize C++ if you like, i have my own problems as well, but if youre plainly stupid than dont be linked to the Wikipedia. IMHO. 192.100.130.238 (talk) 07:54, 6 November 2009 (UTC)

I agree, just reading 8.2 makes you realize this. On the other hand, C++ seems to be a traumatic experience to many, and having these pages seems to let them vent some steam. Perhaps we could move the links to some ""hate sites" section? The linked page is obviously from someone who loves C... note how he cannot see the advantage of std::vector over C arrays. Esben (talk) 16:07, 7 November 2009 (UTC)

I don't know, there could be a section about this (though my english is not so perfect :(). My impression is that C++ is the language that created the most hate and love (in short: emotions) towards itself. The site in question is definitely one proof/reference for this. 84.2.161.52 (talk) 16:48, 8 November 2009 (UTC)

The FQA does not meet the external links guideline. There are several reasons for this.

1. Sites that "misleads the reader by use of factually inaccurate material or unverifiable research" are to be avoided
2. Personal web pages should be avoided, unless written by a recognized authority
3. Sites that do not provide a unique resource beyond what the article would contain if it became a Featured article, should be avoided

decltype (talk) 19:05, 8 November 2009 (UTC)

I have re-added the FQA link twice now, and it's been deleted in short order both times. I'm going to desist because I have better things to do with my time, but it's disappointing to me to see that the WP C++ page become a hangout for C++ cheerleaders. WP should offer well-rounded (encyclopedic even) coverage of this topic, and part of doing that is pointing out major criticisms of the language. The FQA may be "just a web page", but pretty much every knowledgeable C++ programmer is familiar with this now-famous page. Even if (if!) this page is not 100% factual, this is hardly a bar to linking, as this is true for most of WP's other external links as well. Like it or not, C++ has some serious problems, people have taken note of this in public, and WP should not be trying to sweep these facts under the run. Mkcmkc (talk) 14:01, 29 November 2009 (UTC)

Supposedly edits are by consensus - you appear to be the only promoter of the content (aside from the page's author) Tedickey (talk) 15:21, 29 November 2009 (UTC)

I don't mind criticism of C++ --- there is plenty to criticize --- but that page is so full of errors it would not help anyone, except perhaps a C-fanboy who wants his ego stroked. But I'd applaud any factual criticism page. Esben (talk) 15:28, 29 November 2009 (UTC)

Stuff removed from Boolean data type article

The following section was removed from the article Boolean data type:
begin removed text

---

---

During its standardization process, the C++ programming language introduced the bool, true and false keywords, adding a native data type to support Boolean data. Its size is implementation-defined. bool was introduced in 1993.

Values of type bool are either true or false. Implicit conversions exist between bool and other integral types, floating point types, pointer types, and pointer-to-member types. In addition, user-defined types can be converted to bool via a user-defined conversion operator. In general, a zero or null-pointer value is converted to false, any other value is converted to true.

#include <string>

int main()
{  
  using std::string; 
  // implicit conversions to bool
  bool a = 'a'; // char -> bool  [true]
  bool b = 0.0; // double -> bool  [false] 
  bool c = -1; // int -> bool  [true]
  bool d = 0; // int -> bool  [false]
  bool e = &a; // bool* -> bool  [true]
  bool f = &string::clear; // void (string::*)() -> bool  [true] 
   
  // implicit conversions from bool
  int i = false;    // bool -> int  [0]
  double j = true;  // bool -> double  [1.0]
  char* k = false; // bool -> char*  [(char*)(0)]   
}

The 1998 C++ Standard Library defines a specialization of the vector template for bool. The description of the class indicates that the implementation should pack the elements so that every bool only uses one bit of memory. This is widely considered a mistake. vector<bool> does not meet the requirements for a C++ Standard Library container. For instance, a container<T>::reference must be a true lvalue of type T. This is not the case with vector<bool>::reference, which is a proxy class convertible to bool. Similarly, the vector<bool>::iterator does not yield a bool& when dereferenced. There is a general consensus among the C++ Standard Committee and the Library Working Group that vector<bool> should be deprecated and subsequently removed from the standard library, while the functionality will be reintroduced under a different name. This change is unlikely to take place until after C++0x.

---

---

end removed text
Is there a place for this text in the C++-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:27, 30 December 2009 (UTC)

The first two paragraphs are still adequately summarized in Boolean data type; the last should probably go into Vector (C++). —Korath (Talk) 23:37, 5 January 2010 (UTC)

I have incorporated the vector<bool> info into the vector article. No need to take extra steps for attribution after the merge, since I wrote it all. decltype (talk) 07:08, 6 January 2010 (UTC)

Hello World!

I think the example listed is absolutely fucking retarded, why bother listing such a tedious method, may I suggest:

#include <iosteam>
using namespace std;
{
  cout << "Hello World!" << endl;
}

It's not gonna get changed, because, to stop unproductive edit-warring, we've chosen to stick with the "official" version from the language's designer, which is at least not arbitrary. (see hidden HTML comment in the Hello World section for more info). --Cybercobra (talk) 00:34, 22 July 2009 (UTC)

Your suggested example doesn't even compile. Stroustroup's version does. -- Autopilot (talk) 13:02, 23 July 2009 (UTC)

Tombrown16 (talk) 22:37, 17 January 2010 (UTC) I think my addition was fine, It shows the conventional C++ Hello World program allowing windows users to pause to see the output text, I have not deleted the example hello world I have merely added a more conventional one. I have also added a note about the windows only feature, you have no reason to delete it! There is nothing wrong with:

#include <iostream>
using namespace std;
int main()
{
   cout << "Hello World " << endl;
   system("PAUSE");
   return 0;
}

—Preceding unsigned comment added by Tombrown16 (talk • contribs) 22:35, 17 January 2010 (UTC)

An introductory example in an article about a programming language is not the place to show how to work around a specific operating system's misfeatures. Especially since your example doesn't compile without including stdlib.h and relies on an external program rather than something portable like getchar(). —Korath (Talk) 22:54, 17 January 2010 (UTC)

Tombrown16 (talk) 23:06, 17 January 2010 (UTC) Okay I agree with you to some extent :) But I still think showing this under the given example would be better.

#include <iostream>
using namespace std;
int main()
{
   cout << "Hello World " << endl;
   return 0;
}

This has been discussed at length on the talk page archive and consensus was (eventually) reached. The reasons for the current version are that it is sourced to the author of the language and his book on C++. It does have some idiosyncrasies, such as eliding the return 0 and using "\n" rather than std::endl, but it remains the canonical Hello, World by the author of C++. There is no reason to include two hello world examples in the page (WP:NOTHOWTO). -- Autopilot (talk) 17:50, 18 January 2010 (UTC)

Improved Hello World

The C++ Hello World example is pitiful, it demonstrates bad programming practice by classifying the namespace instead of importing it, Also /n is non portable and endl is the standard way of doing things. This is the example I propose.

#include <iostream>
using namespace std;

int main()
{
   cout << "Hello, world!" << endl;
   return 0;
}

This is a way better example and should be shown replacing the current example or underneath it as a second example the current example is poor! Tombrown16 (talk) 17:50, 18 January 2010 (UTC)

'\n' (not /n) is just as portable as std::endl since for text mode files it will output the appropriate platform specific line ending as per the standard. Importing the entirety of namespace std is frowned upon by several style guides, such as this C++ FAQ. Again, this topic has been discussed ad naseum in the archives of this talk page. -- Autopilot (talk) 18:51, 18 January 2010 (UTC)

Given the myriad possible variants of Hello World to choose from, the choice is essentially arbitrary, but at least using the one from the language designer's own book is minimally arbitrary. --Cybercobra (talk) 20:31, 18 January 2010 (UTC)

I propose a C++ control flow example anyone agree? Tombrown16 (talk) 18:11, 18 January 2010 (UTC)

Logo

This is a rather minor issue, but I recently removed the size setting (175px) for the logo (C++ Programming Language book cover) so that it would not be pixelized and therefore more readable. Not long after another editor set it to 150px, saying "the size of the logo standardize" in the edit summary. I'm unaware of any standard for logos in programming language articles, and a quick survey of C, Perl, PHP, Python, and Java show all different sizes in use. As the image is just 128px, I'd prefer to see it remain at that size rather than enlarged rendering it hard to read, but was wondering how others felt. --skew-t (talk) 10:38, 1 February 2010 (UTC)

access middle variables

how to access middle block's variable? C++ code------------

int m; main() { int m=20; { int m =30; //how can i access outer m whose value is 20 from this block?? } }

You cannot access them directly at all. All indirect means are a lot harder than just renaming them to avoid the variable shadowing in the first place. Note that questions such as this do not belong here. Please try Wikipedia:Reference desk/Computing in the future. --Stephan Schulz (talk) 15:50, 4 March 2010 (UTC)

Confusing wording

In the criticism section, second paragraph, last sentence:

For comparison, the C programming language's is about 160 pages, although it was written eight years earlier and defines many fewer features.

I have no idea how to decipher the last part ("and defines many fewer features"),

... many fewer ... ?!?

Maybe someone that actually managed to decipher that part can rephrase it into a less ... confusing version? --77.124.52.69 (talk) 12:53, 15 March 2010 (UTC)

I've changed some text and tried to make it clearer, but really the complexity of the language cannot be measured by the length of the standard. Maybe a computer scientist could supply us with a better argument? --Northernhenge (talk) 15:55, 15 March 2010 (UTC)

"Many fewer" is sort of a Danish+English way of speaking. It means "far fewer". I believe it is a quote from Mr. Stroustrup (the inventor of C++). Esben (talk) 19:25, 15 March 2010 (UTC)

It is indeed dubious to make assumptions about a language's complexity based on the length of the standard or specification. That's almost like saying three-hour movies are more complex than two-hour movies. decltype (talk) 12:53, 17 April 2010 (UTC)

How about 'significantly fewer'? or even simply 'fewer'? Willbennett2007 (talk) 20:03, 16 April 2010 (UTC)

16-bit longs?

Anybody ever heard of a 16-bit long? Specifically, in some old 16-bit version of Visual C++? See Talk:Long integer#16 bits???. —Steve Summit (talk) 13:34, 21 April 2010 (UTC)

Never mind; the (dubious) claim in question has been deleted. [3] —Steve Summit (talk) 12:35, 24 April 2010 (UTC)

Example Code

I was viewing the example code in the article. I was thinking that it may be better to show a way as if the program was much longer, thus requiring a more simple source like:

#include<iostream>

using namespace std;

int main (){
    
    int x, y, z=0;
    cout << "X: ";
    cin >> x;
    
    cout << "Y: ";
    cin >> y;
    
    cout << "Calculating product!" << endl;
    for(int i=0; i<y; i++) {
            cout << z << "=" << z << "+" << x << endl;
            z=z+x;
            cout << "i is equal to " << i << endl;
            }
            
    cout << "Z: " << z << endl;
    
    system("PAUSE");
    
    return 0;
}

Imagine having to write that using the syntax of:

#include <iostream>

int main()
{
   std::cout << "Hello, world!\n";
}

I, for one, would have my head explode if I had to write C++ like the second example. Hamtechperson 03:52, 16 February 2010 (UTC)

I'm not seeing what the implied substantial differences are. "std::", endl vs. \n, and a different bracketing style. Big whoop. --Cybercobra (talk) 04:08, 16 February 2010 (UTC)

Some of the bracketing is from personal preference, and I guess from reading the above that "\n" is basically the same as "endl;", but the major point i wanted to make is that to write a 300+ line text-based file is much quicker as inserting "using namespace std;" just the once, whereas having to put "std::" may sacrifice time for versatility. (I've made some large C++ files (300+ lines of code and text based)) Hamtechperson 19:01, 16 February 2010 (UTC)

To repeat my understanding of the reasoning for the current example: Given the myriad possible variants of Hello World to choose from, the choice is essentially arbitrary, but at least using the exact one from the language designer's own book is minimally arbitrary. --Cybercobra (talk) 23:46, 16 February 2010 (UTC)

NO, '\n' and std::endl are NOT the same. The later forces a flush of the stream. For that matter, your "hello world" example exhibits undefined behavior because it doesn't have a final std::endl in it. —Preceding unsigned comment added by 192.91.173.42 (talk) 20:58, 30 March 2010 (UTC)

Interesting. I was pretty sure that the standard required a flush on the standard streams after the end of the main function and after destruction of all static objects. However, after actually reading the standard and two corresponding discussions on comp.lang.c++[4] and comp.std.c++[5] I am now not so sure. (I don't see how a missing flush would cause undefined behavior, though.) —Tobias Bergemann (talk) 10:34, 31 March 2010 (UTC)

It does, because the standard says it does. —Preceding unsigned comment added by 192.31.106.34 (talk) 21:25, 31 March 2010 (UTC)

Ahem. I will believe that when you give me a pointer to where exactly the standard states that. Yes, std::endl forces a flush. No, omitting that flush will not cause undefined behaviour, because reaching the end of main() implies exit(), exit() implies closing of all streams, and closing a stream implies writing all unwritten buffers. -- DevSolar (talk) 14:05, 5 May 2010 (UTC)

It is indeed not guaranteed that a flush will occur at the end of the program. The problem has been acknowledged by the committee, and addressed for C++0x, by requiring the program to behave as if at least one instance of std::ios_base::Init with static storage duration exists. (This object is required to flush upon destruction) - std::cout et al are not required to do so. decltype (talk) 16:27, 5 May 2010 (UTC)

C++ Sample Program (Hello World!)

I think that the sample program should be replaced with the following.

#include <iostream>
int main()
{
    std::cout << "Hello world!\n";
    return 0;
}

Derek II 11:16, 27 May 2010 (UTC) —Preceding unsigned comment added by Derekthesecond (talk • contribs) All the compilers I have tried generated an error when I tried to compile the sample program. —Preceding unsigned comment added by Derekthesecond (talk • contribs) 11:14, 27 May 2010 (UTC)

Existing version works fine for me on GCC's g++. What compilers are you using? --Cybercobra (talk) 11:19, 27 May 2010 (UTC)

Criticism

I just was thinking that it might be a good idea to include a link to

http://yosefk.com/c++fqa/

Since this is the best collection of C++ criticism I have ever seen. Of course discussions about C++ tend to get rather religious so I hope I do not offend someone by proposing to add this link :-). —Preceding unsigned comment added by 92.194.163.219 (talk) 10:04, 29 May 2010 (UTC)

I didn't find the link particularly informative, personally. Sebastian Garth 23:06, 29 May 2010 (UTC) —Preceding unsigned comment added by Sebastiangarth (talk • contribs)

The link was previously in the article, but there seemed to be consensus to remove it as it didn't meet the external links guideline. Previous discussion here. Regards, decltype (talk) 23:13, 29 May 2010 (UTC)

The link belongs in the article--it's well known and enumerates a number of serious problems with C++. Unfortunately, it offends religious sensibilities, so cannot be allowed. Mkcmkc (talk) 22:43, 6 June 2010 (UTC)

If you can provide reliable sources which establish your point, then there's something to discuss Tedickey (talk) 22:47, 6 June 2010 (UTC)

--

The article says, under Inheritance: "Inheritance from a base class may be declared as public, protected, or private. This access specifier determines whether unrelated and derived classes can access the inherited public and protected members of the base class." I thought an access specifier specified what members an object of a class could access outside the class. From what I studied at school, that should be mode of derivation. Vvneagleone (talk) 13:27, 15 June 2010 (UTC)

In short, it does both. It's called an access-specifier regardless of whether it appears in a base class specifier or in-between member declarations. decltype (talk) 13:49, 15 June 2010 (UTC)

Export template

Im tempted to drop that section from the article altogether. Is pretty obscure detail of the language that not many know how works, on a few implementations that it works on, and no one uses at all. On the other hand, section is factually correct and has some citations, what do you think? —Preceding unsigned comment added by 83.25.102.57 (talk) 11:15, 20 June 2010 (UTC)

No one cared, so i killed it. 83.25.98.37 (talk) 18:44, 25 June 2010 (UTC)

No objections. If time permits, I'll make a separate article for it. decltype (talk) 18:46, 25 June 2010 (UTC)

Language size

I think argument in language size is just silly. First we say that C++ is oh so complex with 310 pages of std, and than we show C# (which is _a lot_ simpler imo) that has 440 pages. If anything, this only proves that C++ is underspecified. Ill drop this part of criticism unless i can think of some way to make it right. Kyle2^32-1 (talk) 20:16, 25 June 2010 (UTC)

Dropped. Kyle2^32-1 (talk) 16:45, 27 June 2010 (UTC)

Missing return value and undefined behaviour.

In the "Language Features" section, there was mention that failure to provide a declared non-void return value results in undefined behaviour. IMHO, this had a definite negative bias, as if all you need to crash your program was being a bit forgetful. I would be very surprised if any C++ compiler out there wouldn't warn you of this, and added a corresponding wording. User Sebastiangarth removed this as "superfulous details concerning compiler diagnostic messages". I disagree; I admit the diagnosis is not required by the standard, but avoiding this problem is really trivial (as opposed to real weaknesses C++ undoubtedly has), and the previous wording gave the issue far too much weight. -- DevSolar (talk) 05:54, 24 June 2010 (UTC)

How is it negative bias when std explicitly defines such situation as undefined behavior? I also dont think thats it even possible for a compiler to issue accurate warnings (ie. emit the warning when its happening and not emitting them when such thing does not happen) for cases when its possible for function to flow past its end w/o return. But i agree that there may be too much attention to this (but its not that bad), and i would be very surprised if i saw compiler that does anything other than return garbage from function in such a case - still its UB. 83.25.73.31 (talk) 17:06, 24 June 2010 (UTC)

Consider this bit of code:

#include <iostream>

int undefined( void )
{	}

int main( void )
{
	std::cout << undefined( ) << std::endl;
}

Compiled with GCC(3.4.5), it produces no diagnostic whatsoever, unless -Wreturn-type or -Wall is specified. Anyway, I'm fine with leaving the diagnostic digression in the article as long as the "almost all" wording is changed to "some", or similar...Sebastian Garth 17:38, 24 June 2010 (UTC) —Preceding unsigned comment added by Sebastiangarth (talk • contribs)

You are using pretty dated compiler. GCC 4.1.2 gives a warning for your case with -Wall —Preceding unsigned comment added by 83.25.73.31 (talk) 17:46, 24 June 2010 (UTC)

For the MINGW compiler (MSWindows), 3.4.5 is the still the "official" (most stable) release, unfortunately. Sebastian Garth 18:11, 24 June 2010 (UTC) —Preceding unsigned comment added by Sebastiangarth (talk • contribs)

Wikipedia (http://en.wikipedia.org/wiki/Mingw) says otherwise ;). 83.25.73.31 (talk) 18:18, 24 June 2010 (UTC)

disregard that, i looked at Mingw version not its compiler ... 83.25.73.31 (talk) 18:25, 24 June 2010 (UTC)

Sebastiangarth, if you use GCC without -Wall just shows you don't have enough brain to use a compiler, let alone edit a language Wikipedia entry. (Yes this is an insult, but it's not targeted at you. You do always use -Wall, don't you?) -- DevSolar (talk) 07:51, 25 June 2010 (UTC)

Well, if I were to believe the claim that "almost all compilers issue a diagnostic", I might not! See my point? Sebastian Garth 14:20, 25 June 2010 (UTC) —Preceding unsigned comment added by Sebastiangarth (talk • contribs)

Good one. Indeed you got a point there; how about that most if not all compilers can issue a diagnostic in this case? Hey, we might even get in a word about how -Wall et al. are your friend really. -- DevSolar (talk) 17:10, 25 June 2010 (UTC)

Instead of "most if not all", though, how about "typically provide the means"? Oh, and the options bit may be a tad extraneous, methinks. Maybe an inline reference would suffice? Sebastian Garth 18:20, 27 June 2010 (UTC) —Preceding unsigned comment added by Sebastiangarth (talk • contribs)

Agreed. -- DevSolar (talk) 14:26, 1 July 2010 (UTC)