C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Shortened names Goto page 1, 2, 3, 4, 5  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Frederick Gotham Guest Posted: Tue Jul 11, 2006 5:38 pm    Post subject: Shortened names This is mostly about my own personal taste, but still I'd like to express my opinion: I'd like to suggest to the Committee that they use identifiers as short as possible for future additions to the standard. I like names such as: pow memcpy fmod qsort strlen puts malloc In the current Standard, I particularly think the new-style casts are monstrosities: static_cast dynamic_cast reinterpret_cast They take up a disproportionate amount of horizontal screenspace, and are a lot less pleasant to have to type out (particularly "reinterpret_cast"). I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ... but nonetheless I'd like to throw in my two cents. -- Frederick Gotham --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Guest Posted: Tue Jul 11, 2006 5:38 pm    Post subject: Re: Shortened names Frederick Gotham wrote: Quote: This is mostly about my own personal taste, but still I'd like to express my opinion: I'd like to suggest to the Committee that they use identifiers as short as possible for future additions to the standard. I like names such as: pow memcpy fmod qsort strlen puts malloc In the current Standard, I particularly think the new-style casts are monstrosities: static_cast dynamic_cast reinterpret_cast They take up a disproportionate amount of horizontal screenspace, and are a lot less pleasant to have to type out (particularly "reinterpret_cast"). I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ... but nonetheless I'd like to throw in my two cents.\ The fundamental problem with short identifiers is that they are popular, for precisely the reasons you give. As a result, the shorter and more reasonabley a keyword is, the more likely it is to clash with a name already in use by existing code. Namespaces reduce this problem, but for unqualified names, they do not eliminate it. The *_cast operators are a special case, however. Most conversions that don't occur implicitly are dangerous, at least in some contexts. Therefore, the explicit cast operators were deliberately made long and unwieldy, to discourage the unnecessary and inappropriate use of casts, and to make it easier to locate them when they are used. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top kanze Guest Posted: Tue Jul 11, 2006 5:38 pm    Post subject: Re: Shortened names Frederick Gotham wrote: Quote: This is mostly about my own personal taste, but still I'd like to express my opinion: I'd like to suggest to the Committee that they use identifiers as short as possible for future additions to the standard. For what definition of "possible"? For example, the committee could have used v, instead of vector, i instead of iterator, c instead of complex... It would certainly be easier to type: m< s, s > than std::map< std::string, std::string >. (Obviously, if we're making names as short as possible, we'll have to get rid of all this std:: junk.) There are 32949 legal two character names. I don't think off hand that the library defines more symbols than that, so strictly speaking, as short as possible means no identifier with more than two characters. Of course, some of the names will have to be pretty arbitrary---there are considerably less countries, and look at some of the two letter abbreviations for those (zh for China, for example). Quote: I like names such as: pow memcpy fmod qsort strlen puts malloc The C++ replacements actually shorten most of those: sort, instead of qsort, new instead of malloc, copy instead of memcpy, size instead of strlen, << instead of puts. That leaves pow and fmod--pow is probably optimal, given history and extra-C++ usage. But who knows, off hand, what fmod means? Especially in the C library, which generally uses an initial f as an indication that the function deals with FILE*. That one should be clearer. Quote: In the current Standard, I particularly think the new-style casts are monstrosities: static_cast dynamic_cast reinterpret_cast I think that's intentional. Tu discourage unnecessary use. Quote: They take up a disproportionate amount of horizontal screenspace, and are a lot less pleasant to have to type out (particularly "reinterpret_cast"). I can make the window on my screen 200 and some characters wide. And I don't know if you realize this, but C++ allows line breaks in expressions as well, so you can even use them and keep the line length under 80 characters (as I do). And of course, they're not something that occurs often in the code. Note too that these are keywords. There are no namespaces to prevent conflicts, and they were added relatively late. At least a minimum effort was required to avoid having them colide with likely identifiers in user code. Quote: I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ... but nonetheless I'd like to throw in my two cents. Readability is more important than writability---a program is written once, but read many times. Readability is important. Having said that, there are trade-offs involved. Something like int is so frequent that anyone working in C or C++ will recognize it immediately; very little, if any, readability would be gained by replacing it with integer. On the other hand, C experimented with replacing it with nothing---with the empty string---in some contexts, and I don't think that that experiment can be considered a success (although it's hard to have an identifier with less than 0 characters in its name). Similarly, I suspect that even you would object to using arbitrary sequences just to get the name down to two characters. In the end, the rule should be, first, consistency---you don't call it getline (without an _) but find_end (with an _), and you don't abbreviate something in one symbol, and not in another. Beyond that, trying to find meaningful short names for frequently used identifiers is probably a good idea: find is probably a better name than find_the_first_value_equal_to_the_third_argument, even if the latter is arguably clearer. For something as little used as alignment_of, however, who cares. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Victor Bazarov Guest Posted: Tue Jul 11, 2006 8:24 pm    Post subject: Re: Shortened names Frederick Gotham wrote: Quote: [...] I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ... but nonetheless I'd like to throw in my two cents. Here my half-penny: 'alignof' is not English. 'alignto' is, e.g. If you want abbreviations, they need to follow some kind of convention like 'alimntof' (so it's clearer that it's a noun, not a verb like "align" or "copy" or "put"). V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Krzysztof ¯elechowski Guest Posted: Tue Jul 11, 2006 8:25 pm    Post subject: Re: Shortened names U¿ytkownik "Frederick Gotham" <fgothamNO (AT) SPAM (DOT) com> napisa³ w wiadomo¶ci news:D3Msg.11332$j7.315496 (AT) news (DOT) indigo.ie... Quote: This is mostly about my own personal taste, but still I'd like to express my opinion: I'd like to suggest to the Committee that they use identifiers as short as possible for future additions to the standard. I like names such as: pow memcpy fmod qsort strlen puts malloc These indentifiers are short because the classic C standard requires all global identifiers to be distinguishable using their initial 6 characters, case insensitive. In order to comply with the standard and to make this rule express and instantly visible, the standard C library implementors chose to make this rule explicit by limiting the length of those identifiers to 6 letters lowercase. It is not obeyed consistently, e.g. "memmove" is equivalent to "memmov", but you have the idea. Quote: In the current Standard, I particularly think the new-style casts are monstrosities: static_cast dynamic_cast reinterpret_cast They take up a disproportionate amount of horizontal screenspace, and are a lot less pleasant to have to type out (particularly "reinterpret_cast"). I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ.... but nonetheless I'd like to throw in my two cents. The identifiers printf and memcpy are "monstrosities" for every C language student. Without knowing 6 character rule sparing one character from memcopy is inexplicable. It gives no advantage in typing and makes the name unreadable. And why did not they choose the identifier "memmve" as well? The abbreviations are inconsistent and hard to learn. On the other hand, nothing prevents you from #defining scast, dcast, rcast, alignof and using them in your code. However, be warned that coining abbreviations for casts is deprecated because their names are chosen to constitute a physical discouraging barrier against abusing unsafe language constructs, *especially* "reinterpret_cast", and to make the design of static code analysis tools easier. Burdening the committee with the duty of managing abbreviations and shortcuts is unreasonable. And what happens if some C/UNIX addict prefers algnof to alignof? Quote: -- Frederick Gotham Christopher Yeleighton --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Guest Posted: Tue Jul 11, 2006 8:48 pm    Post subject: Re: Shortened names kanze wrote: Quote: Frederick Gotham wrote: .. have to be pretty arbitrary---there are considerably less countries, and look at some of the two letter abbreviations for those (zh for China, for example). Actually, for native speakers of mandarin, zh makes a lot of sense, since the mandarin word for China is Zhongguo. .. Quote: usage. But who knows, off hand, what fmod means? Especially Floating point MODulus. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Frederick Gotham Guest Posted: Tue Jul 11, 2006 11:10 pm    Post subject: Dumbed-down posted: Quote: Therefore, the explicit cast operators were deliberately made long and unwieldy, to discourage the unnecessary and inappropriate use of casts, and to make it easier to locate them when they are used. I really don't understand this reasoning. A high-quality programming language like C++ should be designed for expert programmers, not for people learning to program. There's plenty of alternatives out there for the not-so-apt: Visual Basic, Java. No expert programmer would use a cast unnecessarily, e.g.: int i; long j = (long)i; /* or static_cast if you prefer */ And who's to say if a cast is "inappropriate"... ? C was built on a foundation of programmers who are competent, not on holding the hands of beginners who aren't out of diapers yet. C++ should build on this proud mentality. My efficient, fully-portable, Standard-compliant code contains many casts. Some are necessary to make the code compile. Some are necessary to suppress compiler warnings. But they're all there for a reason! Why should expert programmers be burdened with unwieldy names? It insults human intelligence. Some may hold in derision my use of old-style casts, but I'll definitely prefer: int *pi = (int*)pc; over: int *pi = reinterpret_cast<int*>(const_cast<char*>(pc)); -- Frederick Gotham --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Guest Posted: Wed Jul 12, 2006 4:17 pm    Post subject: Re: Dumbed-down Frederick Gotham wrote: Quote: posted: Therefore, the explicit cast operators were deliberately made long and unwieldy, to discourage the unnecessary and inappropriate use of casts, and to make it easier to locate them when they are used. I really don't understand this reasoning. A high-quality programming language like C++ should be designed for expert programmers, not for people learning to program. There's plenty of alternatives out there for the not-so-apt: Visual Basic, Java. No expert programmer would use a cast unnecessarily, e.g.: Most of the people who program in C++ are not experts. Most of the code I've had to deal with in my job that wasn't written by me contains many poorly written spots, and inappropriate use of casts is one of the most popular kinds of defects. Also, it's not as if this is a major inconvenience; the longer names can be partially justified simply by the fact they're easier to search for. If you've ever had the misfortune of having to track down all the places where a variable with a name like 'i' is used, you start to appreciate the advantages of longer identifiers. Quote: int i; Perhaps you haven't had that misfortune yet. Quote: long j = (long)i; /* or static_cast if you prefer */ And who's to say if a cast is "inappropriate"... ? An expert can give you an answer to that which is many pages long. Here's a few general categories of problems: A cast is inappropriate if it produces the wrong result under circumstances the programmer failed to consider. A cast is inappropriate if it causes an unnecessarily wasteful extra step. A cast is inappropriate if it masks a defect due the fact that the object being converted to the correct type should have been declared with that type in the first place. Quote: C was built on a foundation of programmers who are competent, not on holding the hands of beginners who aren't out of diapers yet. C++ should build on this proud mentality. C++ was deliberately designed to make it easier to avoid many of those errors that your hypothetical "expert" programmers would never make, but which real world programmers make all the time. For example, the concept of constructors and destructors, and the rules that call for them to be automatically invoked, make it a lot easier to avoid problems associated with bookend code such as malloc()/free() and fopen()/fclose(). Quote: Why should expert programmers be burdened with unwieldy names? It insults human intelligence. I think you're overrating human intelligence, if you take this as an insult. Human intelligence is messy, inaccurate, and unreliable. Good engineering practice, including the design of programming languages, takes that into consideration. Quote: Some may hold in derision my use of old-style casts, but I'll definitely prefer: int *pi = (int*)pc; over: int *pi = reinterpret_cast<int*>(const_cast<char*>(pc)); Let me join the people who deride you for that choice. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top kanze Guest Posted: Wed Jul 12, 2006 4:21 pm    Post subject: Re: Shortened names "Krzysztof ¯elechowski" wrote: Quote: U¿ytkownik "Frederick Gotham" <fgothamNO (AT) SPAM (DOT) com> napisa³ w wiadomo¶ci news:D3Msg.11332$j7.315496 (AT) news (DOT) indigo.ie... This is mostly about my own personal taste, but still I'd like to express my opinion: I'd like to suggest to the Committee that they use identifiers as short as possible for future additions to the standard. I like names such as: pow memcpy fmod qsort strlen puts malloc These indentifiers are short because the classic C standard requires all global identifiers to be distinguishable using their initial 6 characters, case insensitive. In order to comply with the standard and to make this rule express and instantly visible, the standard C library implementors chose to make this rule explicit by limiting the length of those identifiers to 6 letters lowercase. It is not obeyed consistently, e.g. "memmove" is equivalent to "memmov", but you have the idea. memmove was added much, much later. I suspect that much of C's terseness can be traced back to the fact that when C was being invented, the usual terminal was a teletype. And if you've ever been in a room where a teletype is at work, you can understand why the less characters, the better. (This isn't to say that the linker issue wasn't also a consideration.) By the time C was being standardized, teletypes were already on their way out, and software engineering issues were beginning to be understood. The functions added during standardization generally are not so restricted by the length of names (but existing conventions were followed where they were established). Of course, all this is well over fifteen years ago---twenty or more for the teletypes. Locking a language into these restrictions today is certainly not a good idea. Quote: In the current Standard, I particularly think the new-style casts are monstrosities: static_cast dynamic_cast reinterpret_cast They take up a disproportionate amount of horizontal screenspace, and are a lot less pleasant to have to type out (particularly "reinterpret_cast"). I would prefer the likes of: alignof instead of: alignment_of Of course, this is just my own opinion, and others' opinions may differ... but nonetheless I'd like to throw in my two cents. The identifiers printf and memcpy are "monstrosities" for every C language student. Without knowing 6 character rule sparing one character from memcopy is inexplicable. It gives no advantage in typing and makes the name unreadable. And why did not they choose the identifier "memmve" as well? The abbreviations are inconsistent and hard to learn. It depends. When there is a large set of functions, working together, like the str... functions, the abbreviation works. Otherwise, of course, no. Quote: On the other hand, nothing prevents you from #defining scast, dcast, rcast, alignof and using them in your code. However, be warned that coining abbreviations for casts is deprecated Disparaged, not deprecated. The preprocessor is not going to be removed from the language. Using the preprocessor to change the language, in general, is disparaged. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Frederick Gotham Guest Posted: Thu Jul 13, 2006 12:38 am    Post subject: Re: Dumbed-down Keith Thompson posted: Quote: Most of the casts I've seen that are "necessary to suppress compiler warnings" are actually unnecessary; rather than fixing errors, they mask them. I'm not necessarily suggesting that that's the case with *your* casts, but I'd be interested in seeing examples where such casts are necessary and useful. Gladly. Let's say we have a 64-Bit unsigned integer to store the Gross Domestic Product of the USA for a given year. The units are US dollars: unsigned long long const gdp = 12485725486486764U; We also have a 64-Bit unsigned integer to store the population of the USA for a given year. The units are humans: unsigned long long const population = 297279178249U; Now let's say we have a 16-Bit unsigned integer to store the Gross Domestic Product per capita for a given year. The units are US dollars: unsigned gdp_per_capita = (unsigned)(gdp / population); -- Frederick Gotham --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Pete Becker Guest Posted: Thu Jul 13, 2006 12:45 am    Post subject: Re: Dumbed-down James Dennett wrote: Quote: Frederick Gotham wrote: posted: Therefore, the explicit cast operators were deliberately made long and unwieldy, to discourage the unnecessary and inappropriate use of casts, and to make it easier to locate them when they are used. I really don't understand this reasoning. It helps to reduce defect densities. Yup. If you rewrite a piece of code and replace all identifiers with longer ones, you've got fewer defects per character. (Sorry, couldn't resist.) --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Bronek Kozicki Guest Posted: Thu Jul 13, 2006 2:18 am    Post subject: Re: Dumbed-down Frederick Gotham wrote: Quote: A high-quality programming language like C++ should be designed for expert programmers, not for people learning to program. mistake. Literally everyone programming in some language is, at some stage, just a person "learning the language". Language that is too difficult to learn will quickly become niche language, and (I guess) most people here do not want that. B. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Pavel Vozenilek Guest Posted: Thu Jul 13, 2006 3:10 am    Post subject: Re: Dumbed-down "Pete Becker" wrote: Quote: [longer identifiers] helps to reduce defect densities. Yup. If you rewrite a piece of code and replace all identifiers with longer ones, you've got fewer defects per character. (Sorry, couldn't resist.) A very deep collection of scholar studies and recommendations about identifiers can be found in book "The New C Standard" by Derek M. Jones (online http://www.knosof.co.uk/cbook/cbook.html), chapter 6.4.2.1. Influence of identifier length on error rates is covered here as well. /Pavel --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Keith Thompson Guest Posted: Thu Jul 13, 2006 4:53 am    Post subject: Re: Dumbed-down fgothamNO (AT) SPAM (DOT) com (Frederick Gotham) writes: Quote: Keith Thompson posted: Most of the casts I've seen that are "necessary to suppress compiler warnings" are actually unnecessary; rather than fixing errors, they mask them. I'm not necessarily suggesting that that's the case with *your* casts, but I'd be interested in seeing examples where such casts are necessary and useful. Gladly. Let's say we have a 64-Bit unsigned integer to store the Gross Domestic Product of the USA for a given year. The units are US dollars: unsigned long long const gdp = 12485725486486764U; We also have a 64-Bit unsigned integer to store the population of the USA for a given year. The units are humans: unsigned long long const population = 297279178249U; Last I heard, the C++ standard doesn't support long long or unsigned long long (though I understand that's likely to change). Quote: Now let's say we have a 16-Bit unsigned integer to store the Gross Domestic Product per capita for a given year. The units are US dollars: unsigned gdp_per_capita = (unsigned)(gdp / population); (unsigned int is *at least* 16 bits, of course, but it happens that the result, 42000, is guaranteed to fit in an unsigned int.) What warning does the cast inhibit? I don't get a warning with or without the cast. (I do get warnings on the literals, depending on command-line options.) The cast specifies an explicit conversion; without it, there's still an implicit conversion. There's no obvious reason why adding or removing the cast should affect whether there's a warning. There are a few cases where casts are appropriate. Certain mixed arithmetic expressions, where you need to override the default conversions, are one example. Your code above, where you use a cast to specify a conversion that would have happened implicitly anyway, is not, IMHO, a good example. -- Keith Thompson (The_Other_Keith) kst-u (AT) mib (DOT) org <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst> We must do something. This is something. Therefore, we must do this. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] Back to top Ron Natalie Guest Posted: Thu Jul 13, 2006 7:07 am    Post subject: Re: Shortened names kuyper (AT) wizard (DOT) net wrote: Quote: The fundamental problem with short identifiers is that they are popular, for precisely the reasons you give. As a result, the shorter and more reasonabley a keyword is, the more likely it is to clash with a name already in use by existing code. Namespaces reduce this problem, but for unqualified names, they do not eliminate it. It doesn't help for things like the cast operators and aligment_of which are not NAMES but reserved words in the language. Quote: The *_cast operators are a special case, however. Most conversions that don't occur implicitly are dangerous, at least in some contexts. Therefore, the explicit cast operators were deliberately made long and unwieldy, to discourage the unnecessary and inappropriate use of casts, and to make it easier to locate them when they are used. Well that's a stupid reason. Actually it is to be encouraged to use the C++-style casts over the SHORTER AND EASIER TO TYPE C-STYLE ONES as it limits the range of possible conversions done by any one operator. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ] 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, library and standards All times are GMT Goto page 1, 2, 3, 4, 5  Next Page 1 of 5   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.