C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Return code Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Matthew Peavy Guest Posted: Sun Sep 28, 2003 10:26 pm    Post subject: Return code Hi all, I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. I adopted the style of returning negative ints values for failures, and positive ints for success. Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? Should I stick with the 0-as-success and all other values as failure standard? Do operating systems ever interpret these codes and act on them? Thanks, Matt. www.mpeavy.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Mon Sep 29, 2003 9:25 pm    Post subject: Re: Return code On 28 Sep 2003 18:26:21 -0400, Matthew Peavy <mattsjunkemail (AT) yahoo (DOT) com> wrote in comp.lang.c++.moderated: Quote: Hi all, I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? Yes, although it involves implementation-defined termination codes beyond what the standard defines. Depending on the nature of a program, or even a function within a program, there are many possible errors that can be detected. There is one and only one successful case, essentially being that none of those errors are detects. So assuming you have an implementation that allows more than two possible return codes, 0 means "0 errors detected" and any non-zero number indicates the first detected error that caused the program to quit unsuccessfully. That's exactly how return 0 came to mean success in the early C/UNIX days. Various unsuccessful conditions resulted in various different non-zero positive values. Quote: In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. How can there be different states of success? In general success means that a program was able to do what it was expected to do with the input that it received. Do you want it to use some additional standard to evaluate its performance and return a low positive value for a "fair to middling" job, but a higher positive value when it decides it really did an excellent job? Quote: I adopted the style of returning negative ints values for failures, and positive ints for success. Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? Depends on how you define "wrong". It certainly makes your code less portable. There are common platforms that take the int value passed to exit() or returned from main() and truncate the low 8 bits. You won't ever see a negative value on these systems, only something between 0 and 255 inclusive. Quote: Should I stick with the 0-as-success and all other values as failure standard? Yes you should unless you want to have porting problems. Quote: Do operating systems ever interpret these codes and act on them? In some cases operating systems do, as well as very common programs that invoke other programs in scripts or batch processing modes. The most common of these is something familiar to most programmers, even if it is not specifically part of any programming language standard. I refer to the ubitquious make utility. Every implementation of make I have ever used breaks the build on any non-zero termination status from any program it invokes. I have heard tell of one older operating system that only looked at the least significant bit of the termination status. It only cared whether the value was even or odd. One meant success, the other failure. I forget which was which. I never actually used such a system myself. In general, needing to understand multiple reasons for failure of an entire program, as opposed to a particular function or module within a program, is a testing and debugging thing. What is the user of your program going to do with the fact that with one set of inputs it failed with a code of 3, while with another set of inputs it failed with a 2? Who is this information actually useful to? If you want maximum portability, use EXIT_FAILURE (from <stdlib.h> or <cstdlib>) to indicate failure, and either 0 or EXIT_SUCCESS when successful. These are the only values guaranteed to be portable to every conforming C and C++ implementation. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Mon Sep 29, 2003 9:29 pm    Post subject: Re: Return code In article <FxHdb.35$bk6.40316 (AT) news (DOT) uswest.net>, Matthew Peavy <mattsjunkemail (AT) yahoo (DOT) com> writes Quote: Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? Yes, because we may want to signal the way in which a program failed but if it succeeds that is usually all we need to know. Quote: In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. In practice it is rare to need different states of success for a completed process. Quote: I adopted the style of returning negative ints values for failures, and positive ints for success. Then your code is non-portable. Quote: Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? In the sense that it is non-portable and some OSs might do bad things I would strongly advise you broke yourself of the habit. Before anyone else chips in, there is actually only one portable way to signify failure: return EXIT_FAILURE; (or the equivalent call to exit()) Quote: Should I stick with the 0-as-success and all other values as failure standard? Yes. Quote: Do operating systems ever interpret these codes and act on them? Yes. In fact some exit codes on some OSs can result in serious consequences. -- Francis Glassborow ACCU If you are not using up-to-date virus protection you should not be reading this. Viruses do not just hurt the infected but the whole community. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Sebastian Kapfer Guest Posted: Mon Sep 29, 2003 9:36 pm    Post subject: Re: Return code On Sun, 28 Sep 2003 18:26:21 -0400, Matthew Peavy wrote: Quote: I adopted the style of returning negative ints values for failures, and positive ints for success. Would this generally be considered "wrong"? A UNIX shell would consider a return value of 0 as success, and everything else as an error. Quote: Or is it up to me as to how I define my return codes? Of course it is. The convention is that return code 0 means success, and nonzero return codes indicate different error conditions. If a single return code for success is not enough, you have to define your own schema. Just be sure that you don't surprise your users... Quote: Do operating systems ever interpret these codes and act on them? Operating systems -- maybe, I can't think of an example currently. UNIX shell, all sorts of "make" clones sure do. Your C++ compiler probably returns 0 when compilation has succeeded and nonzero otherwise. -- Best Regards, | Wer Windows-Rechner ins Internet lässt, Sebastian | braucht nicht über SWEN stänkern! Quote: -------------------------------------------------------- mailbox in "From" silently drops any mail > 20k [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter Roozemaal Guest Posted: Mon Sep 29, 2003 9:44 pm    Post subject: Re: Return code Matthew Peavy wrote: Quote: I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Returning an integer from main() dates back to the early days of C and UNIX. You should use the EXIT_SUCCESS and EXIT_FAILURE macro's for true portability. Quote: Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? Under Unix: 0 = OK, 1..255 can be used for various error codes. Quote: In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. I adopted the style of returning negative ints values for failures, and positive ints for success. It could work on your current operating system and not port to another. You are free to define (and document) your own standard, but you can be creating headaches for other programmers. Quote: Should I stick with the 0-as-success and all other values as failure standard? Do operating systems ever interpret these codes and act on them? A lot of Unix shell scripts and Unix make depend on C and C++ programs setting their exit codes according to the OK = 0 standard. Peter Roozemaal [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jerry Feldman Guest Posted: Mon Sep 29, 2003 9:50 pm    Post subject: Re: Return code On 28 Sep 2003 18:26:21 -0400 Matthew Peavy <mattsjunkemail (AT) yahoo (DOT) com> wrote: Quote: Do operating systems ever interpret these codes and act on them? Some operating systems do. Unix does not, but many Unix scripts count on a successful return as being 0. -- Jerry Feldman <gaf-nospam-at-blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jerry Feldman Guest Posted: Mon Sep 29, 2003 9:52 pm    Post subject: Re: Return code On 28 Sep 2003 18:26:21 -0400 Matthew Peavy <mattsjunkemail (AT) yahoo (DOT) com> wrote: Quote: Hi all, I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. I adopted the style of returning negative ints values for failures, and positive ints for success. Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? Should I stick with the 0-as-success and all other values as failure standard? Do operating systems ever interpret these codes and act on them? A return code of 0 is the standard Unix success used by most programs and functions. There are 2 constants defined by including cstdlib, EXIT_SUCCESS and EXIT_FAILURE. (Actually they are macros defined in stdlib.h in some implementations). -- Jerry Feldman <gaf-nospam-at-blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Attila Feher Guest Posted: Mon Sep 29, 2003 9:55 pm    Post subject: Re: Return code Matthew Peavy wrote: Quote: Hi all, I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? Faliures can be numerous (see errno.h). So while success is success, failure can be caused by missing files/path, not enough resources, wrong arguments etc. Quote: In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. There is. But since it is implementation dependent (actually mostly host-environment dependent) what numbers you can return, it is not something thet standard can define. For example, let's suppose you make a grep_cpp of your own, using the newly adopted (for the Library TR, no it is not trouble report ) regular expression library. And you decide to return the number of lines you have found. As long as your platform support that, there is no problem doing it. C++ will not stop you from doing it. You can also decide top return negative values to represent errors. And then you can write (in an imaginary script language): NUMLINES = run(grep_cpp 'someregexp' *.txt) if NUMLINES < 0 then die "Ajve! grep failed! " perror(-NUMLINES) endif Quote: I adopted the style of returning negative ints values for failures, and positive ints for success. If your hoist environment can live with it, it is OK. Quote: Would this generally be considered "wrong"? Well, as a portable concept it might be. There might be systems which only understand success and failure or only support positive values in the range of 0-255 or whatever their designers decided. Quote: Or is it up to me as to how I define my return codes? Yes, as long as you and your host environment agree. Quote: Should I stick with the 0-as-success and all other values as failure standard? Actually not all other values. In a C++ program only EXIT_FAILURE or 1 (IIRC) is defined. The rest of the possible values are all implementation defined as well as the mapping of any value for the host environment (IIRC). So it is possible that 0 will be 1 and everything else will be mapped to zero - but unlikely. Quote: Do operating systems ever interpret these codes and act on them? Not unless instructed to do so. The best example of interpreting those codes is a make process and the makefile. All commands listed to be run (unless make is instructed not to do so) are tested. I mean their exit code is tested. And if they have failed, the make process stops (unless told not to ). -- Attila aka WW [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jack Klein Guest Posted: Tue Sep 30, 2003 10:50 am    Post subject: Re: Return code On 29 Sep 2003 17:55:55 -0400, "Attila Feher" <attila.feher (AT) lmf (DOT) ericsson.se> wrote in comp.lang.c++.moderated: [snip] Quote: Actually not all other values. In a C++ program only EXIT_FAILURE or 1 (IIRC) is defined. The rest of the possible values are all implementation defined as well as the mapping of any value for the host environment (IIRC). So it is possible that 0 will be 1 and everything else will be mapped to zero - but unlikely. Just for the record, 1 is not defined. I have never seen a C or C++ compiler where the EXIT_FAILURE macro is not defined as 1, just as I have never seen one where EOF is defined as other than -1. But neither language standard makes that requirement of either macro. The only actual requirements are that EXIT_FAILURE is defines as some int value other than 0, and EOF is defined as some int value < 0. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Attila Feher Guest Posted: Tue Sep 30, 2003 10:53 am    Post subject: Re: Return code Attila Feher wrote: [SNIP] Quote: Do operating systems ever interpret these codes and act on them? I have forgotten to type (I swear it was on my mind) that I was *only* talking about the host systems I have met. Quote: Not unless instructed to do so. The best example of interpreting those codes is a make process and the makefile. All commands listed to be run (unless make is instructed not to do so) are tested. I mean their exit code is tested. And if they have failed, the make process stops (unless told not to ). -- Attila aka WW [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Attila Feher Guest Posted: Tue Sep 30, 2003 6:26 pm    Post subject: Re: Return code Jack Klein wrote: [SNIP] Quote: Actually not all other values. In a C++ program only EXIT_FAILURE or 1 (IIRC) is defined. The rest of the possible values are all [SNIP] Just for the record, 1 is not defined. I have never seen a C or C++ compiler where the EXIT_FAILURE macro is not defined as 1 [SNIP] That was the IIRC part in there. -- Attila aka WW [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Sep 30, 2003 8:53 pm    Post subject: Re: Return code Jack Klein <jackklein (AT) spamcop (DOT) net> wrote Quote: On 28 Sep 2003 18:26:21 -0400, Matthew Peavy [email]mattsjunkemail (AT) yahoo (DOT) com[/email]> wrote in comp.lang.c++.moderated: I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. Although I realize that an int is being returned (and not a bool), I regard a 0 as much closer to a "false", and 1 much more indicative of a "true", than the other way around. Is there a historical reason why 0 came to mean success and not 1? Yes, although it involves implementation-defined termination codes beyond what the standard defines. Depending on the nature of a program, or even a function within a program, there are many possible errors that can be detected. There is one and only one successful case, essentially being that none of those errors are detects. That depends on what you consider an error. Under Unix, the grep family returns 0 if it finds an occurance of the string, 1 if it doesn't, and 2 if there were any other errors. There are definitly two non-error returns here. Quote: So assuming you have an implementation that allows more than two possible return codes, 0 means "0 errors detected" and any non-zero number indicates the first detected error that caused the program to quit unsuccessfully. That's exactly how return 0 came to mean success in the early C/UNIX days. Various unsuccessful conditions resulted in various different non-zero positive values. I suspect that historically, you are right. But you have to go back very, very far. The conventions for the grep family were established at least as early as Unix version 7. Quote: In addition, from a practical point of view, there is no way to indicate different states of success, if all you have to indicate success is 0. How can there be different states of success? Why shouldn't there be? Quote: In general success means that a program was able to do what it was expected to do with the input that it received. Do you want it to use some additional standard to evaluate its performance and return a low positive value for a "fair to middling" job, but a higher positive value when it decides it really did an excellent job? Perhaps he simply wants to communicate some more information, which could be used by another program. Consider, for example, a program which determines the rights for the current user: it could return none, readonly, or all. Quote: I adopted the style of returning negative ints values for failures, and positive ints for success. Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? Depends on how you define "wrong". It certainly makes your code less portable. There are common platforms that take the int value passed to exit() or returned from main() and truncate the low 8 bits. You won't ever see a negative value on these systems, only something between 0 and 255 inclusive. As far as C++ is concerned: 0 or EXIT_SUCCESS (which is often defined to 0) means success, EXIT_FAILURE means failure, and anything else is implementation defined. What success and failure actually mean is also defined by the implementation. In the case of Unix, it is defined by the process which spawned your process; most shells simply make the value available to the shell programmer. (And you are correct that Unix only propagates the 8 low order bits. So "return 256 ;" will be interpreted as success.) Other OS's had different conventions -- VMS, for example, considered even numbers success, and odd numbers failure. The C implementation must map at least 0 to an odd number. Quote: Should I stick with the 0-as-success and all other values as failure standard? Yes you should unless you want to have porting problems. For porting, only three values are sure: 0, EXIT_SUCCESS and EXIT_FAILURE. Quote: Do operating systems ever interpret these codes and act on them? In some cases operating systems do, as well as very common programs that invoke other programs in scripts or batch processing modes. The operating system doesn't normally interpret them itself. All operating systems that I know, however, propagate the value to the parent process. And I cannot think of any job control language which doesn't have the possibility of testing them, and acting on them. Quote: The most common of these is something familiar to most programmers, even if it is not specifically part of any programming language standard. I refer to the ubitquious make utility. Every implementation of make I have ever used breaks the build on any non-zero termination status from any program it invokes. A Posix compatible make will not do this if you tell it not to, for specific commands. The interpretation of the return code is almost always up to the parent process. Quote: I have heard tell of one older operating system that only looked at the least significant bit of the termination status. It only cared whether the value was even or odd. One meant success, the other failure. I forget which was which. I never actually used such a system myself. Well, VMS is not an "older" operating system, since it is still being maintained today. The C standard says that 0 is success. Presumably, the C library for compilers under VMS map this to some odd number. At least in conformant mode. Quote: In general, needing to understand multiple reasons for failure of an entire program, as opposed to a particular function or module within a program, is a testing and debugging thing. What is the user of your program going to do with the fact that with one set of inputs it failed with a code of 3, while with another set of inputs it failed with a 2? Who is this information actually useful to? It depends on what you are doing. Under Unix, for example, you might very well want to do one thing if you didn't find the string with grep, and something else if grep couldn't open a file. Quote: If you want maximum portability, use EXIT_FAILURE (from <stdlib.h> or cstdlib>) to indicate failure, and either 0 or EXIT_SUCCESS when successful. These are the only values guaranteed to be portable to every conforming C and C++ implementation. And in practice, I think that they are the only really portable values. I use a set of about 4 values myself. They are mapped in an implementation dependant header, and if I'm not on Unix (or another system I know), they all map to either EXIT_FAILURE or EXIT_SUCCESS. This allows me to return more information when the system permits. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John L Fjellstad Guest Posted: Tue Sep 30, 2003 9:22 pm    Post subject: Re: Return code Matthew Peavy wrote: Quote: Hi all, I was wondering about commonly accepted program return codes at the termination of a program. I see from Stroustrup's FAQ that his return code of 1 is an indication of an error, whereas return 0 indicates success. snip Would this generally be considered "wrong"? Or is it up to me as to how I define my return codes? Should I stick with the 0-as-success and all other values as failure standard? Do operating systems ever interpret these codes and act on them? UNIX Shells sometimes do. C++ has also defined to constants, EXIT_SUCCESS and EXIT_FAILURE to 0 and 1 respectively. Note that in UNIX shells (sh, bash, csh etc), 0 is true and 1 is failure. If your program is called from a shell like this, the shell programmer might expect 0 and 1 to be standard. If you need to return other values, I would just document them, but keep 0 and 1 to mean success and failure. -- John L. Fjellstad A: Top posting! Q: What is the most irritating thing on Usenet? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joshua Lehrer Guest Posted: Wed Oct 01, 2003 8:15 am    Post subject: Re: Return code Jack Klein <jackklein (AT) spamcop (DOT) net> wrote Quote: Just for the record, 1 is not defined. I have never seen a C or C++ compiler where the EXIT_FAILURE macro is not defined as 1, just as I have never seen one where EOF is defined as other than -1. But neither language standard makes that requirement of either macro. The only actual requirements are that EXIT_FAILURE is defines as some int value other than 0, and EOF is defined as some int value < 0. stdlib.h on VMS defines EXIT_FAILURE to be: # define EXIT_FAILURE 0x10000002 This is because VMS uses the high order bits to specify severity. joshua lehrer factset research systems NYSE:FDS [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Sebastian Kapfer Guest Posted: Wed Oct 01, 2003 8:26 am    Post subject: Re: Return code On Tue, 30 Sep 2003 17:22:39 -0400, John L Fjellstad wrote: Quote: C++ has also defined to constants, EXIT_SUCCESS and EXIT_FAILURE to 0 and 1 respectively. *beeep* Returning 1 is non-portable. Only returning 0, EXIT_SUCCESS or EXIT_FAILURE are defined by the C++ standard. EXIT_SUCCESS and 0 are equivalent of course, but EXIT_FAILURE has no integral equivalent. Quote: Note that in UNIX shells (sh, bash, csh etc), 0 is true and 1 is failure. If your program is called from a shell like this, the shell programmer might expect 0 and 1 to be standard. By default, _every_ nonzero exit code is interpreted as an error, not just 1. $ ( exit 2; ) && echo "2 is true" || echo "2 is false" 2 is false -- Best Regards, | Wer Windows-Rechner ins Internet lässt, Sebastian | braucht nicht über SWEN stänkern! Quote: -------------------------------------------------------- mailbox in "From" silently drops any mail > 20k [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.