Talk:C++/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 10

strong typing?

Well, it's your article - but can you really say so? Just to be sure I tried a little test program:

#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 personally 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 sadly 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)

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)

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)

Please, people. Stop removing the <ostream> include. The C++ ISO standard requires it to be included, and therefore we include it. End of discussion. Xerxesnine 12:44, 24 April 2007 (UTC) [This comment and its responses moved to this section by Xerxesnine.]

please back this up with some facts. Otherwise abide by the consensus established in the section up above which you chose to ignore when you created this section. --MarSch 13:48, 24 April 2007 (UTC)

The necessary fact is that the C++ ISO standard requires it be included. --Yamla 14:09, 24 April 2007 (UTC)

Consensus is it should be removed. If you want a separate page for the standard fine but this page is on C++ not the ISO standard.

Clearly that is not the consensus and furthermore, this article is about C++-the-ISO-language, not some-version-that-happens-coincidentally-to-work-in-your-compiler. --Yamla 18:57, 28 May 2007 (UTC)

You continue to reference the standard and the reason for leaving it actually has nothing to do with what is in the standard but what is not in the standard. The actual reason was given quite nicely in the discussion archive and I see now why leaving it would be helpful. The reason is that there are some compilers (not widely used) out there that did not implement all those items in <iostream>. The standard is written weak and the people who wrote said compiler can say "look, the standard allows us to do this", but not because the standard states you can do this, it does not. It just doesn't explicitly state it HAS to work that way. So the standard being written that way gives someone writing a compiler the freedom to implement it that way and still claim they are not breaking the standard. To quote from those discussions:

You can't show it on the ground of the standard because the standard does not say that <iostream> must include <ostream> or provide definitions of 'std::basic_ostream', etc. The standard mandates that <iostream> declares the eight standard stream objects ('std::cout', 'std::cin', 'std::cerr', and 'std::clog' plus their wide character counterparts). To do so, <iostream> must declare a bunch of class templates ('std::char_traits', 'std::basic_ostream', and 'std::basic_istream') and that's it. --Dietmar Kuehl

As to help with further editing... the reason for leaving it there is the ISO standard for C++ allows for a compiler writer to require it be done this way and still not violate the C++ ISO standard. The vast majority of compilers include <ostream> when one includes <iostream> so for them it does not need to be there. However, if compiler portability is a strong concern one should consider including both.

So it appears consensus us to not include <ostream> when <iostream> is used. Why is it still there then? For some arb compiler that does not include <ostream> with <iostream>? -Andrew ^{flame him | stalk him} 13:13, 14 July 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)

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)