Talk:C++/Archive 2

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

`#include <ostream>`, `#include <istream>`, and all that...

According to the standard, operator << and operator >> for ostream and istream are declared in the headers <ostream> and <istream>. <iostream> is not required to include those headers. To be strictly conformant, the code examples using stream input and output have to include not only <iostream> but <ostream> and <istream> as well. --Tobias Bergemann 09:19, 14 October 2005 (UTC)

You may be correct, but why do all books, including Bjarne's, use iostream? --MarSch 15:28, 27 October 2005 (UTC)

Certainly not all books. "Accelerated C++" doesn't, if I remember correctly. But this really is a very minor point, and I won't revert if anybody changes the code examples again.

The header iostream has to include the definition of class std::ostream in some way, but the streaming operators are free functions, i.e. they are not part of the class definition. The class definition of class std::ostream may well reside in a separate header file that is included from both ostream and iostream but this separate header file need not include the declarations for the streaming operators. (Strictly speaking, iostream and ostream don't even have to exist as real files. The language standard is carefully worded so that the phrase #include <iostream> in the source has the effect to make available a certain set of classes, functions, and objects. It doesn't have to really include a source file.) --Tobias Bergemann 08:17, 28 October 2005 (UTC)

Do you have a reference for your statement about the headers? --MarSch 13:14, 28 October 2005 (UTC)

The ultimate reference is, of course, the standard document itself. My copy is at my workplace, so I can't quote chapter and verse until monday. Other than the standard I can only refer you to a couple of usenet discussions, e.g. "Standard hello world problem" and "Defect: std::endl in (a) 22.2.8/5, (b) 22.2.8/11, (c) 22.2.8/13, (d) 27.6.1.3/22" from comp.std.c++ and "templates" from comp.lang.c++.moderated.

A more recent discussion of this topic on comp.std.c++: "Defect Report: examples missing #include <istream> or #include <ostream>". — Tobias Bergemann 08:12, 9 October 2006 (UTC)

In any case, most participants of the referenced usenet discussions (which included members of the standardization committee) apparently consider the current situation a defect in the standard that may well be fixed with the next revision. --Tobias Bergemann 20:06, 28 October 2005 (UTC)

Ah, I found a post by Bjarne Stroustrup himself to alt.comp.lang.learn.c-c++ about the problem. --Tobias Bergemann 20:16, 28 October 2005 (UTC)

I removed it again, and would like to see it stay that way. If it does not work for you, then you need a different compiler :)MadCow257 21:08, 3 March 2006 (UTC)

Nevertheless, a compiler could perfectly implement the entire C++ standard and still require you to include ostream, thus it should stay in the article until this defect in the standard is corrected. --Yamla 21:23, 3 March 2006 (UTC)

Apologies for treating this as a bad edit. What a bizarre bug in the standard. --ozzmosis 15:44, 26 April 2006 (UTC)

However, the code uses endl. Is that included in ostream? Furthermore, even so, it's better to use the inclusive iostream header to include all those things with one header file as this is the common practice for most programmers. --D e ryc k C. 16:34, 26 April 2006 (UTC)

I'm sorry, I don't recall where endl is. You can't just include iostream, though, because that doesn't bring in ostream according to the standard. You really do need to include ostream. Remember, we need the article to be correct. --Yamla 16:46, 26 April 2006 (UTC)

Correctness isn't the primary concern. We could just as well use printf instead of cout and that would still be "correct" in C++. The point of that section is more to show what a typical "Hello world" program is, and I don't think I've ever seen one include both ostream and iostream anywhere besides on this Wikipedia article. On the other hand, there are plenty of examples like these. That said, it's just a "Hello world" program, so I don't mind it being this way. –Tifego^(t)_{20:16, 26 April 2006 (UTC)}

That's a good point, but please note that if you don't include ostream, your hello, world program is incorrect. A properly standards-compliant C++ compiler would not have to compile it. On the other hand, if you do add ostream as well, ALL standards-compliant C++ compilers would have to compile it. Anyway, we aren't really disagreeing here. I agree that no known C++ compiler requires ostream; it's a failing in the standard. Nevertheless, I think we should leave that in the example. Perhaps we should add a comment? --Yamla 23:00, 26 April 2006 (UTC)

Sorry to be boringly real-world about this, but what has happened is that almost all of the major C++ compiler developers have figured out that it is a silly oversight of the standard, and made the << and >> operators available from <iostream>. So while it is incorrect, it won't ever actually result in a compile error. Including <ostream> in a hello world program listing in a general encyclopaedia article for lay readers for "correctness" reasons is just pedantry. Jon 11:35, 28 April 2006 (UTC)

The hello world code example has been changed twice to not include ostream and back since the above discussion. I have added a paragraph to the article to better explain the situation. I would like to add a sentence like "Most commentators and even Bjaren Stroustrup himself consider the current situation a defect in the standard that may be fixed in the next revision," but I only have the usenet discussions I mentioned above as references, and usenet posts are not citable by wikipedia's standards. — Tobias Bergemann 07:09, 25 July 2006 (UTC)

I agree that it might be fixed in the next revision of C++, but until that day comes shouldn't we use the standard? iostream already includes both o- and istream, including them again is not necessary. --65.92.105.13 22:44, 26 July 2006 (UTC)

But the standard does not say that iostream includes both ostream and istream. That's the whole point. --Yamla 22:49, 26 July 2006 (UTC)

<istream> and <ostream> are included in <iostream>, <iostream> includes <ostream> which in turn includes <istream>, also you could insert a line of code under the now single preprocessor which reads using namespace std; this way you wouldn't have to use the scope operator for cout, and endl. since nothng is more annoying that unneccesary scope operators...except maybe the default copy constructor —The preceding unsigned comment was added by 70.231.127.198 (talk • contribs) 03:24, 2 August 2006 (UTC2)

The standard generally does not define the inclusion relationships between the standard headers. It is very likely true that <iostream> includes <ostream> and <istream> in every existing implementation, but the point is that this is not mandated by the language standard. The Header iostream synopsis in 27.3 prescribes

namespace std {
  extern istream cin;
  extern ostream cout;
  extern ostream cerr;
  extern ostream clog;

  extern wistream wcin;
  extern wostream clog;
  extern wostream wcerr;
  extern wostream wclog;
}

Declarations of extern objects do not require complete types, so it is perfectly legal for a compliant implementation if #include <iostream> does not define the types istream, ostream, wistream and wostream, nor the manipulator std::endl. — Tobias Bergemann 07:34, 2 August 2006 (UTC)

Cleanup

Wikipedia is not a repository of links. This article is extraordinarily long and full of links, of which some are certainly not appropriate (it has crossed the Spam Event Horizon). Please pare down the links to only what is appropriate for an encyclopedia. --bmills 14:45, 16 February 2006 (UTC)

I decided to start being harsh with links. In particular I killed anything I felt was a) out of date, b) just links to things that look a bit like C++, but aren't or c) more suitable for the wikibook on learning C++.

As I expected, some things popped back in. http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm I would like to re-remove, but I'd perfer to talk about it. It claims to show how C++ maps to C. The problem is that the standard doesn't define how "C++ maps to C" so this ends up just being one person's belief on how they might go about implementing a C++ compiler. I know at least that the way is laying out functions bares little resemblance to how g++ goes about compiling C++ code, so I'm not convinced it is helpful.

I like your progress so far with the cleanup; you're definitely moving things in the right direction. As for the "mapping" link, have a look at this diff. That particular link was added as part of a pair from an anonymous DirecPC IP; checking other contribs from that IP reveals similar links at Session Initiation Protocol. I'd say that means it's linkspam, and thus safe to remove; if a comparison with implementation in another language is needed, we can always add actual content from a source that isn't out to make a profit. --bmills 18:34, 20 February 2006 (UTC)

Cleaned a few references, it just looks like a huge list of books. --vineeth 07:24, 27 February 2006 (UTC)

Standard Libraries

I recently replaced:

A project known as STLPort, based on the SGI STL, maintains an up-to-date implementation of the STL, IOStreams and strings. Other projects also make variant custom implementations of the standard library with various design goals.

with:

All C++ compilers provide an implementation of the C++ standard library. Compiler-independant implemenations, such as STLPort, also exist. Other projects also make variant custom implementations of the standard library with various design goals.

It was reverted by Ozzmosis as "inaccurate and unfinished". OK, I can see an argument the language could do with a little polishing, but I don't see that it was inaccurate. I don't know of any C++ compiler that doesn't ship with an implementation of the standard library, and I find for the most recent version of every compiler, their version is usually better than STLPort's. I feel the current wording implies STLPort is worthy as a "better implementation", whereas libstdc++ (g++'s implementation) or Dinkumware's (the verson packaged with vc++ and icc) are considered better by many people. Anyone want to suggest different / alternative wording? Mrjeff 11:11, 27 February 2006 (UTC)

The problem with asserting that "all C++ compilers provide" is that you really don't know this for certain. It's possible for someone to write a C++ compiler that doesn't provide any standard libraries, eg. for an embedded system. Also, OpenWatcom C++ is one compiler that comes to mind that has only recently provided a very basic and incomplete STL implementation. See http://www.openwatcom.org/index.php/Open_Watcom_STL . The "unfinished" comment was my mistake as you left out a colon before the list and I misread the diff. --ozzmosis 12:44, 27 February 2006 (UTC)

Ah, you think you've used most of the C++ compilers under the sun, and up pops another one :) I'll re-think how I'm going to change that section, and have another go :)

Why not just replace "all" with the weaker "many"? Presumably you can cite a fair number of compilers with STL implementations, and just about anything you could say has less POV than an STLPort ad. —donhalcon^〒 14:56, 27 February 2006 (UTC)

:-) Watcom C++ is pretty old now. Anyway, I've copyedited that paragraph so hopefully it's now a bit more accurate and unbiased. I used "most"! --ozzmosis 15:57, 27 February 2006 (UTC)

I would suggest to replace "all" by "all standard conformant" or something like that.

A move and/or cleanup

Per the peer edit and the preferable article size policy, something needs to be moved out. I propose that a new article bad made called Syntax of C++. This would significantly reduce the size and technicality of this article, while giving more space for the rest of it too expand if needed. Thoughts? MadCow257 03:31, 5 March 2006 (UTC)

The article has a lot of excess content; the "references" and "external links" sections could still use some trimming. Most of the "sample code" examples are also significantly longer they really need to be; the "polymorphism" section is very confusing (the basic idea gets across, but the details are muddled), so it might be good to clean that up and trim it down. Just some ideas for keeping the article size under conrol. —donhalcon^╤ 05:04, 5 March 2006 (UTC)

MadCow257, I don't think moving the whole Syntax section out would be the right thing to do, because the Syntax section isn't really a section on Syntax at all; as it is now, every single section inside Syntax is not about syntax. Instead, I propose that "Sample Code" be moved into C++ examples (with a link to C++ examples remaining as the only thing in the "Sample Code" section) and that the "Syntax" header be deleted entirely until there is some section of the article that's really about C++ syntax, rather than sections that are about features of C++ which happen to show examples of syntax. --Tifego 02:28, 11 March 2006 (UTC)

I went ahead and reorganized the article a little bit, but I didn't move anything out yet so it's still too big. The sample code should probably be moved or drastically shortened. And the section on Polymorphism really needs work. It has a big chunk of example code that is confusing and could be replaced with a couple of sentences, it tries to cover too many topics at once, has no clear focus, etc. Also, it only mentions templates sort-of in the passing, but they are a very important part of polymorphism in C++ and at least deserve their own subsection to emphasize that. --Tifego 03:34, 11 March 2006 (UTC)

I would suggest the name C++ syntax for the child article, along the same lines as C syntax and Java syntax. – Doug Bell ^{talk•contrib} 12:13, 12 March 2006 (UTC)

The move from "C++" to "C++ programming language"

I (mildly) oppose the recent move of the article from C++ to C++ programming language. From Wikipedia:Naming conventions (languages):

Languages which share their names with some other thing should be suffixed with "language" in the case of natural languages or "programming language" in the case of programming languages. If the language's name is unique, there is no need for any suffix.

However, the convention also states (using VBScript as an example of a language name where no disambiguation is needed):

Similarly, please place a redirect to VBScript at VBScript programming language and also at VBScript (programming language).

It is no big deal either way, and I won't revert the move. —Tobias Bergemann 10:16, 12 March 2006 (UTC)

I agree - see Fortran, PHP, and Smalltalk for other examples of languages that don't end in "programming language". The move's only justification was that it was for consistency, but it's not consistent by those naming conventions. --Tifego 11:20, 12 March 2006 (UTC)

I moved the article in this case for consistency with the other programming languages named after a letter. I don't know if the comparison to Fortran, PHP, and Smalltalk is an apples-to-apples comparison because the name C++ is, well, not much of a name by itself. Since Stroustrup himself calls it the "C++ programming language" (and named his book the same), I think the argument can also be made that that is the actual name of the language. However, if there is a strong consensus to change the name back, I'm not going to lose sleep over it. – Doug Bell ^{talk•contrib} 12:13, 12 March 2006 (UTC)

If the scope of this encyclopedia were limited to computer programming related things, I would say the title "C++" is better than "C++ programming language". But it isn't. So, despite me finding the latter a bit clumsy, I think the longer title is true and correct. I took a look at the current ISO Standard. Its name is "Programming languages — C++" (ISO/IEC 14882, second edition 2003-10-15). The first sentence in the intro of the standard reads "This International Standard specifies requirements for implementations of the C++ programming language." I think the situation as it is now is perfect (article name = "C++ programming language" and a redirect to that under the name "C++). --Adrian Buehlmann 18:48, 12 March 2006 (UTC)

OK, I'm convinced, although this means sort-of ignoring the Wikipedia:Naming conventions (languages). --Tifego 04:02, 13 March 2006 (UTC)

However, C++ is a more commonly known and widely used name when compared to C++ programming language. Similarly, PHP is not at "PHP: Hypertext Preprocessor" and RuBisCO is not at Ribulose-1,5-bisphosphate carboxylase/oxygenase, because the naming convention says that the most widely used name should be adopted. C programming language and Pascal programming language etc. have the words "programming language" appended to the article name only because the omission of them creates ambiguity - simply "Pascal" can refer to the person Blaise Pascal, and simply "C" would make others think you're talking about the letter. But C++ cannot mean anything else - it MUST mean this programming language. Therefore I strongly propose a moveback. --De ryck C. 09:02, 13 March 2006 (UTC)

Needs cleanup

I think this article is waaaaay too big for Wikipedia. All those "syntax", "operator" etc. stuff can be done away with. Section 7 -- the whole thing -- is IMO not Wikipedaic. We should link to tutorials, not write one ourselves. People come here to <learn about> C++, not to <learn> C++. If everyone agrees, someone should step up and do some *major* cleanup.

I removed the STL code examples; I don't really think we need them. Loads of programmers I know don't even use the STL. Jafet.vixle 03:44, 13 March 2006 (UTC)

Looks like a step in the right direction. Everything after and including the "Incompatibility with C" section in this article is still way too long, though (as you said). I believe everything that's in the "Language features" section (and a few things that aren't) deserve an entry there for being very relevant to C++, but each subsection should either be much shorter, or consist of a link to another article that covers the topic in more detail. "Sample code" has a lot of description in it, someone should decide how much of that is really notable information. The section on Input/output streams in particular looks like a waste of space considering that io streams were already used in an example above that. --Tifego 03:59, 13 March 2006 (UTC)

Also, this talk page is getting way too large, somebody should archive all but the newest few topics. --Tifego 04:05, 13 March 2006 (UTC)

I moved discussions older than about january 2006 to Talk:C++ programming language/Archive 1. —Tobias Bergemann 13:46, 13 March 2006 (UTC)

Move back to C++?

The following discussion is an archived debate of the proposed move of the article from C++ programming language to C++. No further edits should be made to this section.

The result of the debate was ~~speedy~~ move by Deryck C. --Tifego 04:15, 19 March 2006 (UTC)

Previously Doug Bell moved this article from C++ to C++ programming language (see discussion above), and there was a dispute concerning his act with no conclusion drawn. I would like to propose a moveback of this article to C++, because:

C++ is a more commonly known and widely used name when compared to C++ programming language. Similarly, PHP is not at "PHP: Hypertext Preprocessor" and RuBisCO is not at Ribulose-1,5-bisphosphate carboxylase/oxygenase, because the naming convention says that the most widely used name should be adopted.
C programming language and Pascal programming language etc. have the words "programming language" appended to the article name only because the omission of them creates ambiguity - simply "Pascal" can refer to the person Blaise Pascal, and simply "C" would make others think you're talking about the letter. But C++ cannot mean anything else - it MUST mean this programming language.
Wikipedia: Naming conventions (languages) reads Languages which share their names with some other thing should be suffixed with "language" in the case of natural languages or "programming language" in the case of programming languages. If the language's name is unique, there is no need for any suffix. We should conform to these rules.

--De ryck C. 04:56, 15 March 2006 (UTC)

I agree with you Deryck, except for one thing. "C" is very commmonly used with "programming langauge", even among experienced coders. I've never heard anyone call C++ "C++ programming langauge" in my life. Point is C is not only called c programming because of ambiguity, but because that's its name. The same does not apply to C++ and it should remain C++. Not really a big issue though with the cheapness of redirects... MadCow257 23:30, 15 March 2006 (UTC)

Just curious, but did you look at the previous discussion above regard "ever hearing it called "C++ programming langauge"? – Doug Bell ^{talk•contrib} 01:07, 16 March 2006 (UTC)

Yes, I have, and there is more opposition then support there. I do realize that Wikipedia is not a democracy though. These kind of issues are small and numerous, the best policy would just be to leave them alone (why not make the major issues better first), so it was pretty disappointing when I saw it get moved to c++ programming language. As for Bjarne's book, let me make an analogy. C++ Programming Langauge :: Direct3D Graphics Programming. You would most likely not have a book called C++, nor a book called Direct3D. The longer version is not the name of the langauge, but the name + a description MadCow257 03:10, 16 March 2006 (UTC)

And you never call this place "Wikipedia the free encyclopedia". If no more oppositions I think undoing the move is what I'd do. --De ryck C. 04:25, 16 March 2006 (UTC)

I slightly prefer it this way (C++), but wouldn't care much either way. --Tifego 06:06, 16 March 2006 (UTC)

I could understand using C++ Programming Language if there was a C++, the species of fruit bat to distinguish it from, but since there isnt...? Jon 03:20, 19 March 2006 (UTC)

"using namespace" is bad?

It's written in this article that "some considers using namespace as bad programming practice", and placed down an "citation needed". I wonder is it so much of a bad practice that there can be sources citing it? --De ryck C. 02:07, 19 March 2006 (UTC)

I noticed that edit, and it's not really acurate. Maybe it should be reverted? MadCow257 02:09, 19 March 2006 (UTC)

"Some", IMO should really be true. You can't argue that nobody thinks it's bad. But citation is not needed. --De ryck C. 02:17, 19 March 2006 (UTC)

I recall reading it in either Stroustrup's CPPPL, or one of the Meyer or Bruce Eckel books. The idea is that std is such a large namespace that importing it wholesale could be a bad idea. Personally I don't think it's such a bad idea, but what I do is use using namespace std while sketching code and then change it to several using std::cout (etc) statements as it solidifies. Jon 03:07, 19 March 2006 (UTC)

The argument against using an entire namespace is that it essentially circumvents namespacing. However, that can also be an argument for it (i.e. namespaces are annoying and deserve to be circumvented). --Tifego 03:11, 19 March 2006 (UTC)

In my programming practice, I use some 20 std:: functions. If each of them has to be implemented with the "using" keyword, the code would be drastically big. --De ryck C. 07:26, 20 March 2006 (UTC)

It's just 20 lines of code, how is that drastically big? –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

The entire code is only 100 lines long. --De ryck C. 07:47, 20 March 2006 (UTC)

Oh, I'm more used to dealing with 10000+ lines. It still doesn't matter though, it's not like "using" can possibly makes your code less efficient. If you had said "it would be drastically inconvenient" instead of "the code would be drastically big" I'd only have agreed. –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

I usually program for competitions, and the longest program is <1000 lines long. --De ryck C. 08:14, 20 March 2006 (UTC)

Anyway, this is getting way off-topic. I can't find any good references for "using namespaces is bad", only mentions of older programming books saying it's bad, and I don't have any such older programming books to check. Google searches that find anything relevant mostly come up with people saying it's bad (in some forums), but that's no reference. –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

What a pity that nobody publishes them from the forum to the site. --De ryck C. 08:54, 20 March 2006 (UTC)

My CS311 teacher says to avoid it ("namespace pollution"?). An article here says it's not necessarilly bad but should be avoided --DevastatorIIC 10:01, 20 March 2006 (UTC)

Added the link there in the using namespace explanation and did a bit rephrasing. --De ryck C. 10:15, 20 March 2006 (UTC)

Reference / External links cleanup

I noticed that a cleanup tag was put onto the Reference and External links sections some weeks ago. From my peek into the links, nearly all of them are, to some extent, relevant to this article. I'd like to seek some collaboration on the criteria on what kind of external links and references should be kept and what to be removed. --D e ryc k C. 14:42, 24 March 2006 (UTC)

To me, those don't even seem neccesary anymore. I've gone through all of 'em and they are relevant. There isn't any specific policies so is the problem that there's to many? MadCow257 23:33, 27 March 2006 (UTC)

After reviewing the wikipedia style guide for linkage, the external links section is in conflict with none of the points. Therefore I have removed that tag, and am considering doing the same for references. Only about 1/8 of the article is the See Also section and on, which should be appropriate for something as broad as c++.MadCow257 02:54, 30 March 2006 (UTC)

I went ahead and did it, but the references is a little less clean. Compared with how it looked when the tag got placed though, problems can be dealt with specifically now

Peer Review

I took it off peer review because it'd accumulated enough things and was near the bottom. Hopefully someone else can clean up polymorphism because I don't have any experience with it :( Maybe we could strike through the bullets in the review as they're done, what's the wiki code for strikethrough? MadCow257 23:37, 27 March 2006 (UTC)

don't know about wikicode, but you can use the html del tag.--MarSch 13:24, 29 March 2006 (UTC)

the code is < s > < /s >, and I've striken through what's been done MadCow257 22:55, 29 March 2006 (UTC)

Polymorphism

I made an attempt at cleaning up the polymorphism section. I think it still needs some work (so, somebody please look over it), but at least it's not so incredibly long anymore. –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

Classes

Added a bit more that cleared the concept of them up, becasue when I learned it it was very difficult to understand.

More tagging

The sample code section has a cleanup tag. Can anyone say more specifically what about it needs to be cleaned up? Also someone put an Article with off topic sections tag, what's that about MadCow257 02:43, 31 March 2006 (UTC)

You answered your own question, almost. The cleanup tag does say specifically that the reason it needs to be cleaned up is because it's off-topic. The examples were too numerous and there's already a page for C++ examples, at least at the time that tag was added. Basically the article as a whole was too long and that section got tagged as a candidate for shortening. Looking at it now, what I think is wrong is that there's overlap (in terms of what information they teach) between "minimal program" and "hello world", and overlap between "hello world" and "input/output", and all three sections contain not-very-important-to-C++ stuff in them (for instance, EXIT_FAILURE and what file it's defined in). –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

I trimmed it down and removed the tag. –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

Critisms section

This article could benefit from a section on criticisms, but I think the one that was added needs a bit too much work to be in the article in its current state. It ~~comes across as very one-sided, for one thing. If there is a section on criticisms, there should probably be an accompanying section on praises. Also, it~~ begins with It is commonly said that "It's easier to shoot yourself in the foot with C, but when you do it with C++ you blow your whole leg off". But this quote is incorrect, not attributed, taken out of context, and not very encyclopedic to introduce a section with such a statement. Each of the criticisms should be properly attributed to somebody or given a link to a reference that expresses that view, and not stated as if the negative points were all actualities. The "implementations" section was most fleshed out, but also completely uncited. (I realize I also added some stuff here that was uncited, but that was factual information about the language, not a subjective issue of criticism, and was strictly as a rewrite of other already-uncited material, not a new addition of it.) –T_if_eg_o^(t) _{00:46, 20 March 2006 (UTC)}

I understand that the section needed possibly too much work to be worth including at the moment, but some of the others reasons aren't important. The quote came from http://public.research.att.com/~bs/bs_faq.html#really-say-that, and C started out with a section of it as well. Its crisicm, so as long as all of the things are really said, then it can be as POV as it needs. I did a citation too, in the resource section. I guess you've insipired me to right up a better version in Word though. Besides philosophy, this is like the most important section and C++ doesn't even have one which is why I put it up in haste MadCow257 15:41, 1 April 2006 (UTC)

That link you gave says the quote slightly differently than the one you added, but more importantly, it also says that it was not a criticism of C++ in particular, and that it is taking it out of context to state it as such, so while it is relevant to the criticism of C I am not sure it is relevant to the criticism of C++. As for it being POV, the problem was mostly just a matter of wording—it sounded like it was stating things such as "it's too hard to learn" as fact, when you really meant they were the opinions of some person or group of people. And for citations, the external link should also appear right there in the article after the claim.

–T_if_eg_o^(t)_{01:22, 2 April 2006 (UTC)}

The changes in the new version are kind of dissapointing, I think we should follow the model set by Java - [1] They use bullets, and don't remind the reader every 5 words that the Critiscm section doesn't apply to all people's opinions MadCow257 03:19, 9 April 2006 (UTC)

By all means; that criticism section looks well-done. But the previous C++ criticism section was nowhere near as good or neutral-sounding as that. –Tifego^(t)_{19:24, 10 April 2006 (UTC)}

And there should be more material in the section before that's really possible. The list of criticisms that was up there before (the second one) was entirely meaningless, or at best poorly-articulated. The criticism for Java generally states and explains specific facts (Java failed to deliver such and such feature, Java is slower at this because of so and so) whereas the C++ criticisms before said vague things like "multiple inheritance can be avoided" or "code is longer then it needs to be". The latter of those is far too general and the former does not even qualify as criticism at all. (The other two criticism points were about linkers and appeared to be have no basis in fact.) –Tifego^(t)_{19:36, 10 April 2006 (UTC)}

C+ redlink

The article has a redlink to a C+ programming language. Does anybody know what this should really be? My best guess is that it means ABCL/c+, but I'm not all that sure about it. –Tifego^(t)_{05:12, 8 April 2006 (UTC)}

Easy tutorials

Why they are removed ? —The preceding unsigned comment was added by Alhoori (talk • contribs) .

There are at least 5 links to tutorials in the external links here. Is that what you were looking for? –Tifego^(t)_{06:00, 19 April 2006 (UTC)}

I deleted two links before, and deleted them again. I'm sorry, but these tutorials are not of high quality, and in particular are almost entirely C rather than C++ (why does the 'strings' section talk about arrays of chars instead of std::strings for example). Only a very small number of tutorials can be linked to from wikipedia. Sorry. Mrjeff 09:37, 19 April 2006 (UTC)

std::strings are nice, but there's nothing inherently non-C++ about char* either (and IMO they're important for C++ programmers to at least know about since they will probably have to deal with them sometime). However, the first of those two links is to an entirely-C tutorial that said so, which makes it basically linkspam here, and the second one isn't very high-quality and says little about C++. –Tifego^(t)_{16:42, 19 April 2006 (UTC)}

(OT) Compilers question

Does anyone know of a C++ compiler that uses a binary file format? I've been given a file, supposedly a C++ with QT app, that I'm supposed to compile, but it's binary and has the extension .m4 (which I would have thought would refer to the m4 macro processor, but I've been told not). Anyone know about it? — mæstro ^t/c, 10:55, 11 May 2006 (UTC)

Did you check here for what .m4 might mean? –Tifego^(t)_{16:58, 18 May 2006 (UTC)}

Wikibook

I added a link to wikibooks:programming:c++. I think that links like this will result in improvement in wiki-books, and will result in usable reference manuals, unlike what wikibooks are now (i.e. incomplete). 24.210.73.62 22:41, 14 May 2006 (UTC)

Remove Tutorials links

Why someone removed the useful tutorial link http://www.alnaja7.org/Programmer/102/itcs_102.htm ? can he/she give use better links ? Many suffered until find the right information in the right time , but some people don't like this ! Alhoori 01:22, 21 May 2006 (UTC)

This has already been discussed in your talk page. OhNo itsJamie ^Talk 03:12, 21 May 2006 (UTC)

I asked the members to decide that , and your reasons what not reasonable ! Alhoori 09:16, 21 May 2006 (UTC)

I previously commented on this. It is my belief that these articles do not sufficently cover good C++ practice. As a general rule, I think you should try to only insert links to sites you have no personal connection with. I have tried to do this, as it avoids the quite strong and reasonable urge to link to things which I have written wherever possible. Mrjeff 17:23, 21 May 2006 (UTC)

Steve Heller's book

Free book "C++: A Dialog" is "not recommended" by accu.org review [2]. Based on this I removed it from the list. Pavel Vozenilek 04:55, 27 May 2006 (UTC)

Books and references sections

These sections need radical overhaul:

references should not start with Abrahams' book - this one describes the most esoteric aspects of C++. Having surname starting with "A" is not a privilege be always the first.

Current trend in C++ books for novices is to start with useful C++ tool and only much later reveal the old C roots. Such books are now missing or hidden (Lippman, Koenig, Glassborow's "you can do it"). The "The C++ Annotations" online book expects prior C knowledge. Even if free it should not be recomended, unless explicitly labeled as transition from C.

Two of books present are quite negatively reviewed in accu.org: Oualline's review, Malik's review. Pavel Vozenilek 05:15, 27 May 2006 (UTC)

Good catch, I've removed both Oualline books and the Malik book. Even if they didn't have bad reviews, there is nothing to recommend them as especially important books about C++. --MarSch 10:33, 29 May 2006 (UTC)

"Minimal program" error

While reading the section of the article labeled "Minimal Program" i came to a realization. The program that is listed is fundamentally flawed. The main() function is described of being of the type 'int'. this means that the function must by default return a value to the processor that is compatable with the type 'int'. The program displayed, however, does not meet this prerequisite. if you input this program into any compiler, it would instantly give you an error message, something along the lines of "function int main() must return type int." to rectify this situation, i would suggest adding the line

 return 0;

to the area in between the

{ }

Ex.

{

 return 0;

}

Nimnengil 00:31, 31 May 2006 (UTC)Nimnengil

The language standard guarantees an implicit "return 0;" for the main function. Quoting ISO/IEC 14882:2003 3.6.1/5: "If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;." This is already explained in the article in the paragraph succeeding the "minimal program" example. — Tobias Bergemann 07:50, 31 May 2006 (UTC)

VC6 returns "void" by default (at least that is what it is telling me with its warning), so evidently it is one of those newer things in the standard (well, if you consider "newer" in the last 8 years, heh!). This is besides the point though, because it seems like a totally pointless example - if I came across a program like that (because in real life you probably would want to comment that thing, and of course after commenting it you've defeating the whole purpose of not returning anything) it would terrify me (erm, just being pedantic - heh!) - but hey, people must like it I guess :). RN 08:23, 31 May 2006 (UTC)

As far as I know, the implicit return for the main function was indeed introduced with the 1998 C++ standard and is not part even of the latest C standard. However, the int return type has always been (again as far as I know) the only standard conforming return type for main, both in C++ and in C. Quoting ISO/IEC 14882:2003 3.6.1/2: "An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. [...]" — Tobias Bergemann 09:15, 31 May 2006 (UTC)

Training Providers

I just removed the following two links. I don't think there is any need for links to >$2,000/day training courses. If anyone wants to argue the case, feel free to do so. http://objectdiscovery.com/C++.php 5 day C++ training http://www.bdsoft.com/ C++ training geared towards programmers Mrjeff 16:57, 7 June 2006 (UTC)

external links

Hi all -- You might want to be aware of a situation with an anonymous user who is inserting external links to his site at vias.org into various articles. He seems to take online, copylefted books, and mirror them on his own site, with ads. There's nothing illegal about what he's doing, provided he complies with the terms of the license, but I think it's more appropriate to link to the version of the book on the author's own site. This happened in this article with Downey's book, and I've changed the link so it points to the copy maintained by Downey himself.--Fashionslide 21:17, 15 June 2006 (UTC)

Example code

Ok, please correct me if I'm wrong (no C++ pro), but check the following code: __

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

___ This is how I should write it. You need the pasue, or the "Hello world" would just flash by. But why write it like it's done in the article? Looks more complicated... Cybesystem 23:49, 9 July 2006 (UTC)

It's true that if you run the program, without it being in a terminal, the "hello world" will just flash by. However system("pause") won't work on lots of computers, and definatly isn't standard C++, as it assumes you have a program installed called pause. I often write C++ on computers that don't have a pause command :) The whole "Should you include ostream" problem is a big one. There are a few compilers where you have to include ostream, but the ones most people use (in particular g++ and Microsoft C++) don't require it, as they put ostream in iostream. It doesn't hurt to put the header there however. The toss-up between "using namespace std" and "std::cout", "std::endl" is the kind of thing that wars are made from, and I don't think either in this example is that much better than the other, so I would just leave it as it is :) Mrjeff 11:18, 10 July 2006 (UTC)

More specifically, the system() function only works on Windows computers, by sending the command within system("") to the console (ie. DOS). There is, however, another way around this: using std::cin.ignore(). This has its drawbacks though, if you use std::cin >> variable before using std::cin.ignore, the program will just pass the ignore statement by. --65.92.105.13 22:48, 26 July 2006 (UTC)

No, system() itself works fine e.g. on UNIX (where it originated). But pause is not a UNIX command (and not part of C++), and the standard basically allows system() to do whatever it wants with its argument (the behaviour is implementation-defined) --Stephan Schulz 09:03, 28 August 2006 (UTC).

Language features section

Templates are currently only discussed under the polymorphism header --I added a short sentence and a reference to the template metaprogramming article-- but since they are a large, complicated, sophisticate and for some even controversial feature, should be discussed in its own section. Mikademus 07:30, 25 July 2006 (UTC)

Added a "preprocessor" section with subheaders for macros and templates. Mikademus 21:13, 25 July 2006 (UTC)

"Old problems"

I really don't like this title - it seems like a way to shove off criticisms of the language. AT THE VERY LEAST export is absolutely not an "old problem" - it says it right in the article that it is not. Basically none of the major compilers implement it yet, it has been in the standard for something like SEVEN YEARS, and a lot of the current books refer to it. Plus there has been an insane amount of controversy over it, including that one rather infamous paper by Herb Sutter from Microsoft and someone else. RN 01:51, 26 August 2006 (UTC)

Actually a few major compilers do support it now, but I agree it's still a mess and also a number of other compilers (g++ in particular) seem to have little interest in trying to implement it, and there is a good chance it will be scrapped and replaced with something else in C++0x I believe. Mrjeff 19:50, 26 August 2006 (UTC)

Thanks for your comment :) - and right - as far I know all EDG-based ones do a.k.a. borland and comou. Microsoft, in their statements anyway, seems committed. Like you say though, as far as I know the thing could get axed entirely, or perhaps templates or something similar will all be "exported" by default or the like. Hmm, maybe one idea would be to make a daughter article for the C++ standard stuff if there isn't one already... I'm sure that would extend pages.... RN 09:38, 28 August 2006 (UTC)

#include <ostream>, #include <istream>, and all that...