Talk:C++/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

→

Archive 10

Hello world example- incorrect code?

The "Hello World" isn't really OO. Whats about this (akademic...) example?

#include <iostream.h>
#include <string.h>

class string
{
private:
int size;
char *ptr;
public:
string() : size(0), ptr(new char('\0')) {}
string(const string &s) : size(s.size)
{
ptr = new char[size + 1];
strcpy(ptr, s.ptr);

}
~string()
{
delete [] ptr;
}
friend ostream &operator <<(ostream &, const string &);

string &operator=(const char *);
};

ostream &operator<<(ostream &stream, const string &s)
{
return(stream << s.ptr);
}

string &string::operator=(const char *chrs)
{
if (this != &chrs)
{
delete [] ptr;
size = strlen(chrs);
ptr = new char[size + 1];
strcpy(ptr, chrs);
}
return(*this);
}

int main()

{
string str;
str = "Hello World";
cout << str << endl;
return(0);
}

SEE: Evolution of a Programmer —Preceding unsigned comment added by 91.3.119.43 (talk) 09:06, 7 October 2008 (UTC)

The code shown does not return anything and the function main is specified as returning an int.. this shouldn't compile. 86.27.184.241 (talk) 22:05, 10 December 2007 (UTC)

Incorrect. main() (only) is allowed to not return a value. Check the C++ standard. This code will compile. --Yamla (talk) 22:31, 10 December 2007 (UTC)

Yes, but it's clearer and better to explicitly return a value. Otherwise what value is in the return register? A random value? The result of stdout? There will always be a value there, so it's better practice to have an explicit value. Most OS use zero for 'no problems' so that's why 0 is chosen. peterl (talk) 21:48, 13 February 2008 (UTC)

The current example is taken directly from Stroustrup and is sourced appropriately. For the main function, 0 will be returned if you do not explicitly specify a return value. Not a random value. Not a register. Not the result of stdout. This is explicitly defined by the standard. That's why you were asked not to make this change. --Yamla (talk) 22:09, 13 February 2008 (UTC)

Beefed up the ref to include details on implicit return of main. peterl (talk) 10:17, 14 February 2008 (UTC)

I've attempted to cover this in the mini-FAQ (without going into too much detail). SHEFFIELDSTEEL^TALK 16:46, 17 May 2008 (UTC)

Examples of programming languages do not constitute "original work" if they did all the stuff that you have typed into Wikipedia will have been considered "original work" or did you violate a copyright by doing this? The use of and expressions in a computer programming language make no sense with respect to NO ORIGINAL WORK, because the purpose of a programming language is an effective expression in that language. If you want people to understand a language, don't give them broken,limiting or fragile examples.

1. include <iostream>

using namespace std;

int main() { cout<<"Hello Worms."<<endl; } //The above examples serves to highlight another feature of the C++ language(namely namespace), not just glorify a Stroustrup "sound bite" —Preceding unsigned comment added by 71.106.9.74 (talk) 06:46, 4 August 2008 (UTC)

I agree. I don't understand how citing from Stroustrup automatically makes this the best "Hello World" application ever. This seems to just be an excuse the Old Guard of this article is using to maintain their version. The computing landscape has changed a lot since that example was written, and it seems appropriate to modernize it to make the hello world easier to read. —Preceding unsigned comment added by Wikipendant (talk • contribs) 06:48, 12 August 2008 (UTC)

"Best" is in the eye of the beholder. No matter what example is present, someone will take issue with it. It is easily arguable that endl is not as easy to read as \n because \n is present in other languages and endl is not. Attempts to "modernize" Stroustrup's example will most likely make it more complicated and harder for someone without C++ experience to understand. Remember that the "Hello world" example is for novices, not gurus. Krelborne (talk) 02:31, 13 August 2008 (UTC)

Contradiction: Date Errors in Article?

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

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

Criticism of C++

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

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

Pog 19:17, 6 August 2007 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

More criticism of C++

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

Here are some references in support of this criticism:

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

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

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

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

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

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

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

The minimalistic standard library could also be argued as a strength. Because anything included in the standard will have to be maintained for a long time, contributing to bloat. For a reference for that, I point you to the Java standard library... which includes 2 GUI toolkits, both heavily criticized. Currently, one can use e.g. C++ and QT, and get a rather complete toolkit, which is reasonable cross platform, well documented and Libre. Esben (talk) 20:40, 10 January 2008 (UTC)

QT is not free for commerical use Pog (talk) 21:32, 16 April 2008 (UTC)

Qt is released under the GPL. The GPL allows for commercial use. --Yamla (talk) 21:34, 16 April 2008 (UTC)

Yes, but proprietary commercial development requires the commercial license.[8] "The Qt Open Source Edition is offered to the Open Source community under Trolltech's Dual Licensing Model. The Open Source Edition is freely available for the development of Open Source software governed by the GNU General Public License (GPL version 2). The Qt Commercial Editions must be used for proprietary, commercial development."[9] — Tobias Bergemann (talk) 07:37, 17 April 2008 (UTC)

True enough. But it's still fine to use the GPL'ed version for commercial development under the GPL, as some companies do. Qt would be free in such a case. --Yamla (talk) 14:27, 17 April 2008 (UTC)

#include <ostream>?

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

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

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

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

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

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

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

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

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

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

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

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

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

May the God help us all.

67.188.7.78 05:46, 25 August 2007 (UTC)

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

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

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

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

namespace std {

template<typename E, typename T> class basic_ostream;

template<typename C> struct char_traits;

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

}

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

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

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

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

ATren 12:33, 25 August 2007 (UTC)

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

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

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

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

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

I know its an old debate, still i cant stop but ask: how can iostream define cout(an instance of ostream) without including the ostream header? Just think, please... and \n is perfect for a simple newline, and its pretty C++-style, as C++ is a performance-orinented language, and a manipulator should be slower than 1-2 char output. Tetra HUN (talk) 21:16, 17 March 2008 (UTC)

iostream could forward-declare ostream. Heck, the "headers" don't even have to be actual headers. --Yamla (talk) 21:30, 17 March 2008 (UTC)

It cant. cout is not a ptr of ref, its a real object. To create an instance, you need the whole definition of the (template)class. But, youre right in the fact that compilers will possibly treat std headers in an unordinary way. Tetra HUN (talk) 21:49, 17 March 2008 (UTC)

(un-dent) I don't know if anyone has tried this approach before, but: Wikipedia's gold standard for content is Verifiability, not truth. This means that we should not concern ourselves with technical arguments, from programmers, for programmers, about what the "Hello, world" example should contain; instead, we simply document what our reliable source does contain. And Stroustrup is the source, as far as C++ is concerned. Sheffield Steel^talk_stalk 22:13, 17 March 2008 (UTC)

If you look closer, we write about the C++ Prog.Lang. So the reliable source is the ISO standard which describes the language rules. It is true, that Stroustrup(i can pronounce, yay!) is most likely a reliable source, but the main is the standard. Tetra HUN (talk) 05:06, 18 March 2008 (UTC)

I do agree that the ISO document is an excellent source; however, while Stroustrup provides source code for the "hello, world" example, and while the ISO standard provides information which can be used to logically deduce what the exact contents of hello.cpp ought to be, it does not (to my knowledge) actually provide example code. We have to be careful to avoid synthesis when discussing what fact A and fact B imply about C++.

Just to clarify: I'm not trying to start an argument here; I'm trying to provide an argument in defence of the long-standing version of hello.cpp that's in the article. Sheffield Steel^talk_stalk 13:43, 18 March 2008 (UTC)

As i see, theres nothing to be argued: this hello world is just fine. I wrote my first just because the older posts tells that iostream doesnt has to contain ostream, which is totally nonsense... what more, i talked with the hungarian cpp guru, and he told me, that the question is not that if iostream contains ostream and istream. Its about that iostream is just the union of ostream and istream, or more in sg? Sorry for long and useless readings :) Tetra HUN (talk) 22:32, 18 March 2008 (UTC)

The point nobody here has yet mentioned is that \n is platform-bound. Fine in Unix, but on a Mac you need to use \r and on Windows/DOS you need \r\n. Using std::endl clears this up for you, flushes the buffer (not that it matters since we're exiting anyway) and is included with iostream. Jon (talk) 12:05, 17 May 2008 (UTC)

\n is not platform specific, how it is written to file is, using std::endl is equivalent to writing \n to stream and than std::flush. Moreover, please dont edit hello world exaple, its well sourced and agreed by editors to be best left as it is. Create dedicated topic here if you have some concerns about it. Cheers 83.25.81.179 (talk) 12:38, 17 May 2008 (UTC)

I've tried to cover this issue in the mini-FAQ at the top of the page. SHEFFIELDSTEEL^TALK 16:47, 17 May 2008 (UTC)

Standards compliance - compilers who support export keyword

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

Good Article Review

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

The result of the review was to Delist the article. An archive of the discussion can be found here. Based on comments in the review, I have added some {{fact}} tags to help any future editors. Drewcifer 22:29, 8 September 2007 (UTC)