Talk:C++/Archive 4

This is an archive of past discussions about C++. 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

→

appropriateness of external link

On March 12, I added the following external link:

List of books and tutorials about C++

User:Yamla (an admin) removed a link, called it vandalism and told that if I'll continue "spamming", I will be banned.

The page is a list of links to 50 C++ related resources. Of them, 41 are free books or documents about C++ which are opened in the browser (without registration or anything else, and without any amazon.com links). For 9 others, there is a choice of reading them in the browser (also freely) or buying them from amazon (links to amazon contain refid).

Please comment about

whether this link is appropriate
whether you think that adding this link constitutes spamming or vandalism

My personal opinion is that my link was very good and useful. After careful reading the Wikipedia:External links document (I read it three times), I still believe that there is nothing wrong in adding this link.

--Urod 05:00, 17 March 2007 (UTC), updated --Urod 05:08, 17 March 2007 (UTC)

Third opinion

I strongly suggest that you talk it over with Yamla first. Ask Yamla to elaborate on why they deleted your link. As for me, I think that it is appropriate as a link. It contains a nice amount of information that you might even want to use to cite. bibliomaniac 1 5 05:20, 17 March 2007 (UTC) (moved this into the previous section --Urod 06:10, 17 March 2007 (UTC))

Thank you. --Urod 07:01, 17 March 2007 (UTC)

Yamla wrote that this site satisfies criterion 4 for exclusion in WP:EL ("primarily exist to sell products or services"). I personally doubt this. --Urod 16:16, 17 March 2007 (UTC)

I have restored the link, which I find more informative than the following 3-4, and suggest that one of those be removed instead, please. AnAccount2 21:19, 17 March 2007 (UTC)

I just noticed this section. I reverted the link previously. My edit comment sums it up: "link spam; does not pertain directly to C++; exists only to promote ads and amazon referrals; adds no information; see User_talk:Yamla. please stop spamming." This solidly falls under links to be avoided, in my view. Yamla appears to agree. Xerxesnine 21:48, 17 March 2007 (UTC)

I have independently evaluated the link in question, and found it to be far more informative than at least three of the existing links. I have replaced it. I object to being unjustly characterized as a link spammer. I have no affiliation with freecomputerbooks.com or any of the parties in the dispute about its external link on C++. That it is ad-supported or referral-supported has no bearing. Tens of thousands of our external links are to such ad-supported sites. AnAccount2 22:14, 17 March 2007 (UTC)

Are you sure you aren't just a sockpuppet of Urod (talk · contribs)? --Yamla 22:17, 17 March 2007 (UTC)

I have no sockpuppets. Please check my IP if it is possible. (I don't know technical details about IP checking in wikipedia and who does it.) --Urod 22:54, 17 March 2007 (UTC)

From User talk:Yamla: C++ texts from freecomputerbooks.com

Thank you for your message.

I am concerned about your apparent inability to assume good faith, your accusations of spamming which upon independent review I have found unjustified, your apparent lack of reluctance to bite an obvious newbie with a final warning after what I believe to be an unjustified accusation of spamming, and your hastily withdrawn accusations of sockpuppetry against me.

You have asked me to evaluate http://freecomputerbooks.com/langCppBooksIndex.html in terms of WP:EL. I have done so. I find that adding it to C++ would be a service to our readers because it:

is more informative than at least three of the existing external links in that article;
has merit, linking to dozens of free references, tutorials, and guides;
is at least as accessible as any page rendered in Wikipedia's monobook style;
is clearly appropriate to the article;
has a well-articulated copyright policy, allowing submissions of only free materials and providing a means for copyright holders to remove their material if it appears on the site;
is supported by advertising and referrals, as are tens of thousands of our existing external links. This fact alone does not prohibit its exclusion under WP:SPAM or WP:COI;
provides unique resources beyond what the article would contain if it became a featured article;
does not mislead the reader by use of factually inaccurate material or unverifiable research;
is not mainly intended to promote a website;
does not primarily exist to sell products or services -- although it is ad- and referral-supported, those links are few and sparse in its text, and again, these sorts of compilations are not at all uncommon in our articles;
does not have objectionable amounts of advertising -- I count less than ten referral links and zero direct ads on the linked page, spread among dozens of useful resources;
doesn't require payment or registration;
works on all Mac and PC browsers, and my Nokia 9300 phone;
doesn't require Flash, Java, or other external applications;
isn't a search engine link or aggregated search engine results;
is not a social networking sites, discussion forums or USENET (which I might add is included in the article's external links); and
is not a blog, a personal web page, or an unestablished open wiki.

Based on this determination, I will continue to replace the link in the article, and I will encourage others to do so as well.

If you are truly concerned with keeping the external links in C++ to a minimum, won't you please consider removing one of the links to a single reference manual or tutorial instead of the link in question, providing a collection of such works?

If you disagree with my decision, I encourage you to establish an RFC on the topic. Thank you. AnAccount2 22:57, 17 March 2007 (UTC)

I agree that it makes more sense to link to a big list of freely available books, then to have multiple links directly to freely available books. Unfortunately the free book site that is the object of this dispute seems to be horribly broken. Therefore I propose the creation of List of freely available C++ books and link to that in "See also" section. --MarSch 10:19, 18 March 2007 (UTC)

Broken in what way? It works for me. I have reviewed about 15 of the free works linked, and found them all to be high quality. AnAccount2 07:18, 19 March 2007 (UTC)

Enough, please

This is a straightforward case. There are thousands of "middlemen" sites which exist as referrals to other sites; amazon referrals, which appear in the site in question, are particularly common. Why did you pick freecomputerbooks.com and not one of the thousands of other sites? Why not give a link to Froogle, for example? What is so special about freecomputerbooks.com? Why are you being so persistent about that site? Why have you devoted so much time to promoting it on the C++ page, on this talk page, on Yamla's page, and on my page?

On Yamla's page you wrote, "...Based on this determination, I will continue to replace the link in the article, and I will encourage others to do so as well." You then proceeded to revert yet again. Yamla is an admin. Please review the responsibilities of Wikipedia admins, as you appear to misunderstand their role in relation to yours.

In summary, please stop these shenanigans. Thank you. Xerxesnine 17:48, 18 March 2007 (UTC)

Yamla specifically asked me to review the link in question relative to WP:EL. I have done so, and I have made my decision. Administrators are not given higher authority about what to include in the encyclopedia -- there is no special role that gives them a higher authority with regard to content. The link is far more informative than the two individual free books which I replaced with it. There are no free books on C++ available from Froogle. Again, I will continue to include the link for the many reasons listed above. AnAccount2 07:18, 19 March 2007 (UTC)

You didn't answer the crucial questions above. Froogle was just an example of the online resources available for someone who wishes to buy a C++ book. Why would someone use the amazon referrals at freecomputerbooks.com rather than use Froogle or amazon.com directly, for example? For free online C++ books, why not just do a google search? Unless you can provide reasonable answers to these and the above questions, it is obvious link spam. And please stop gaming the 3RR. Thank you. Xerxesnine 15:51, 19 March 2007 (UTC)

Please note also that administrators are empowered to enforce Wikipedia policies. --Yamla 16:02, 19 March 2007 (UTC)

Additional opinion

I came here because of the note at Wikipedia:Requests for comment/Maths, science, and technology about including the link to freecomputerbooks.com. There ought to be a consensus on a Talk page that any particular external link belongs in the article. I don't perceive such a consensus here, so I believe that the link should stay out. Also, at present there are 16 external links in the article (even without the new one being discussed) and that's probably too many to exist in a Featured Article, should this one ever want to pass those criteria. Regarding the merits of this particular link: a Google search for 'C++ books' gets 26.6 million hits, including many to free download sites, suggesting that there is no burning need for our readers to be sent to this particular site lest they find no relevant books. Reverting other users repeatedly to insert a controversial link, without a clear Talk page consensus that it belongs, seems to me like uncooperative behavior. EdJohnston 17:20, 26 March 2007 (UTC)

My RFC Conclusion: Reinstate

Finding this page through the RFC page, I have decided to add my input (having no prior involvement, and desiring no further involvement). I have read the comments on this talk page and the appropriate Wikipedia guideline (WP:EL). I conclude that the link should be reinstated. I trust my responses to the challenges against the link will be complete enough to support my conclusion. Following are the challenges and responses associated to the RFC regarding the link:

Challenges

It falls under exception #4—Links to sites that primarily exist to sell products or services
The editor seems to like this link above others
Consensus was not met for addition

Responses

I count two "advertisers" (links to Google-related sites, and amazon.com links) on the site in question and ten (i.e. Etrade, Vonage, Samsung Blackjack, etc.) on the NY Times main page. If the New York Times website is a reliable source with its several advertisers, this link, with less advertising, cannot be construed to fall under exception #4 and therefore is an appropriate external link. The primary purpose of the site seems to be to give a free online resource, secondarily some links may lead to selling sites. NOTE: Having found the main site, it has potential to be used as an external link on any number of Wikipedia pages.
Here is the situation: (a)An editor adds a link; (b)it gets deleted; (c)he replaces it; (d)he then gets accused of some nefarious affinity to the specific link above all others. That just doesn't seem fair! The whole RFC is whether this link should be included in the article. How then does it make sense to accuse an editor of repeatedly referring to it and none else? Also, in making this unfair accusation, other sites were suggested: Google and Froogle. These really are sites that primarily exist to sell products (exception #4). How are lists of books for sale (also falling under the WP:EL exception #9) better than a number of books that can be read on the web for free?
My answer regarding this good faith link is almost an exact quote (deviations in bold) of the consensus argument by Ed: There ought to be a consensus on a Talk page that any particular external link doesn't belong in the article. I don't perceive such a consensus here, so I believe that the link should stay. In other words, the consensus argument cannot be applied successfully to ONLY one side.

QED

—Red Baron 22:17, 13 April 2007 (UTC).

In your conclusion, by replaced you seem to mean reinstated and you seem not to mean removed or indeed replaced _by something else_. Is that correct? It is quite unclear. --MarSch 10:20, 14 April 2007 (UTC)

Correct, has been corrected, thanks—Red Baron 14:39, 16 April 2007 (UTC)

Revised again per comment by Xerxesnine.—Red Baron 16:09, 17 April 2007 (UTC)

The Actual Challenge

You did not mention the what the actual challenge was:

What exactly justifies the external link? What is that mysterious something, that je ne sais quoi, which freecomputerbooks.com provides that a simple google search cannot?

I still await the answer. I wonder, what will the new spin be this time?

I also have a few challenges directed at the author personally. These are incidental; in no manner should they be considered in lieu or before the actual challenge above.

Why is Rjakew trying to pass himself off as Red Baron with a wiki-link trick of Red Baron?
The initial dispute began on 12 March 2007 when the link in question was removed by User:Yamla. On the same day, a petulant complaint about the removal was added to Yamla's talk page. On 15 March 2007 an account named Rjakew was created, the author of this RFC who goes by the name of "Red Baron". On 17 March 2007, more complaints are added to Yamla's page, and from then on the hassles have been persistent, including puerile threats left on my own page.
Given "Red Baron"'s presumed disinterest in freecomputerbooks.com, would he agree to hand off the issue to another user whose account was created significantly before 12 March 2007?
The good faith about freecomputerbooks.com has long expired. No legitimate claims have been made for inclusion as an external link, only persistent and disingenuous arguments made by a variety of users, including our newest friend "Red Baron". For starters, just look at the recent AMA request.

Xerxesnine 16:57, 17 April 2007 (UTC)

'Hello, world' code

Contrary to the directive not to do so in the article's comments, I have made the bold move of changing this code:

'using namespace std' should never, ever be used, ever, even as a simple example.
this is not a tutorial on namespaces; this is an overview of C++. Mentioning 'using std::cout' is too much detail.
including <ostream> is required by the standard, so it should be included. This is not a tutorial on iostream technicalities; we do not need pedantic notes on iostream/ostream.

Xerxesnine 19:39, 17 March 2007 (UTC)

"'using namespace std' should never, ever be used, ever, even as a simple example" - I disagree. It is ok in cpp files. --Urod 19:47, 17 March 2007 (UTC)

Ugh, not in a C++ overview. This is not a tutorial on namespaces. If we write "using namespace std" we are required to also mention where/when that is/isn't acceptable, and we must also mention the difference between using directives and using statements. Xerxesnine 20:54, 17 March 2007 (UTC)

I agree wholeheartedly with Xercesnine. "using namespace std;" is just a notch above "#define cout std::cout" in my book. While there are cases where "using namespace std;" might be acceptable (i.e. in cpp files, especially when porting old code), general use of this construct is not good practice. It does not belong in a "hello world" program which would serve as a new user's first intro to the language. ATren 15:00, 23 April 2007 (UTC)

It should defenetly be 'using namespace std;, because this is the I, and most people, learn it. besides, if people learn it now, they won't have to worry about it later. And it is alot faster for larger programs.K25125 00:52, 27 May 2007 (UTC)

Using namespace std is not a required component of the hello world program, nor does it make the program simpler to understand. When you are trying to make a simple program, you want to make it as simple as possible, without confusing newcomers or slowing down quick glances. The best thing that can be done with that statement is to reduce typing, at the cost of a potential cross-namespace naming conflict. --Sigma 7 02:30, 27 May 2007 (UTC)

This discussion is going on in two different places. I vote that we talk about the "using" construct in the section named that, and worry about the code itself in this section. — EtherealFlaim 05:21, 27 May 2007 (UTC)

I think the Hello World section is better now that all the disclaimers and such are removed. I was one of the ones thrashing around trying to add things to make it right, but now that I see the pruned down version, I like it better. ATren 01:13, 19 March 2007 (UTC)

Something I think should change: Remove "#include <ostream>" and " << std::endl" Instead, just use the following: std::cout << "Hello, world!\n"; This is much more simple, and also far more common. Most basic C++ books today don't include <ostream> in their Hello World examples anyway. -- Alpha_Slayer 19:18, 16 May 2007 (UTC)

Much more simple but also wrong according to the C++ standard. You need ostream for std::ostream. Also, std::endl is not the same as \n. --Yamla 19:24, 16 May 2007 (UTC)

I don't see it stated anywhere that endl has to be used. It might make the code easier to read but it does not achieve a different end result. endl causes an extra class method call where "\n" is interpreted by the parser as an end-of-line which it checks for anyway. "\n" might actually be easier to understand for some people. Come to think of it neither endl nor "\n" has to be present when writing only one line. -Andrew ^{flame him | stalk him} 13:41, 14 July 2007 (UTC)

Why ANSI and not ISO?

Is there a reason why both dialects of C++ are referred to as being ANSI rather than ISO standards? I would have thought that the international standard superseded the US one.

SheffieldSteel 23:13, 19 March 2007 (UTC)

iostream.h

Geez, seems like there's been a few times people have tried to add a .h to this header. The CORRECT header is just iostream (e.g.: #include <iostream>). Look, if you really think we should be using deprecated header files, you're well behind on the current state of C++ and it could be argued that you have no business editing an article about this language. Sorry to be harsh, but that's really poor and inexecusable. C++ Template 16:48, 23 March 2007 (UTC)

Multiple Inheritance

I think multiple inheritance adds power to a language. I think that the additional capability should be the focus rather than saying it is sometimes considered "controversial".

I would like to add my views about multiple inheritance. A proper usage of multiple inheritance adds lots of code reusability. If the developer is doing mistake the blame should not be put on to the feature of the language. I would like to advice deleopers to use features of C++ only after understanding it. For me it is not "controversial". Jayaram Ganapathy

References section looking ugly

Hay references section is looking ugly. I am unable to edit and fix it. Please look into it. There is a ref tag in the virtual function example section. Please correct it appropriately. Thanks Jayaram Ganapathy

Why the fuss?

I've seen the "#include <ostream>" war being waged now for months, and I've actually flipped sides a few times in an attempt to gain consensus. But I'm wondering, what is all the fuss about including this extra include line? It is completely harmless to include it, and regardless of whether any compiler actually strictly needs the explicit ostream include, the standard is constructed in such a way that a fully compliant compiler might need it... so why not include it?

This seems to be a lot of fuss over nothing. Why the persistent focus on this one insignificant line in the sample program? Can we just keep the include and move on? ATren 15:05, 24 April 2007 (UTC)

It seems that many editors find Hello World to be an irresistible edit target. There is probably a thesis in there, but... eh. I don't know. SheffieldSteel 17:46, 24 April 2007 (UTC)

This <ostream> insanity, especially with regard to our recent friend 207.207.127.254 (talk • contribs), is the strongest argument I've seen in favor of citizendium. Xerxesnine 21:19, 30 April 2007 (UTC)

The editor at 207.207.127.254 identified himself as Peter Norvig (and I'm not violating privacy policy here). If he is the same person as Peter Norvig, and given where the IP address resolves, this is certainly not a foregone conclusion, he could have likely become one of the "expert overseers" and would likely have been able to enforce his incorrect version. I'm not saying Citizendium is inferior to Wikipedia, just noting that its different model would probably not have helped here. --Yamla 21:31, 30 April 2007 (UTC)

I highly doubt it is the same Peter Norvig. The Director of Search Quality at Google is not, as far as I know, a student at UPS. -SpuriousQ (talk) 06:23, 1 May 2007 (UTC)

This is why Wikipedia implemented the semi-protect, which basically prevents anon IPs from disruption. If it continues, we can go that route. But he reverted himself today and started a discussion here instead, so maybe it's not necessary. ATren 23:28, 30 April 2007 (UTC)

This is not a debate over the extra line or not, it is what the committee´s intentions were. Section 27.3 in the standard does not say anything about including <ostream> or <istream>. But the definition in 27.3 may imply other things. For instance it does not declare the types istream, ostream, wistream or wostream. So a strictly conformant program is required to include both <istream> and <ostream> before including <iostream>. But I don't think this is the intention of the standard committee. Many (if not all) examples in the standard that use cout and or endl include only <iostream>. If strictly following the standard neither of these would be allowed, since <iostream> doesn't define any operators, doesn't define the type of cout/cin/... (calling any member functions is a failure), doesn't even forward declare the type (compilation should fail directly in the iostream header). But hey, these are not the first non-comformant examples in the standard, at least it says something about their intentions.

I'm not sure I understand your logic in claiming that <istream> would also be needed. std::cin is not used in the sample app, and therefore the definition of std::istream is not required. It is my understanding that a standards compliant iostream header could declare all the types and typedefs required by std::cout without defining them, and this is why <ostream> would be required for any use of std::cout.

As for the intent of the standard, it is not for us to judge what it should be. Clearly, it appears that the standard is at odds with itself - on one hand, it does not explicitly require the definition of std::ostream, but on the other hand you say that the standard itself includes sample code that doesn't include <ostream>. So it's an inconsistency in the standard: either the sample programs are wrong or the specification of <iostream> is incorrect.

But it is what it is, and the bottom line is that an ostream-including app will be correct regardless of what the intent of the standard is. Having the extra include is correct either way, and it's harmless (other than being a little aesthetically repulsive), so why not keep it? ATren 22:33, 12 May 2007 (UTC)

Double-Defining <ofstream>

ok, I'm getting a little frustrated with heavy-handed admins reversing my changes. Here are a couple of points that, as an embedded systems programmer, I have experienced that warrants the change in the 'Hello World' application code:

I understand the reasoning behind including <ostream> in addition to <iostream>, because there exists a theoretical system that would produce compiler errors while remaining perfectly adherent to the C++ standard, as the standard does not explicitly require ostream to be included by iostream.

However, There also exists an (equally likely) system that adhers to the C++ standard that will error as a result of the current "Hello World" code. The problem exists because compilers in general have no method to detect whether a header file has been included multiple times. It is up to the implementation of ostream.h whether compilation directives protecting the double-inclusion of the header file are in place.

Less-common versions of the C++ compiler (e.g., Microchip's for the pic18) may not have these directives, and as such the Hello World application will fail to compile. That said, I have modified the Hello World code to avoid both of these scenarios, and compile well in *any* system. I have done this anonymously, so this is not a matter of pride. I am simply trying to bring Wikipedia up to the level of consistency it pretends to adher to with the inclusion of ofstream in the first place.

At worst, the code I have provided is no less correct, and is no less clear, than the previous version, while retaining portability. I beg the Wikipedia administrative community to please, please get over their meaningless convictions over this issue and allow an objectively more correct version of the hello world application to grace the page on c++.

The "hello, world" version you provided is not standard-conforming. Read this talk page and do some google homework to learn why. Any compiler which cannot compile the current "hello, world" program (NOT your version) is not standard-conforming and thus out of the purview of this article. Xerxesnine 20:30, 27 April 2007 (UTC)

Can you provide evidence that the standard permits compilation to fail if a program includes both <iostream> and <ostream>? I'm not saying you are wrong (though you are in violation of WP:3RR), but the official standard is a bit hard to fathom. I was under the impression that the compiler had to allow any combination of standard headers to be included. Note that the hello-world version that you give will fail on some pre-standard compilers, so your claim that this will compile well on any system is pedantically incorrect; of course, the version of hello, world that you are arguing against will similarly fail on such systems. I do take issue with your "objectively more correct" claim, however. Given that the C++ standard officially requires that ostream be included in order for the code to work, your version is not objectively correct. That this may result in header conflicts making a strictly-adhering solution impossible does not alter this. --Yamla 20:32, 27 April 2007 (UTC)

I am extremely skeptical of the claim that a compiler could ship with a standard library without header guards to protect against multiple inclusion. I am even more skeptical that such a compiler could claim to be compliant with the standard (a standard library without header guards would fail to compile almost every moderately complex project I've ever seen).

In any case, your repeated reversion of this #include line violates the three revert policy, and technically you can be blocked for such practices. What I would suggest to you is to try to make your case here, and if you can achieve consensus then the change will be made. Wikipedia is about building consensus by citing reliable sources to back your claims, not about edit-warring to force your preferred version of events. If you feel you are correct, then cite reliable sources to back your claims. Saying "well I used a brain-dead compiler that failed on this code" is not as verifiable as Xercesnine (and others) citing the standard (which is about the most reliable authority on C++) to support their version. ATren 20:54, 27 April 2007 (UTC)

I've checked an old draft version of the standard (about 5 years old) and found this (17.3.2.1) (emphasis mine):

A translation unit may include library headers in any order. Each may be included more than once, with no effect different from being included exactly once, except that the effect of including either <cassert> or <assert.h> depends each time on the lexically current definition of NDEBUG.

So including both <ostream> and <iostream> is perfectly valid according to the standard (and, as I indicated above, a standard library that didn't permit this would be practically unusable). ATren 21:18, 27 April 2007 (UTC)

This works fine on my compiler and that does not work on compiler X have to be the worst arguments out there for any particular version of "hello.cpp" - especially considering that this page documents the standard, not particular implementations. I would hope that people won't muddy the water further by continuing to use that line of argument. I'd also like to concur with ATren's point above: I would expect any competent project architect (and surely standards-compliant library writers are a subset of that group) to use a mechanism such as redundant include guards to protect against multiple inclusion of header files. These techniques are the bread and butter of any non-trivial project. SheffieldSteel 22:03, 27 April 2007 (UTC)

ATren, this appears to be 17.4.2.1.2 in my copy of ISO/IEC 14882 from 2003-10-15. So I agree with your claim that a compiler which did not permit including both ostream and iostream would not be a C++-compliant compiler. I'm still open to being proved wrong, though. I have 13 years of programming C++ but have never implemented my own C++ compiler and so have only passing familiarity with The Official Standard. --Yamla 14:55, 28 April 2007 (UTC)

Anonymous is right. Although the endl I/O manipulator is part of ostream which provides the ostream class it is not a requirement to include it for code conforming to standard. Any compiler not including ostream will have to implement it and its related functions and manipulators as part of iostream. Although endl is defined under ostream, iostream is defined as having all the capabilities of istream and ostream as a combined iostream class. It may therefor not be defined under iostream explicitly but is defined under it by implication and any compiler which can not compile code using endl without including ostream specifically is not standard compliant. -Andrew ^{flame him | stalk him} 23:39, 13 July 2007 (UTC)

using namespace

Shouldn't the "Hello, world!" program have "using namespace std;" instead of "std::cout..."?

I like the former better myself, and although they both work, later programs will use so many std commands that it's not efficient to use std:: with all of them. --24.245.11.103 02:23, 28 April 2007 (UTC)

Many experts advise against any use of a using directives (i.e. "using namespace std;"). See Herb Sutter's take on using directives ("Using directives should be avoided entirely, especially in header files."). Stroustrup also advises against using directives for most situations.

For programs with repeated uses of std:: names, the cpp file may have using declarations, i.e. "using std::cout", which import a single symbol rather than an open-ended list of all std symbols. Using declarations in cpp files are the generally accepted way of avoiding repeated std:: prefixes everywhere, though some still will accept using directives in cpp files. Again, see Sutter's excellent discussion of namespaces best practices, at the link provided. (And consider buying Herb's books, which expand further on the voluminous free advice he's provided through the years).

The point (made by Xercesnine and others) is: though there may be some valid uses for a using directive, it is not a good general practice, and to include it in a 3-line hello-world program is not appropriate. That's my view as well.

(Disclaimer: I have no affiliation whatsoever with Herb Sutter; he's just written some really good advice on good C++ practices, most of it given freely on Usenet in the 90s. :-)) ATren 04:18, 28 April 2007 (UTC)