Talk:C++

Archives
January 2006 August 2006

arguments?

I am under the impression that the canonical starting program (at least in g++) is actually

int main(int argc, char* argv[]) {}

with the arguments being the command-line parameters passed to the application. This is more likely to be what a user or someone interested in C++ would see; perhaps the "minimal program" should have them added? One might say that this isn't quite a "minimal program," but it's what would actually be seen...I don't know. Thoughts? Ed Ropple - Blacken - (Talk) 22:06, 9 November 2006 (UTC)

strong typing?

Well, it's your article - but can you realy say so? Just to be shure I tried a litte test programm:

#include <iostream>

int
main ()
   {
   unsigned i = -1;

   std::cout << i;

   return i;
   }

compile and test:

>g++ test.cpp -o test
/tmp  Linux  martin@linux2  Mi Sep 27 20:47:18  standart
>./test
4294967295

It did not print out -1 or an error message for a illegal type conversion, didn't it? I personaly can't see anything strong about turning -1 into 4294967295.

--Krischik ^T 19:01, 27 September 2006 (UTC)

I agree that C++ should not be called strongly typed. However, unsigned arithmetic in C/C++ is defined as integer arithmetic modula a power of two, and −1 is converted accordingly when i is initialized. It is actually the conversion from unsigned to signed integers which is unsafe as overflow during a conversion in this direction invokes undefined behavior. (Correcting myself: overflow during a conversion does not invoke undefined behavior but implementation-defined behaviour, it is only overflow during arithmetic operations that invokes undefined behavior. —Tobias Bergemann 08:03, 9 October 2006 (UTC)) — Tobias Bergemann 07:54, 28 September 2006 (UTC)

Yes, it is the implicit conversion that is unsafe. But at no time is the type of the variable i unknown. So I would still classify C++ as strongly typed. Yes, it has casts that subvert the type system, and implicit conversions that result in the kind of undefined behavior observed above, but on the whole it is strongly typed. If there is a concern about the term "strongly typed", I would suggest "strongly typed, but the type system may be subverted using casts". ATren 15:46, 28 September 2006 (UTC)

But is knowing the type not a matter of static vs. dynamic? --Krischik ^T 17:01, 28 September 2006 (UTC)

I'm not sure what you're asking here. Every C++ object has a single type, bound at the time of object creation. Polymorphism allows for type-interchangeability between different subclasses of the same base type. So, at compile time, the static type of a reference variable may be Base&, but the dynamic type of the object bound to that variable at runtime may be Derived1, Derived2, etc (where Derived* classes inherit from Base), or even Base itself. None of this violates the rules of strong typing, does it? ATren 19:33, 28 September 2006 (UTC)

Actually, this behavior is kind of predictable. The signed number, -1, is stored in a Two's Complement format. So "-1" is stored in a 32bit value as [1111 1111 1111 1111 1111 1111 1111 1111]. This data is then copied to the unsigned variable. But because the variable is unsigned, that data is treated as "2^32 - 1", or "4294967295". Therefore, the data itself isn't modified, but rather the interpretation of it. (Ghostwo 18:59, 14 November 2006 (UTC))

But C++ also operates on platforms where the signed integers are not Two's Compliment. On such platforms, (where -1 is *not* [1111 1111 1111 1111 1111 1111 1111 1111]) -1 still becomes the maximum value when converted to an unsigned type. This behavior in C++ works on value, not representation, so the actual data can be changed; not just the interpretation thereof. Clarkcox3 19:57, 16 November 2006 (UTC)

static/dynamic, strong/weak

None of which violates the rules of static typing either because the type continues to be Base&. You can't store an integer in the same variable (you could force a uint_p into it). In a dynamicly typed language you can do:

i := 1;

print i;

i := "Hello World";

print i;

i := Derived2 (1, "Hello Word");

print i;

C++ is of course stronger typed as C - it won'd implicidly convert a void* to andy other pointer type any more. And with dynamic_cast it got a lot safer. But saddly C++ improved there type system only for pointer and classes but not for primitive types. The fact that you can't do:

void f (unsigned i)
  {
  auto signed j = dynamic_cast <signed> (i); // raise range_error when i > MAX_INT.
  }

or

typedef explicit int Apple_Count;
typedef explicit int Pear_Count;

auto Apple_Count Apples;
auto Pear_Count Pears;

Apples = Apples + Pears; // Compile error: you can't add apples to pears.

is a missed oportunity. The first would have improved C++ in the arena of "save" and the 2nd in the arena if "strong". I know that if Apple_Count and Pear_Count where classes then C++ would be "strong" and not add apples to pears. It is just that for the building block, the foundation of all classes: primitive types C++ still is weakly-typed.

Of corse non of the attribute static/dynamic, strong/weak, safety is a one or the other. The question is: which direction does a language lean to.

--Krischik ^T 06:38, 29 September 2006 (UTC)

You raise some interesting points. Using dynamic_cast<> on primitives would indeed be a novel approach to safe integer casting, though I think I'd rename it for primitive conversions. dynamic_cast<> would be expected to raise bad_cast, not range_error. I'd prefer a different casting operator for primitives, i.e. primitive_cast<>.

One of the benefits of C++, of course, is we can often add something that is not provided. For example, to implement primitive_cast<>:

 template <class TO_, class FROM_> TO_ primitive_cast(FROM_ from)
 {
     //use numeric_limits<TO_> to detect detect valid range for TO_ type
     //throw range_type() if invalid range
 }

And to use it (for example):

 void f (unsigned i)
 {
     auto signed j = primitive_cast <signed> (i);
 }

The weakness here, of course, is the lack of enforcement. The primitive_cast can be eliminated, or, in fact, you could even specify the wrong type in the TO_ parameter, and the compiler would not raise an error. In this sense, I agree, C++ can be considered somewhat weakly typed for primitives.

Your second point, about typedef'd names being interchangeable, is due to the fact that typedef is type aliasing - no new type is defined by typedef. The apple/pear example could be made fully type safe by making them classes:

 class Apple_Count
 { 
 private: 
   int count;
 public:
   explicit Apple_Count (int c) { count = c; }
   Apple_Count operator+(const Apple_Count& rhs)
   {
       return Apple_Count(count + rhs.count);
   }
 };
 
 class Pear_Count
 { 
 private: 
   int count;
 public:
   explicit Pear_Count (int c) { count = c; }
   Pear_Count operator+(const Pear_Count& rhs)
   {
       return Pear_Count(count + rhs.count);
   }
 };
 
 auto Apple_Count Apples;
 auto Pear_Count Pears;
 Apples = Apples + Pears; // This will raise a compile error.

This will raise a compile error. This same kind of class encapsulation technique can be used in the first example as well, to prevent implicit primitive conversion.

So, perhaps the answer here is what you have implied above: that C++ classes, pointers, and references are more strongly typed than primitives, with the further caveat that things like reinterpret_cast basically allow the programmer to ignore the type system completely. In essence, this goes to the design goals of C++ - you can be as strongly typed as you want to be; C++ written using primitives everywhere will not be as strongly typed as one that uses purely classes, so the choice is really left to the programmer. The point is, C++ gives you the option of writing strongly typed code, but also allows you to get around it if you choose, by using primitives and/or reinterpret_cast<>. ATren 11:22, 29 September 2006 (UTC)

C++ is not strongly typed

C++ allows for implicit type conversion. According to the Strongly-typed programming language article, this is not allowed in a strongly-typed language. Implicit type conversion is not allowed in strongly typed languages because it limits the ability of the compiler to determine type errors at compile time.

Here is an example that adds a character to an integer and prints 109 without complaining.

#include <iostream>
using namespace std;

int main()
{
        char a = 'a';
        int b = 12;
        int c = a + b;
        cout << c << "\n";

        return 0;
}

Since this is a controversial point in this discussion, I am not going to change it myself. I want people to read what I wrote, comment on it, and come to a consensus. However, I can promise you that any programming language semantics expert would say that C++ is not strongly typed in the sense that Haskell or Java is strongly typed.

24.124.75.129 03:33, 8 October 2006 (UTC)

It's a valid question. Personally I believe that C++ has strong typing features, but is not as strong as other languages in terms of implicit conversions (especially for primitive types). On the other hand, templates arguably make C++ more strongly typed than other languages, by (for example) allowing the use of generic collections that are type safe and don't require any casting. So on one hand C++ gives you the ability to write generic code that is very type safe, but then it also provides several different mechanisms to subvert the type system. So I might categorize it as basically strongly typed, but with exceptions. I think it would be incorrect to call it weakly typed, because weakly typed implies there is no type checking facility at all. ATren 21:03, 7 October 2006 (UTC)

Regardless of the "stronger than other languages" issue, the fact that one can subvert the typing system places C++ in a different category than the truly strongly typed languages such as Haskell or Ada. Also, it is important to note that on the Weak typing article, C++ is called weakly typed, so this issue needs to be resolve between the two articles for consistency.

A common definition of weak typing is the allowance of type coercion with the language's primitive types. Therefore, I feel that it is perfectly fair to call the language weakly typed. Weakly typed does not mean no type system, it just means that the language is not strongly typed.

24.124.75.129 03:42, 8 October 2006 (UTC)

Maybe "neither" is an appropriate answer? While "strong" may not be appropriate, "weak" seems equally inappropriate, since that lumps it with scripting languages that have almost no typing facility. ATren 15:20, 8 October 2006 (UTC)

The controversy here is clearly the definition of "strong typing" and it appears that even the experts don't have a solid definition. My copy of "Types and Programming Languages" by Benjamin C. Pierce (a top textbook in the field) does not even have an index entry for "strong typing". Therefore, I am voting for removal of the strong/weak typing label altogether. 24.124.75.129 03:45, 15 October 2006 (UTC)

I agree. It's clear that C++ is not one or the other, so best to remove it entirely. ATren 04:34, 15 October 2006 (UTC)

I went ahead and made that change. If anyone objects, please discuss further. 24.124.75.129 21:01, 15 October 2006 (UTC)

I fear that Java with it's new box-in box-out feature is not strongly typed either any more. But I guess that is another story... --Krischik ^T 13:06, 8 October 2006 (UTC)

The article about strong typing (Strongly-typed programming language) basically says it is a pit of vipers and everybody means something different. C++ provides type checking, but it also provides for suspending the type system. Does that mean C++ doesn't provide a type system? What if the type system is strong? as Bjarne himself repeatedly claims, see for example TC++PL. Just because it can be switched off when that is convenient (or necessary) doesn't make the typing itself any less strong. --MarSch 18:02, 6 December 2006 (UTC)

Well, my first impulse was that C++ was "strong", but I now consider it ambiguous enough to keep both "strong" and "weak" out of the article - because it's clearly not weak, but there are languages (i.e. ADA) that are much "stronger". That's why we made the decision to remove "strong". Stuff like implicit casting of primitives and reinterpret_cast<> seem to fly in the face of most definitions of strong typing. ATren 21:17, 6 December 2006 (UTC)

We could say that Bjarne has called it strongly typed and be done with it. I do agree that the rules for primitives are funky (and so does Bjarne), but it is done because of C compatibility. All these things could be explained in the article. --MarSch 15:27, 7 December 2006 (UTC)

If you want to add some verbiage about Bjarne's claims about strong typing, I wouldn't object. Personally I don't think it's worth the effort - strong vs weak is so fuzzy that I'd just as soon leave it out. ATren 16:55, 12 December 2006 (UTC)

PHP influenced by C++?

I am not sure that PHP was influenced by C++, although PHP5 is now leaning towards that direction. PHP until version 5 had no method of overloading operators, overloading functions, strongly typed variables, and remains completely interpreted.

PHP has no sensible OOP-style programming model before PHP5, and has no try..catch methods.

I conclude that if PHP is, in fact, based on C++, since it rejects so many of these major advances by the C++ foundation, that it is, in fact based on C, and not C++. {{subst:unsigned|129.31.85.158 }

Well, PHP4 had a C++ style class declaration (I don't know if it has similar semantics, though). But yes, I agree that the influence is rather tentative. Keeping in mind WP:OR, soes anybody have references for or against? Something from the PHP web site maybe?--Stephan Schulz 07:34, 10 October 2006 (UTC)

if you want to claim something like this you need a reference. Concluding it yourself is a nono. --MarSch 15:30, 3 December 2006 (UTC)

Some facts for consideration:

1. PHP has many classes and functions which are also present in C++ but not C
2. PHP is first released after C++ is released
3. However, PHP is built on C not C++

My viewpoint lean towards the statement that PHP is influenced by C++, but how can anyone know what were the programmers thinking when they first invented PHP? --Deryck C. 09:37, 16 January 2007 (UTC)

Vandalised.

Somebody has written "I don't know c+++++++ how can i edit?" under 'Templates.' Please remove.

 Done. --Yamla 16:54, 6 November 2006 (UTC)

C++: Pronounced the way it looks?

The article begins, "C++ (pronounced the way it looks) is a ..." But how does it look? C plus plus? C double plus? C positive positive? C double positive? I'm deleting this until somebody can come up with a citation. Patiwat 21:31, 5 December 2006 (UTC)

Does anyone think it would be better to just write "C plus plus" for the pronunciation instead of using the IPA? I'm not very familiar with the IPA so it doesn't tell me much. Plus the IPA looks like over kill. --Eruhildo 21:43, 4 January 2007 (UTC)

I agree. I doubt anybody would have trouble figuring out how "plus" is pronounced. ATren 21:58, 4 January 2007 (UTC)

Why not have both? There's no need to remove the IPA. Herorev 03:18, 5 January 2007 (UTC)

The IPA clearly distinguishes between all possibilities mentioned by Patiwat. What more info would "See plus plus" add? --MarSch 14:43, 5 January 2007 (UTC)

Well, in my browser, the IPA is just a bunch of boxes - I probably don't have all the fonts required by IPA. But even if all the characters were there, I suspect it would be much less clear than a simple "C plus plus". I think IPA is overkill in this case, since the name C++ is composed of very simple English words. Though I'm not going to change it if there is opposition. ATren 15:25, 5 January 2007 (UTC)

I'm adding "pronounced C-plus-plus" in addition to the IPA, and we'll see if that sticks. ATren 17:19, 12 January 2007 (UTC)

Agree. "pronoucing the way it looks" is not as good as the previous version imo. --Deryck C. 08:55, 13 January 2007 (UTC)

C++ not LALR(1)

The article contains a 'citation needed' notice for a sentence claiming C++ isn't LALR(1). I don't have a citation, but I think the following (presented in a different manner, one would hope!) would demonstrate one parse ambiguity:

#if 1
typedef int* Ambiguous;
#else
int Ambiguous = 3;
#endif

int val = 4;

#if 1
int*
#else
int
#endif
test()
{
  return (Ambiguous) & (val);
}

Waldo 00:46, 6 December 2006 (UTC)

you're mixing preprocessor stuff with the C++ stuff. The parsing problem is about pure C++. The ref in a sentence earlier says the LALR(1) stuff, I think, so I removed the {fact}. --MarSch 17:51, 6 December 2006 (UTC)

iostream/ostream

Do we really have to be holier than the pope on this? Is there any braindead implementation in which <iostream> doesn't include std::endl or the complete <istream> and <ostream>? --MarSch 09:40, 9 January 2007 (UTC)

My guess is that some embedded compilers may include only the minimum requirement in each header, to reduce the output footprint (since including the full iostream library may be expensive for an embedded application). In any event, if the spec specifies both are necessary (or, if the spec is sufficiently neutral on the topic such that both may be necessary) then I think both should be included. ATren 17:18, 12 January 2007 (UTC)

As far as I know it is an unintended bug in that the standard is not clear enough. BS himself says something like this. Having to include something in addition to <iostream> for doing basic I/O is _NOT_ the intent of the standard. It is not meant for embedded implementation since it wasn't meant at all. It it a curiosity and hardly worthy of inclusion in this article. We need sane examples. --MarSch 12:45, 13 January 2007 (UTC)

But I guess that's the point: if the standard is not clear on the issue, compiler vendors can do what they want with it, and programmers have to assume that both includes will be needed. So I think it should probably stay as it is unless (a) the standard explicitly changes on this matter, or (b) there is official confirmation that this is a bug in the current version of the standard, and that compiler vendors are expected to implement all the basic requirements for IO from within the single include <iostream>.

An example of (b) would be the original implementation of the std::vector<> spec. In one of the initial versions of the standard, there was no explicit mention that vector should point to a contiguous block of memory, even though that was always the intent. However, several respected authorities (possibly BS and Herb Sutter, among others) came out and said that contiguous storage was indeed required, and that all current known standard library implementations had implemented it that way. This, to me, was a strong enough statement to rely on.

But I haven't seen such a strong statement about the <iostream> thing - not necessarily that the statement hasn't been made, but that I haven't seen it. If we can locate a solid reference for it, then the <ostream> can be removed; otherwise, I think it should stay (ugly as it looks) ATren 06:02, 16 January 2007 (UTC)

Since Wikipedia is a conservatory of knowledge and not just a den of nerds who argue concisely on the exact working mechanism behind each compiler, we should take the common iostream implementations, which include complete istream and ostream headers, into consideration, and remove the excess ostream include command. --Deryck C. 09:34, 16 January 2007 (UTC)

Might I suggest you read WP:NPA and WP:CIVIL, and refrain from calling other editors "nerds". ATren 01:19, 17 January 2007 (UTC)

ATren :) don't be so touchy and don't take stuff so personal. Anyway since when is nerd not a compliment anymore. --MarSch 18:15, 18 January 2007 (UTC)

Well, I'm relatively new on these pages and I don't know all the personalities, so perhaps I overreacted a bit. I wasn't really objecting to "nerd" per se, but the implication that the debate was senseless (which, really, is an arguable point :-)). Anyway, Deryck and I have communicated and all is resolved. ATren 16:29, 19 January 2007 (UTC)

(Just for reference, there is some discussion of the IO includes in the archives for this page.)

I think we should remove the #include <ostream> etc. from the code examples. But we should keep the note in the article to explicitly explain that we are aware that the include would be necessary for strict compliance with the 2003 standard if we want to avoid to repeat this discussion in the future. —Tobias Bergemann 10:59, 16 January 2007 (UTC)

That makes sense to me. ATren 01:20, 17 January 2007 (UTC)

As per Tobias's suggestion, I've taken a stab at removing the ostream include, while preserving the explanation of why it might be needed on some obscure compilers. If anyone has objections, please discuss it here. ATren 16:10, 18 January 2007 (UTC)

Yes, this looks good to me. Although I think this obscure detail doesn't justify even the note, I can live with it. --MarSch 18:19, 18 January 2007 (UTC)

What about a footnote? I don't know how to code it using wiki markup, but perhaps making the point in a footnote (in small text at the end of the section) would be less obtrusive than a giant text box next to the code - which I agree gives more weight to the issue than it probably deserves. ATren 16:37, 19 January 2007 (UTC)

Sorry if my comment above irritated anybody because of the word "nerd". I reckon that I did not realize many still consider "nerd" derogatory; that I did not realize the harm must be something I ought to say sorry for. Sorry that I didn't realize ATren considered the use of the word "nerd" incivil. (Please forgive me, I don't know how to put forth my idea without referring to certain people, thereby risking doing personal attacks.) Considering the point about personal attacks through the word "nerd", I hope everybody will forgive my personal-attacking myself through inducing that I myself am a nerd - I'm also a frequent contributor to this article. --Deryck C. 15:33, 19 January 2007 (UTC)

(I've also replied on Deryck's talk page). I only warned because it appeared (in this impersonal medium) to be a bit hostile towards the debate we were having. Given that Deryck and I have exchanged apologies, I'm chalking it up to just a big misunderstanding. No harm, no foul. ATren 16:25, 19 January 2007 (UTC)

(back to topic) I think the best solution is to add a note about the difference between compilers right below the sample code. --Deryck C. 08:33, 20 January 2007 (UTC)

I like ATren's idea of a footnote. Unless someone can dig up a source which shows an actual compiler requiring this, a footnote suffices nicely. --MarSch 18:35, 29 January 2007 (UTC)

So is it time to dig up this strange compiler now? --Deryck C. 11:26, 30 January 2007 (UTC)

The current ostream box is not correct; #include <iostream> is guaranteed to define std::cout, which is an instance of basic_ostream<char>, therefore basic_ostream<char> must be defined. Whether the typedef std::ostream is defined too is irrelevant. The reason <ostream> is needed is firstly that it defines std::endl, and secondly that it defines the free function std::operator<<(std::basic_ostream<char> &, char const *) which is used for displaying the "Hello world". I have read a comment in comp.lang.c++ about a version of Sun CC that compiled 'std::cout << "Hello world.\n"' and printed out the address of the string: since <ostream> was not included, the function overload I mentioned earlier was not visible, so the member function std::basic_ostream<char>::operator<<( void const * ) was invoked, which prints out the value of its argument. -- Old Wolf 21:48, 04 March 2007 (UTC)

#include <iostream> is not guaranteed to define std::cout, it merely has to declare it as an extern object (see "Header iostream synopsis" in 27.3 in the standard), and declarations of extern objects do not require complete types. As far as I understand, a implementation is free to use a certain amount of compiler magic to be able to declare std::cout etc. without defining basic_ostream. — Tobias Bergemann 07:56, 5 March 2007 (UTC)

The comment in the same section about 'using namespace std' is also not correct. The using directive does not import anything, and does not add anything to the current namespace. Instead, it specifies that if an unqualified name cannot be found in the current namespace, then it will be looked up in the target namespace instead. In the C++ standard text there is a worked example that shows how misunderstanding can arise if you think of it as 'importing' the names. -- Old Wolf 21:48, 04 March 2007 (UTC)

C++ as 'superstructure' of C

C++ is not quite a superstructure of C (indeed, the number of things that are valid ANSI C but not C++ increased from C89 to C99 - although it is still close), and I'm quite tempted to remove this sentence (or perhaps, more constructively, add a qualifier) as spreading common misinformation. Thoughts? Angus Lepper 18:22, 15 January 2007 (UTC)

How about providing an example? The following is C but not C++:

int main()
{
    void *y;
    int *x = y;
}

njaard 05:35, 16 January 2007 (UTC)

yes qualify, but don't go into excruciating detail. --MarSch 18:22, 18 January 2007 (UTC)

AfD Nomination: R++

I've nominated the article R++ for deletion. --Edcolins 14:03, 21 January 2007 (UTC)

int main()

All return values but EXIT_FAILURE, EXIT_SUCCESS and 0 invoke implementation-defined behavior according to the standard. Just changed the article. —The preceding unsigned comment was added by 88.76.234.183 (talk • contribs) 22:36, 24 January 2007 (UTC1)

Although the C++ standard does not require a return value of 0, an error will be returned to the operating system whenever the return value of int main() is not 0. All non-zero values will be treated as runtime error. Moreover, most compilers (including G++) doesn't allow void as the main() return type. --Deryck C. 09:06, 25 January 2007 (UTC)

neverending redirect.

sometimes when i search C++ it sends me to a never-ending redirect of itself (ie with no page content). but not always?. i'm not sure how to fix it or why it happens but i thought i'd bring it up..

some joker made the page a redirect to itself for a while. Maybe it was just that. --MarSch 17:18, 31 January 2007 (UTC)

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. bibliomaniac15 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)

'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 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)

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)