Talk:C++

printf()

I'm sick of everyone fighting over the cout declaration in the hello world application. We should stop butting heads over this and come up with a mutually acceptable solution. sprintf() is a nice, unambiguous c++ function that will serve well in the application without leaving room for arguement. —The preceding unsigned comment was added by 207.207.127.254 (talk • contribs).

While sprintf() is a lovely function, we have this bit of text just above the hello.cpp example:

The following is a Hello world program which uses the C++ standard library stream facility to write a message to standard output.

Given that, your sprintf() example doesn't deliver the promised goods.

Atlant 17:46, 30 April 2007 (UTC)

I'd also add: the sprintf code you wrote will fail to compile, and even if it did compile, it would not produce any output. Now, please, stop trying to make a point with these edits and let it go, or I will seek outside help on this. ATren 17:53, 30 April 2007 (UTC)

I accidentally (by habit) wrote sprintf instead of printf. The following is functional, standards conforming, nonredundant code:

The slash was backwards, the lib is fine.

#include <stdio.h>
int main(){
        printf("Hello, world!\n");
        return 0;
}

A one sentence edit to the preface of the hello world application would remove reference to streaming. I am not trying to prove a point, ATren. Please stop following me around reverting my changes and let the rest of Wikipedia decide on this one. Let's call a truce: I won't edit it if you/Xerxesnine doesn't. Let the leveller heads around here take a stab at it. I see no reason not to clear up this ofstream debate once and for all. -Norvig

printf/sprintf is an artifact of old style C streams. C streams are not typesafe, which is why C++ iostreams were developed in the first place. Experts recommend against the use of C streams in C++ code because (a) functions like printf are not extensible to non-primitive types, and (b) the use of variable arguments in printf makes it easy to write code that has the wrong number of arguments, yet still compiles. In fact, recent versions of popular compilers will actually give you deprecation warnings for certain C-streams functions (citing security concerns due to unchecked buffers).

The fact is: C++ streams are appropriate for a C++ hello world program, and there is absolutely nothing wrong with the existing code. Why do you insist on changing it? ATren 18:23, 30 April 2007 (UTC)

As previously stated, the ostream include is senseless, confusing to a newbie, and potentially dangerous in some environments. A hello world application is designed to create a simple framework in which the newbie can "learn by seeing/doing". The current example less clear than the proposed one.

(edit conflict) Shouldn't that be a backslash n instead of a forwardslash n? And cstdio instead of stdio.h? And really, hello,world should use streams because this is the preferred C++ way of doing things, though this isn't necessarily compelling. --Yamla 18:23, 30 April 2007 (UTC)

Suggesting the C version of "hello,world" in the C++ article... this is a troll, right?

The last thing we'd want is for a newbie to "learn by seeing/doing" things wrongly. Therefore we should present best-practice example code, not dumbed-down, lowest-common-denominator, or C-legacy code. If things are not clear to the newbie (OMG OMG why dose it includes ostreams???/) they should be explained by concise comments. SheffieldSteel 03:09, 2 May 2007 (UTC)

Lets try to stay civil in this matter, SheffieldSteel, and not reduce the discussion to mockery. printf is *not* legacy code, as it has many uses in modern day coding, and is arguably more powerful than C++ streams. printf is not the "lowest common denominator", but rather displays "Hello, world!" in a clear, consise, logical manner so someone new to C++ can pick up the syntax and "feel" easily, in a perfectly standards-conforming manner. This is what a hello world application is for. Please restrain yourself from parody/mockery of useful suggestions in the future.

Some programmers prefer printf, but experts still generally recommend the C++ streams. See the C++ FAQ Lite. There is no consensus for changing this hello world to use the old-style C streams - this is an article about C++, not C, and therefore the C++ streams should be presented. It's that simple. You may prefer printf in your code, which is fine, but C++ streams are more appropriate here in a C++ article. ATren 12:13, 2 May 2007 (UTC)

(Observation) You know, there's something ironic about the use of C++ FAQ Lite to argue for the use of C++ streams I/O when the very next FAQ in that list is "Why does my program go into an infinite loop when someone enters an invalid input character?" (which is, essentially, an explanation of how easy it is to screw yourself with C++ streams I/O).

Atlant 12:19, 2 May 2007 (UTC)

But that item describes a misuse of the library - specifically, by not checking the status of the stream, you risk missing an end of file or some other exit condition. This is not an argument against the library, just describing how it is commonly misused. printf can just as easily be misused and cause runtime havoc (e.g. printf("%s",1)). Any library can be misused. ATren 12:28, 2 May 2007 (UTC)

Yes, but some are more easily misused than others. In your printf example, it's much easier to tell why it went wrong. the iostream example took a closer examination before I was able to spot it. The hello world is all about clarity, adherence to the standards, and ease of use. We should apply the principle of least surprise when generating hello world applications for new users. —The preceding unsigned comment was added by 207.207.127.254 (talk • contribs).

How about this example:

printf("%s %c %d, %f, %d, %s, %c %f", ",0,",',',0,0.0,0,"\",',',",'"',0.0)

? Is this easy to tell what's wrong? Especially when it compiles perfectly fine? Any moderately complex use of a library is subject to misuse. But the point here is, this is an article on C++, so C++ streams should be used. That's all. ATren 17:19, 2 May 2007 (UTC)

Yes, but are we advocating the use of " printf("%s %c %d, %f, %d, %s, %c %f", ",0,",',',0,0.0,0,"\",',',",'"',0.0)" in the hello world application, or the use of "printf("hello world")"? A similar, as obfuscated iostream call could easily be created. Please restrict your examples to those that actually matter given the discussion context.

And there is nothing obfuscated or tricky about std::cout << "Hello, World" << std::endl; either. So there is no reason to replace it. ATren 18:01, 2 May 2007 (UTC)

So, you say that printf is at least as understandable as std:cout, and they're both just as simple and safe, and I say that the ofstream include is confusing, and could potentially cause errors in systems that don't protect the file from being double-included. Why shouldn't we change it again?

Because the ostream version is correct, and appropriate. ATren 00:55, 3 May 2007 (UTC)

"Correct and appropriate" doesn't contribute anything to the discussion. Saying "It's right because it's right" will just create an endless arguement, and isn't helpful.

I'm not going to continue to go around in circles in this debate. There is zero consensus for this change, and there's plenty of support for keeping it exactly the way it is. ATren 19:36, 3 May 2007 (UTC)

I just removed another edit from 207.207.127.254 (talk · contribs) to the main article. This was clearly made against consensus (I can see nobody other than that editor arguing for that version), used the compatibility stdio.h include instead of the standard cstdio include or better yet, the C++ include, iostream. And the C function printf instead of std::cout. As this is meant to be a C++ example, we should include a C++ hello, world rather than a C hello, world. If this continues, I will report that editor for vandalism. --Yamla 02:25, 4 May 2007 (UTC)

Sorry for the misunderstanding, Yamla. I didn't mean to vandalize. I was under the impression that I could discuss my ideas here, and, barring legitimate objection, post the change without being prosecuted. I'm not saying anything inflammatory or wrong (except the legacy c include -- dates me I guess!). If there is something else I need to do be more correct, please point me to the policies and I'll abide by them. I know this is a sensitive subject for some reason, but C++ *is* a superset of C, so it's perfectly legitimate to use this simpler example to help new users on their way. I'm not sure what I'm doing wrong here. Why the animosity?

—The preceding unsigned comment was added by 207.207.127.254 (talk)

Thank you Yamla; that was the point I was trying to make. Will try to be more civil in future. SheffieldSteel 03:36, 4 May 2007 (UTC)

I've reported this edit against consensus on AN/I. I am requesting either a block or a semi-protect. ATren 03:49, 4 May 2007 (UTC)

(I am probably going to regret this.) In light of the increasing heat of the exchange above I would like to ask the participants to take a step back and to reconsider the goal of their contributing to wikipedia. If Wikipedia works at all it does so by collaboration, and by reaching for consensus amongst the editors, and by respecting the opinions of other collaborators. However, opinions, even if they appear to reflect the opinion of a majority of collaborators, have to be substantiated by arguments.

That being said, I would like to explain why I would prefer for the "Hello, world!" example provided by a page on the C++ programming language to make use of the features provided by the language. After all, why do we at all bother with providing a "Hello, World!" example? I can think of the following reasons:

• Tradition
• It gives readers an example for a small but complete example program with easily understood meaning.
• It gives readers familiar with other programming language a point for comparison of those languages.

C++ more or less contains all of C, so much so that a C sprintf "Hello, world!" programm is also a C++ "Hello, world!" programm, and I think the article could very well contain a note of this fact when giving the C++ "Hello, world!" programm. By giving a C "Hello, world!", the first two reasons I gave above are satisfied. By giving a std::cout "Hello, world!" I think we could add value to the article for those readers already familiar with C, thereby giving more emphasis to the third reason. — Tobias Bergemann 09:07, 4 May 2007 (UTC)

Tobias Bergemann, I think that was well said, and agree with you. The only point I'd make is I wish people would stop saying sprintf() in this discuission when I think it's been stipulated-to that we all mean printf() ;-).

Atlant 12:15, 4 May 2007 (UTC)

Does anybody here agree with Norvig that a printf should be used instead of std::cout? Does anybody here know of a compiler that would fail to compile code that includes both <iostream> and <ostream>, as Norvig claims? (This compiler, by the way, would be in direct conflict with the standard, as I indicated above). Does anybody here agree that the C++ sample program should be identical to the C sample program, using not a single C++-specific feature? Perhaps I am misjuding consensus here, so I'm just curious if anybody else shares Norvig's views. ATren 14:53, 4 May 2007 (UTC)

Well, if this were my universe, I'd erradicate C++ completely in the hope that a useful object oriented language would arrise to fill the niche. However, accepting for the moment that I can't, I think we should present C++ using typical C++ features, i.e. streams instead of printf(), and use the language in a standard-conforming way, broken compilers be damned. --Stephan Schulz 15:54, 4 May 2007 (UTC)

Thank you all for your calm, informative comments. I'm sorry for making the change earlier, but before it was only ATren, who has a long history of disagreeing with me via statements that is way was "Correct and appropriate", with no other evidence. Not to mention trying to get me banned from Wikipedia for no reason. I misunderstood the consensus, and had no intention of modifying the article against others' will.

That said, I'd like to contribute another point towards my arguement. On a hello world application, ideally each statement has a clear, consise purpose, so that the new user can look at each statement and derive meaning. With the current cout-based example, we include a spurious include to <ostream>, which has no obvious link to the rest of the code, and the new programmer could even delete it without consequence when experimenting with the code. This leaves room for ambiguity as to the purpose of this include, and may confuse the user. The printf example does not have a similar fault, and it's syntax is arguably more understandable.

Thanks for your time. I appreciate constructive discussion.

Most of his comments about me are flat out wrong, and I am prepared to prove it if anyone questions. I tried to help him by guiding him through the rules and regulations here, and he basically told me to leave him alone while he continued to make changes without consensus. I only sought admin help after his last change to the article.

He refuses to acknowledge consensus (at least four of us disagreed with his changes) and continues to make the same arguments over and over again even though nobody agrees with him. No matter how much he tries to demonize me (and earlier, Xercesnine) his actions are not consistent with a new user seeking to contribute in good faith. He started by removing the one line in the entire article that said "don't remove me", then reverted 4 times, then started this endless circular argument, and now he's playing the role of the helpless victim. Sounds like he's gaming the system to me.... ATren 18:20, 4 May 2007 (UTC)

I'm not "gaming the system", I don't even know what that means! The problem with Wikipedia is that *anyone* could've put that line in. I simply assumed that the person who put the line in didn't know what he/she was doing. As previously stated, these were my first edits, before I was aware of user pages, or even discussion pages. I've come a long way. I'm obeying the rules. Please, let's move on to the subject at hand. I don't see this arguement as circular. Can you point to anything circular about it? I think the new users to the debate have definitely contributed some good points, and while I don't agree with them, they definetly hold water. Debates can be fun, ATren, and I normally enjoy them. If you don't wish to contribute anymore, simply stop, and I won't edit anything on the C++ page unless the others agree with me. Thanks!

OK, if you want to continue this debate, let's start with that compiler that won't compile with both <ostream> and <iostream> includes. Which compiler is it? Please specify the compiler brand, target architecture, and version number, so we can investigate for ourselves. ATren 19:16, 4 May 2007 (UTC)

Carry on with the great debate; don't mind me. I just want to say for the record that I think a lot of readers may be coming to C++ from C (I know I did, way back when), and because of that, the more we can contrast hello.cpp with hello.c, the better - as long as the differences are explained, of course. SheffieldSteel 19:32, 4 May 2007 (UTC)

I agree that a C++ hello, world example is appropriate for an article on C++, and that std::cout is the C++ way of doing things, while printf is the C way. That said, having to include ostream is annoying. Still, there's so much going on behind the scenes with any hello, world example in any language that I don't think this is a significant problem. I agree with SheffieldSteel that it is appropriate to show the contrast between C and C++ with the hello, world example. --Yamla 20:03, 4 May 2007 (UTC)

I also concur the existing "hello, world" should remain unchanged, for the above reasons. That makes at least six contributors who share this view (Atren, Yamla, SheffieldSteel, Tobias Bergemann, Atlant, myself). To my knowledge, there is nobody who concurs with 207.207.127.254 (talk • contribs). It is my sincere hope that 207.207.127.254 (talk • contribs) gives up trying to make a WP:POINT, creates an account, and henceforth contributes constructively to Wikipedia. Xerxesnine 22:05, 4 May 2007 (UTC)

Yes, Xerxesnine, there appears to be a consensus against me. Yet, how am I supposed to know this before bringing it up in the discussion? I understand, and won't bring it up again unless another Wikipedian agrees with me, but I still don't understand your animosity. Everyone else seems to conduct themselves professionally enough, but you/ATren (which I'm beginning to think are the same person) seem to take my point of view personally. Both accuse me of making a point - what point am I trying to make? I don't understand this accusation, and I don't understand you and your sock puppet's constant aggression against me. Like I said, I will respect the consensus and not change the article, but I'm disappointed that those who could have welcomed me to Wikipedia have treated me in such a manner, when the rest have been so kind. —The preceding unsigned comment was added by 207.207.127.254 (talk • contribs). 6 May, 2007

I'm happy to see you have a good attitude towards this, and I hope you've learned a little bit about how Wikipedia works through all of this. ATren 18:20, 6 May 2007 (UTC)

Just for the record, I think it likely that the anonymous user was contributing in good faith. Most likely, he was simply unaware that a consensus already existed for the existing version, backed by information from the official standard and many, many months of us reverting people who think they know better than the official standard. It is, after all, why we specifically leave a comment there telling people not to change it. That said, ignoring that comment probably was not a good plan. --Yamla 22:17, 4 May 2007 (UTC)

Recent changes to "Hello, World" section

I reverted two minor changes to the "Hello, World" program:

• Reverted the comment "provided to adhere to the standard" - there is already a footnote about the standards conformance, and I think it's cleaner to indicate in the code what the header provides, rather than why it's needed. The current version ("provides std::ostream, std::endl") is also consistent with the comment above ("provides std::cout")
• Removed the comment about "//" denoting a comment. I guess this would be fine, but let's discuss here before changing the article.

The "Hello, World" section is (for some reason) very contentious, so any change should be discussed before we do it. ATren 15:06, 8 May 2007 (UTC)

To ATren, et al:

   It seems like you think that the C++ article is your personal property, and that all changes need to be rubberstamped by

you before being approved. The comment description in particular looks informative, and there is certainly no controversy over that. I suggest that ATren, Yamla, and Xerxesnine stop editing / discussing the C++ article while there heads cool over the matter, and see what the *actual* consensus is. Your actions amount to censorship, and this should not be tolerated in Wikipedia.

There's no need to get anything rubberstamped. Every editor is free to either discuss changes first, here, and try to obtain consensus, or go ahead and make changes without consensus, but don't be surprised if those edits are reverted. The fact is that various changes have been discussed extensively, and the current consensus version reflects that. SheffieldSteel 22:35, 20 May 2007 (UTC)

using namespace std

Someone has recently changed the code to remove std:: prefixes and add "using namespace std;" to the hello world program. I believe there was weak consensus that using namespace std; was inappropriate (that's my view, as well as Xerxesnine's) so I've reverted it, but perhaps this warrants more discussion.

My view is that experts such as Bjarne Stroustrup and Herb Sutter (and probably others) have advised against using this construct in all but the most specialized cases, e.g. porting a large project from the pre-namespace days. I don't think a 5-line "hello, world" should use a blunt tool that basically disables a core language feature (namespaces) and which several prominent experts advise should only be used for backwards compatibility with old code. I've yet to find an expert who advocates "using namespace std;" for general use. I'd be curious to hear others' views on this matter... ATren 13:54, 24 May 2007 (UTC)

Unfortunately, I learned with "using namespace std;" because I knew no better... It wasn't until quite awhile after I learned C++ that I found out all of the problems associated with using that. I've had to fight an uphill battle ever since against my urge to use this, but now I only infrequently find myself thinking about doing so... that said, I think that we should not be exemplifying things which will (often) have to be unlearned, especially in a "Hello, World!" example. A note could always be added (with a link to another section discussing namespaces, possibly?) to the effect that the std:: is clarifying the namespace and that there are alternate ways of doing the same thing (i.e. using std::cout;...). I do not advocate changing the helloworld example, but for people who are used to seeing it with the "using namespace std;" I think there should be a note to that effect somewhere in the general vicinity... Maybe it will catch someone before they end up like me. — EtherealFlaim 08:30, 26 May 2007 (UTC)

GLR parser is referenced in the article but it is not a link to the GLR parser page on Wikioedia

please make it a link (http://en.wikipedia.org/wiki/GLR_parser)

Thanks for your suggestion. When you believe an article needs improvement, please feel free to change it. You can edit almost any article on Wikipedia by just following the Edit link at the top of the page. We encourage you to be bold in updating pages, because wikis like ours develop faster when everybody edits. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. You can always preview your edits before you publish them or test them out in the sandbox. If you need additional help, check out our getting started page or ask the friendly folks at the Teahouse. --Yamla 18:32, 28 May 2007 (UTC)

Hello world program

The hello world program, that must be the minimum program for a language, can be redured. Cause iostream provides the whole class ostream and objects cout and endl, #include <ostream> is completely useless. Besides, it could also be simplified by adding the using namespace std line and not referring to the namespace std each time looked. --201.235.108.196 00:36, 29 May 2007 (UTC)

This has already been discussed. ostream is not completely useless. Just because it works in your particular compiler does not mean that it is correct according to C++ standards. --Yamla 01:08, 29 May 2007 (UTC)

Actually, in the C++ standart all the ostream class is in iostream --201.235.108.196 20:50, 29 May 2007 (UTC)

This is false. See 27.3 in the standard. This has already been pointed out, please do not make misleading claims like this again. --Yamla 21:10, 29 May 2007 (UTC)

I agree with the above anon user. There seems to be quite a bit of consensus gathered against the ostream inclusion. Perhaps you should address this in a way other than a holier-than-thou, backhanded response. Wikipedia is about consensus: if the vast majority is against the ostream inclusion, please just remove it and stop undoing edits to make a point.

Off the top of my head, there are at least 5 registered users who have endorsed the current version, and provided good reasons based on the existing wording of the standard (which is the most definitive reference on C++). On the other hand, a few anon IPs have expressed opposition with the reasoning "it works on my compiler", completely ignoring any argument that omitting the ostream header is incorrect by the wording of the standard. The consensus seems to clearly favor of including the header. ATren 18:45, 29 June 2007 (UTC)

Current usage of the language

Belem tower 09:28, 29 May 2007 (UTC) Would be interessant a link to a list of significative commercial/free software programs done with C++. This could enforce the improvement "Since the 1990s, C++ has been one of the most popular commercial programming languages."

Not really, no. I mean, millions of lines of code and literally thousands of programs have been written in C++. --Yamla 13:08, 29 May 2007 (UTC)

Exactly, take a look at google's results to see how many. --h2g2bob (talk) 21:53, 29 May 2007 (UTC)

Size of executables compared with C

Belem tower 09:28, 29 May 2007 (UTC) Can anyone add a comparative with C of the size of the executables and the reasons of why this is going this way ? Sorry for bad english.

No. This would depend on the compilers and is too platform-specific. --Yamla 13:09, 29 May 2007 (UTC)

What is an Class instance if not an object, or how can an object not occupy memory?

The following bit makes little sense to me, despite many years of object oriented programming in many languages, C++ included:

A very common source of confusion is a subtle terminology issue: because of its derivation from C, in C++ the term object means memory area, just like in C, and not class instance, which is what it means in most other object oriented languages. For example, in both C and C++, the statement int i; defines an object of type int, that is the memory area where the value of the variable i will be stored on assignment

I'm guessing that the author alludes to the fact that many languages only support pointer-to-object. Futher, I'm guessing that the confusion would be the confusion that "pass-by-value" languages such as Java are in fact passing pointers-as-values, and thus modification of the parameters affect the values as viewed by the caller. If I've guessed correctly, I'd like to rewrite that section for clarity, or simply delete it. If my guesses were off, could someone enlighten me as what the above section means? Esben 22:43, 7 July 2007 (UTC)

What is meant is that in the language of the standard all class instances are objects, but not all objects are class instances. — Tobias Bergemann 06:54, 8 July 2007 (UTC)

That would be correct. Since a class can be anything, even a single variable, and is not automatically a pointer to data, all variables and class instances are objects. However since objects can also be variables they are not necessarily classes (the inverse fallacy). Then there is also the principle of assign to class instances and not classes but I don't think this is referring to that. -Andrew ^{flame him | stalk him} 12:50, 14 July 2007 (UTC)

Interesting, I wasn't aware that the standard used "object" in that sense. But I must ask... is that really worth mentioning in wikipedia? It seems like an obscure detail in the language specification, rather than something most C++ users must be aware of. E.g, all C++ users I know use "object" as "instance of a class" and "typename" or similar for the general form you mention above. Nor have I ever come across anyone really confused by this issue, despite the claim in the quote. So, I think we should delete the quoted piece. Any protests? (And please tell me if I am going about this in the wrong way, I'm not exactly a battlehardened wikiveteran :) ). Esben 09:19, 20 July 2007 (UTC)

I think I agree that the disctinction between object and object of class type is mostly relevant only when C++ users directly refer to the standard, and therefore confusion will rarely happen. I for one won't revert if you remove the quoted piece.

By the way, and just for future reference, here is a quote of the relevant part of BS ISO/IEC 14882:2003:

1.8 The C++ object model [intro.object]

1/ The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is a region of storage. … An object is created by a definition, by a new-expression or by the implementation when needed. The properties of an object are determined when the object is created. An object can have a name. An object has a storage duration which influences its lifetime. An object has a type. The term object type refers to the type with which the object is created. Some objects are polymorphic; the implementation generates information associated with each such object that makes it possible to determine that object's type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions used to access them.

2/ Objects can contain other objects, called sub-objects. A sub-object can be a member sub-object, a base class sub-object, or an array element. An object that is not a sub-object of any other object is called a complete object.

Re: I'm not exactly a battlehardened wikiveteran — Neither am I, but I think you are doing fine.

— Tobias Bergemann 10:04, 20 July 2007 (UTC)

Very well, I have deleted the paragraph, since it as I mentioned above is more confusing than enlightening. Thank you for you help and your quote. —Preceding unsigned comment added by Esben (talk • contribs) 14:28, 31 August 2007 (UTC)

Contradiction: Date Errors in Article?

In the intro, it says that "C with Classes" was renamed to C++ in 1979. Then in "The name C++" section, it says it was renamed to 1983. Should be cleaned up. Peteturtle 17:23, 5 August 2007 (UTC)

That's my fault editing while half asleep. It said it was developed in 1983 when it was developed in 1979 and renamed in 1983. I tried to fix it but introduced my own error. It's fixed now. -- Andrew | flame him | stalk him 01:04, 7 August 2007 (UTC)

Criticism of C++

The criticism of C++ section seems to neglect the two biggest and most obvious criticism of C++ that I have, as a C++ professional:

• the lack of a well designed and standard library to perform common tasks - e.g. managing files and directories, dates & times, string manipulation, locking, threads, and most importantly the GUI. Rather than a standardized library to perform these functions, there are numberous competing and overlapping libraries in use. The most frequently used libraries are some or all of: obsolete, proprietry, opensource (and can't be used for commorcial development), or are just plain bad.
• Microsoft seems to have weilded a malignant influence over the language, by consistently providing non-standard and incompatible features into its Visual C++ platform (the most commonly used for commercial development). This has largely resulted in commercial C++ development being locked into the windows platform; strengthening its OS monopoly by stifling development of none windows versions of commercial software.

Pog 19:17, 6 August 2007 (UTC)

It should be an easy matter to find a reliable source that verifies any criticism which is notable. Do you have any sources in mind? Sheffield Steel^talkers_stalkers 20:54, 6 August 2007 (UTC)

"Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available." - Stroustrup [[1]]

"...every platform vendor provides a C++ library to access their GUI. The problem is that it doesn't have a standard GUI, and that is indeed a major problem. " - Stroustrup [[2]]

"... the C++ Standard Library currently contains no facilities for such filesystem tasks as directory iteration or directory creation, programmers currently must rely on operating system specific interfaces, making it difficult to write portable programs." - Boost [[3]]

It seems to me that this is just your personal opinion. The standard library includes most of those you mentioned or as much as can reasonably be expected to be included while still being platform independant especially with strings. One can't reasonably expect a "standard" library for threading and GUI which by nature is proprietary. The next version of C++ is however expected to have some foundational support for theading. What Microsoft has done to the language and entrenching it as part of its monopoly can hardly be blamed on the language itself and if you move away from VC++ and use the SDK instead you will find much greater compatibility. 3rd party libraries will still be required but that is the nature and spirit of the language. -- Andrew | flame him | stalk him 01:33, 7 August 2007 (UTC)

The standard library doesn't include any of them except strings, and relatively few functions are provided for string manipulation, resulting in endless boilerplate code to achieve common tasks. Boost does fix some of these problems, but Boost isn't part of the standard (yet). As for the criticism that microsoft has succesfully managed to co-opt the language, it is undeniably true - there are hardly any major title games or third party commercial software, for any other platform, largely because that software is developed in C++, and it is too costly to be worthwhile making it cross platform (due to the lack of standard libraries, plus the OS specific features provided built into the most commonly used IDE). Microsoft have attempted to J++'ify C++ and have largely succeeded. Pog 02:24, 7 August 2007 (UTC)

Hardly any third party commercial software? Oh come off it. And that's not even counting the non-commercial software. --Yamla 03:43, 7 August 2007 (UTC)

Or the software compiled with non-Microsoft compilers. --Yamla 03:47, 7 August 2007 (UTC)

So, you're not arguing about games then :P There are zillions of programs written in C++ that are windows only. There's a few for MAC, which tend to be MAC only (for the same reasons). A few developers, mostly of back-end/server or academic software, make their code cross platform. Anyway, this is beside the point. My arguement is that the majority of commercial C++ developers are developing using MFC, DirectX, managed C++.net C++/CLI or whatever, don't use the STL, and wouldn't know a template if it hit them. You might not like it, but it's sadly true.

If there are criticisms from verifiable sources you'd like to include, by all means do so. As for my personal stand on this, well, I develop cross platform multithreaded code all the time in C++... just because the language doesn't offer it as part of its standard library doesn't mean such libraries aren't available. It's just a difference in philosophy: Java is both a language and a platform, whereas C++ is simply a pure language. As such, C++ doesn't need to provide comprehensive OS coverage and leaves it up to third parties to provide that coverage.

I might also add: the fact that C++ does not enforce a single standard API for things such as threads and GUIs is viewed as an advantage by many developers - because they can choose the libraries that best suit their needs. And, yes, decent libraries for threads and GUIs are available. ATren 11:27, 7 August 2007 (UTC)

But so far you have mainly given criticisms of what Microsoft has done to it rather than criticisms about the language itself. I don't think that is fair since this article is about C++ and not Microsoft. The standard library provides extensive support for strings and anything more that you want from it should not really be provided by it and rather by 3rd parties. Directory creation is largely dependant on the platform and so can't reasonably be included without incompatibility. And what is a standard GUI? GUIs by their nature are not standard.

So far it seems like you are mainly criticising developers for not making code cross-platform when few languages will solve this. And face it, how many programs are written in Java? The moment MFC, DirectX, .net, or any such proprietary extensions are used cross-platform is no longer a realistic option. But the real problem lies with OS support. If Linux does not have a standard DirectX replacement that can hardly be attributed to C++ and the same problem will exist if another language is used. -- Andrew | flame him | stalk him 13:28, 7 August 2007 (UTC)

Criticism of C++

I propose to add to the criticism of C++ the absense of a fully featured API/standard library, for many commonly used features. This results in repeated reinventing the wheel or worse, and forces use of third party libraries, which are often poorly documented, not suitable for commercial use, not cross platform, and also mean that a C++ programmer must waste time learning a much larger number of API's than would otherwise be the case.

Here are some references in support of this criticism:

"Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available." - Stroustrup [[4]]

"...every platform vendor provides a C++ library to access their GUI. The problem is that it doesn't have a standard GUI, and that is indeed a major problem. " - Stroustrup [[5]]

"... the C++ Standard Library currently contains no facilities for such filesystem tasks as directory iteration or directory creation, programmers currently must rely on operating system specific interfaces, making it difficult to write portable programs." - Boost [[6]]

Here is a wishlist of features that people would want added to C++, many of them from Stroustrup himself: [[7]].

Notable on this list are: threads, sockets, filesystem, time & date, statistics, and a GUI.

There are plans to extend the C++ standard libraries in C++0x, partly to address this criticism. Pog 16:51, 10 August 2007 (UTC)

The GUI issue is really a problem with any programming language, at least any not tied to a specific GUI. After all, there is no standard GUI, as Stroustrup points out. Apart from that, my only concerns are that you avoid original research. See WP:NOR. That requires reliable sources, etc. etc., but you seem to be well on the way. --Yamla 16:58, 10 August 2007 (UTC)

#include <ostream>?

I know this has been discussed before but I would like to make a point. ALL of the compilers I know of don't need the ostream header file to work with the "Hello, World!". Here is a list of current compilers that don't need the ostream file to properly compile:

Visual Studio C++ Express Visual Studio 2005 Visual Studio 7.1 Dev-C/C++ The Metrowerks compiler gcc The compilers that come with some of the Linux platforms etc.

This code is outdated and needs to be changed, not for correctness, but for usefulness. I'm not saying that the ostream header file doesn't have its uses but it is, in this case, useless.

Signed(Sorry, wrong IP)User:141.155.135.126 —The preceding unsigned comment was added by 71.238.89.67 (talk) 01:20, August 23, 2007 (UTC)

This has already been discussed in great detail. The code is correct as per the standard. The article is about the language rather than about the specific implementations. On Visual C++, it may be appropriate to provide a hello, world that does not include ostream. On this article, about the standard C++ language, we need to provide a hello, world that follows the standard. The hello, world code we give here must work in any C++ compiler. What you are suggesting does not have to work. You say this code is outdated. This is not true. This code is correct as per ISO/IEC 14882:2003. --Yamla 01:33, 23 August 2007 (UTC)

I agree with Yamla. It comes down to this: including the header is absolutely guaranteed, 100% to work in a standards-compliant compiler; not including the header cannot offer that guarantee - even if 99.9% of compilers do happen to work, there's still a possibility that a fully standards compliant compiler will fail on code that doesn't include that header.

Or, think of it this way: if you were writing a portable application and you were faced with code that either:

• had a 0.001% chance of failing, or
• had NO chance of failing at the expense of a single extra line of code

wouldn't you choose the latter? We're talking about one single #include statement that has absolutely no adverse effect on runtime performance... why wouldn't we keep it? ATren 01:46, 23 August 2007 (UTC)

While you're right to say that it doesn't impact performance, the code presented is bad form. iostream includes both istream and ostream, as per the standard. It has to. It declares std::cin is an istream, and std::cout is an ostream. If iostream didn't include these headers, it couldn't make the declaration. Therefore, ostream does not need to be explcitly included. Also this code contradicts the "hello world" code in iostream. I have never seen a c++ "hello world" that includes ostream outside of this page, and I'd challenge anyone to produce an example of one.

Even the pendanic argument that ostream isn't explcitly included in the iostream snippet in the standard is a dubious justification for this code as is, as iostream also declares cin as an extern istream, and if the currently listed code was compiled on this hypothetical pendanic compiler/linker, would fail because it wouldn't be able to resolve the cin declaration. Thus, you'd need to include istream as well, making the code even more esoteric!

To say that the concensus is to use ostream, is to use a very interesting definition of "consensus," given that it seems that only the same two people are making the argument for it, and everyone else that has commented on this line in the months that it has been here is against it. While I'd agree that there is a consensus for printf() vs cout, there is abolutely no consensus for for the inclusion "#include <ostream>." I would go as far as to say that the consensus -- as evidenced by both the number of people commenting on on this page, and the shear volume of the literature -- is to remove it.

In a level of absurdity that can only be found on wikipedia, I flag the "hello world" section as NPOV.

May the God help us all.

67.188.7.78 05:46, 25 August 2007 (UTC)

The standard does not require that iostream include ostream. See Stroustrup (correction for page 633). I am going to remove the disputed tag from this section given that we now have a clear citation for it, from the author of the language, no less. --Yamla 12:25, 25 August 2007 (UTC)

I wrote the below comment before I followed that Stroustrup link, but it seems (according to Stroustrup) that the issue is only endl, not ostream. I seem to remember there was some concern about ostream as well (with respect to specific wording of the standard) but maybe that's not the case? If it's just endl, then maybe a compromise would be to remove the endl and replace with \n, which (if std::ostream does not require explicit <ostream> inclusion) would allow us to remove the <ostream>, right? ATren 12:45, 25 August 2007 (UTC)

(ec) I'll address each of the points above, one at a time:

• "iostream includes both istream and ostream, as per the standard. It has to. It declares std::cin is an istream, and std::cout is an ostream." - it is my understanding (and I'm willing to be proven wrong) that the standard does not explicitly declare that "iostream includes both istream and ostream". If the standard does not make that specific declaration, then it is possible that a standards compliant compiler might use forward declarations in the iostream header and defer actual definition to the ostream/istream headers.
• "If iostream didn't include these headers, it couldn't make the declaration." - This argument is flawed, since iostream can make the declaration without having the definitions:

namespace std {

template<typename E, typename T> class basic_ostream;

template<typename C> struct char_traits;

typedef basic_ostream<char, char_traits<char> > ostream;

}

• "To say that the concensus is to use ostream, is to use a very interesting definition of "consensus," given that it seems that only the same two people are making the argument for it, and everyone else that has commented on this line in the months that it has been here is against it." - there have been many discussions on this issue - search this page to find them. In every case where it was discussed, the consensus was to keep the header, and in some discussions there were at least 5 (probably more, I can't remember specifically) editors who concurred against 1 or 2 who opposed. Furthermore, the arguments made in opposition were often flawed - e.g. one editor claimed that including both iostream and ostream failed to compile on his compiler, which was clearly false.

Since we're talking about consensus here, the consensus reached earlier was that we should not focus on any specific compiler, but rather the standard itself. So, if the standard leaves open the possibility for std::ostream not to be defined in the <iostream> header, then we should include the <ostream> header as well.

So arguments along the lines of "why wouldn't a compiler include <ostream>" are irrelevant to the question of what the standard says.

Having said all this, I think I would change my opinion on this if someone presented evidence that the standard did not leave open the possibility of <iostream> declaring ostream without defining it (and the same for endl). But as long as the standard leaves the possibility open, I will support including both headers, and I believe there are at least 4 other editors who concur.

ATren 12:33, 25 August 2007 (UTC)

endl is the stream manipulator that Stroustrup speaks of, the one that requires ostream. That is to say, it is endl which requires ostream, not cout if I remember correctly. Now, the obvious answer is to change hello, world so that it ends in \n as shown by Stroustrup. That eliminates the requirement for the ostream include. However, pushing \n or pushing endl are two very different things. One outputs a newline, the other also flushes the stream. And really, endl is what you'd expect to see in a C++ example. So, our options (while adhering to the standard) is to use \n rather than std::endl, or using std::endl while including the required ostream include. I prefer using std::endl, I think it is the more C++ approach, so to speak. Stroustrup appears to prefer \n. I think that's a bad approach here but I can hardly argue that Stroustrup knows less about C++ than I do. --Yamla 13:00, 25 August 2007 (UTC)

I do share your opinion that std::endl is preferred as the more "C++" way to do it. But if \n good enough for Bjarne, I guess it's good enough for Wikipedia. :-) As for the stream flush that occurs in endl (but not with \n), a stream flush occurs anyways, on exit, so it's not a big issue here. So although my own first choice would be the endl version, the very fact that Stroustrup uses \n (indeed, seems to prefer it) makes the \n much more palatable for me. Using Stroustrup's exact version is also better from a sourcing standpoint - because then the entire hello world program would be copied verbatim from that source. And, of course, it would be nice to end this <ostream> header debate once and for all. :-) ATren 13:32, 25 August 2007 (UTC)

This debate is never going to end. At best, the debate will now shift to endl vs \n. Heck, we still get people changing the iostream include to iostream.h. Gah! Still, although I don't like \n either, being able to source this from Stroustrup is a huge argument in favour. --Yamla 13:55, 25 August 2007 (UTC)

OK, I'm going to boldly move to that version, if you don't mind. We'll see if anybody objects. ATren 20:09, 25 August 2007 (UTC)

Re: This debate is never going to end. The debate is probably going to end, as with the next version of the standard #include <iostream> will be apparently be required to act as if it included ostream and istream. See N2363 and N2259. — Tobias Bergemann 07:55, 26 August 2007 (UTC)

Standards compliance - compilers who support export keyword

this site and this one seem to be a good reason to add Intel's C++ Compiler to the collection of compilers supporting the export keyword. The former link means that Intel is also using the EDG frontend. —Preceding unsigned comment added by 217.80.125.57 (talk) 18:18, August 24, 2007 (UTC)

Good Article Review

This article has been reviewed as part of Wikipedia:WikiProject Good articles/Project quality task force. I question the quality of this article based on the Good article criteria. For that reason, I have listed the article at Good article review. Issues needing to be address are listed there. Regards, T Rex | talk 21:05, 29 August 2007 (UTC)

Ownership?

Is C++ currently or in the past owned, licensed, or public domain? Whether the answer is obvious to programmers or not, it might be worth including along with a response to the claim by an official SCO Group spokesman that SCO owns C++ See http://www.groklaw.net/quotes/showperson.phtml?pid=12 Carltonh 00:06, 6 September 2007 (UTC)

We already state that C++ is royalty-free. --Yamla 00:25, 6 September 2007 (UTC)

So perhaps that should/could be expanded documentating the royalty free status, along with mentioning the (perhaps one time only?) claim by SCO to owning C++. If no other or more recent claims by SCO are known, then it could be noted that they have not addressed or defended the ownership claim or provided further evidence or legal threats. Given SCO's fame at making broad IP ownership claims, I think it is noteworthy, even if the claim was baseless. Carltonh 17:15, 6 September 2007 (UTC)