C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Evolution of C++ : Thinking ahead of what's to come - Part 1 Goto page 1, 2, 3 ... 17, 18, 19  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Michaelangelo Guest Posted: Sun Aug 08, 2004 10:09 am    Post subject: Evolution of C++ : Thinking ahead of what's to come - Part 1 A modest (C++ Evolution) Proposal [Sorry for the LONG introduction, but it helps sets the stage of where I am coming from... and going...] I've been following C++ since I became first aware of it in the early 90's. Looking forward, once we have conforming C++ compilers (ha!), the next step is standardizing the feature set amongst platforms & compilers. I'd like to go one step further, and discuss / address what the next successor of the language might possible look like. I'll call this mythical language, C^2, as that's the name I've dubbed it in my design notes. ;-) Why? Isn't it a little early to be talking about the "next" language, when the current one is still being standardized? No, because a) This already happened to C & C++, and didn't impact C++ too much. Growing pains are a fact of life. b) A (useful) language is never a "static" thing. As long as it being used, there are new paradigms being invented that the current language does not allow oneself to easily express these idioms in a more compact way. These paradigms should be explored, so that they eventually might find their way back into the language. A good example was Operator Overloading, which was a natural growth, from classes. Anytime something becomes popular, it is abbreviated. Symbols are the pinnacle of this. In mathematics we don't say: C IS_EQUAL_TO A PLUS B, we write C = A + B, or CosAngle = VectorA . VectorB Normal = VectorA x VectorB etc. If we're not carefull, these discussion can quickly turn into arguments on "religion". Instead of heated debate about X or Y, avoiding X because of Y, etc., I'd like to instead list both the Pro's and Con's of X and Y. I'm of the belief that just because something can be abused, doesn't mean it should be avoided. The programmer should know what he is doing, and the compiler should point out warnings (as much as possible) in potential mis-uses. I'm aware that the question of design idealogy then becomes one of: i) Is this even feasible? ii) It so, why should it be done? iii) If not, if it is a rarely used feature, how useful is it? I'm not the first to think beyond C++, as "D", "Heron", Alexandrescu, GNU's C++ (g++), etc, have all influenced, and have addressed some of the same (deficient?) issues. I'd really like to see this post turn into: 1) A Catalog of ideas, so people (like me!) don't keep (re-) submitting the same redundant ones :) 2) A summary of a wish-list language features. The only requiremen is that there has to be "What problem does this idea/feature solve that is not tied to specifically one application?" It would be neat, if compiler writings find this discussion useful, tried things out, and then eventually become incorporated into standard C++. (I really wish I understood compiler technology better, and had the time to be able to write a language translator. i.e. C^2 to C++, but I alas, I digress as graphics and math are my forte then compiler technology.) Aside, is there a document that summarizes the various vendors extensions to C++? In some ways, this process is analogous to what happens in OpenGL. There is a standard that everyone must implement, but there are extensions, where vendors can implement their own ideas. (Except this is much harder to do in a compiler.) After a few years, when the emergent "solution" has been known, it is rolled into the next version, and is standardized. Again aside, has anyone already documented where this has happened in C++? These notes, for the most part, don't worry about implementation details. I realize that in the Real-World (TM) engineering is all about tradeoffs. Some things gotta give. i.e. On a civilization scale we didn't get to our currently level of technology because we lacked the ability to dream; it was BECAUSE of it. Someone dreamed that they could see things smaller then they could with the naked unaided eye. After the magnifying glass, we eventually reached the Electron microscope. In that spirit, this post is a "Dream" of one person's "ideal" C++ language, with (hopefully) other's people comments. :) I'm a game programmer (console & PC), and grew up, and in love with C's conciseness, and efficiency. I found it really struck the right balance between compactness, and pseudo-code. (Everyone knows that C is jokingly referred to as The High Level Portable Assembler.) C++ maintained the vision, while striking the right note between Type-Safety vs Dynamic Types - which is really the same thing as speed vs flexibility. How this all started for me, was a few years back, I was wondering why some of the things in C and C++ were such hacks, and if there was a way to "fix" them after writing tedious code in C++, especially "fast" cross-platform code, and trying to work around some of the limits the language sets, which prevented some optimizations, without resorting to verbose code. Eventually I reasoned that most of this could be automatically "translated", much the same way CFront originally extended C, but then I saw that there were a few things that here was no way it could fit into C++ model without extensive compiler changes. i.e. You can't initialize non-aggregates. Argh, in my cases, these are pseudo-POD and pseudo-classes - just a few operations on them. Ok, I'll use inheritance to work around this problem. A good example is a constant type, that: a) I don't want taking up space in the block initialization data section (integer and floating constants can often be an "immediate load" in assembly.) b) being initialized at run-time, when it should be at compile-time. i.e. const Vector3f ZERO( 0, 0, 0 ); Looking back over the growth of C and C++, I see the paradigms that C++ can express becoming even more abstract, and powerful. We're already pushing the limits with generic programming - Templates + OOP + Macros. "Boost" has taken this concept to the extreme. In the past that means I have had to deal with 3 platforms: PCs, Linux, PS2, namely compilers: Microsoft's Visual C++, Gnu's G++, and Metrowerks, and tried to work around something that works on one platform and not another. One of the basic issues was that I needed a portable way to designate primitive types (such as Vectors, Matrices, etc) that are - fastest on that platform (for calculations) (taking into account alignment) - a specified size, no more, no less (for serialization) One of the things I found lacking is a naming scheme that is consistent across platforms, especially when you get to anything bigger then 32 bits. I was a big fan of C++ being a better C then C, and now that I'm more familiar with C++ (understanding how things are implemented under the hood, where the hidden costs are), I find myself in the same patten: I'm looking at a better C++ then C++. Namely anything that helps me to write less code, and automate checking. Yes, I'll list pet peeves, criticisms, and rants about the language, but I'm looking for feedback on these different ideas. I will be the first to admit, that a lot of these ideas are half-baked, and have been discussed before. But if a more advanced "Chef" can give his tips on how to "cook" them properly, and/or say "This will never taste" good (with past references), then the goal has been achieved. I also admit that I am ignorant of the many solutions used through the standards, (POSIX, Standard C++ headers,etc) so if something sounds stupid - then it probably is :) Anytime a language changes, it has to address the "Backward Compatibility" issue. In general there are 2 choices: 1) As much as possible 2) Clean slate, intentionally breaking things. At what point does language evolution go from (1) to (2) ? This is parallel or analogous to an API, because that's really what the compiler is providing. As such, there are things that should be scrapped, and others continued to be taken to their logical conclusion IMHO. So without further ado, here is my legend first, then a list of things I've been wondering about over the past few years: Synopsis : A summary of what the problem is Problem : A detailed description of the problems it causes. Appears : When/Where it appears in Real-World code. Proposal : What the change would look like. Feasibility : Implementation difficulty (as I understand it.) i.e. Trivial, Difficult, Impossible Ramifications: Side-effects, or why we shouldn't do this. I have NOT included a Rating. i.e. Rational, Half-Baked, Loony/Insane. I would appreciate being told which ideas are just plain stupid, and which ones have merit, and WHY. This way I can add it to each section, under "Notes." In time, this would turn into a C++ Ideas FAQ. For now, it's just someone rambling about why couldn't the language be better :-) // ======================================== Synopsis: Scalability in Primitive Type Names Problem: What names are going to be used when we have even more precise (or less precise) representations of numbers? You can see this in the mess of how C/C++ deals with chars, integers, and floats of different sizes. float; // really 32 bit double; // really 64 bits long double; // supposed to be 80 bits, but depends on hardware // Theoretical future problem examples... // We want an 128-bit floating-point value // Are we going to continue to use such hacks as this??? long long double Real_128bit_t; //or long double double Real_128bit_t; // I could imagine support for a "Half-Floating Point" // It is used in HDR for Graphic's Floating-Point FrameBuffers. // One example of support is Industrial Light & Magic's OpenEXR. // http://www.openexr.org/ short float Real_16bit_t; The whole designation of "word", "double-word", "half-word", "short" vs "long", is a relative classification, anyways. It depends on the platform. It is a mistake to insist on this naming convention, when their intent is being mis-used. I believe this is a signal that the API wasn't well designed, when you have functions like: GetWindow( WORD handle ) GetWindow( DWORD handle ) etc. Yes, I know that it comes from an archaic time of when computers were still being designed and implemented with "innovative" solutions. In fairness, it was unimaginable that we'd have commodity computers with hardware of MULTI Gigabytes of RAM! But we should be asking these questions: i.e. Is anyone REALLY doing C++ development on machines that support 36-bit words ?? i.e. The HP48 Calculator uses RAM that is NIBBLE based, but we really expect to be running C++ on these oddball embedded CPU's? (If yes, I could imagine an int4 type being supported.) Appears: When writing portable code for serialization, or algorithms designed to work on a specific data-type. (Color Space conversions on fixed bit-depths are a good example.) Proposal: Get rid of this "long long" crap, and adopt a consistent naming schema, with the traditional cardinal types first deprecated, and then eventually gone. i.e. // Valid ... int8 int16 int32 int64 int128 // ... and the corresponding unsigned versions... uint8 uint16 uint32 // ...etc... // Floating-point type names (finally!) don't // depend on some hacked naming convention float16 float32 float64 float80 float128 // "Native" fast types, size is implementation dependent. int float char // Character Types -- it IS 2004 after ALL. // Unicode is becoming the standard for strings, not ASCII. // especially since Unicode-16 misses about 30,000 glphys char8 char16 char32 // Invalid short long double w_char What this means is that all us "library" authors no longer have to keep re-writing these definitions above in our "Types.h" file. We are free'd from having to assume the size of the primitive types, as we know their exact sizes, which are guaranteed, instead of the quasi-definition of short being bigger then a character, but smaller then an int, etc. (What we really want is something Feasibility: 1) Trivial, mostly already done today, via typedefs, except for native char32 support. 2) Time-Consuming - need to implement ALL the string functionality for 32-bit characters. Ramifications: 1) Due to legacy support, might be impossible in C++. 2) How do you safeily specifically initialize a floating point number of a certain size? i.e. // C/C++ // compiler may warn float to double truncation float f_implicit = 3.14159265358979323846 ; float f_explicit = 3.14159265358979323846f; // OK double d_implicit = 3.14159265358979323846 ; // OK // there is no explicit form for double that I'm aware of // double d_explicit = 3.14159265358979323846d; // compiler may complain about truncation long double L_implicit = 3.14159265358979323846 ; long double L_explicit = 3.14159265358979323846L; // OK // C^2 - Will this cause any problems? // Compiler may issue warning that value was truncated? float32 _PI_32 = 3.141592653589793; float64 _PI_64 = 3.141592653589793; // Or is a size specifically needed? // the float designator "f32" becomes "lost" in the constant float32 _PI_32 = 3.14159265358f32; float64 _PI_64 = 3.14159265358f64; float32 _PI_32 = 3.14159265358_32; // Little easier to read float64 _PI_64 = 3.14159265358_64; // Or 'f' means "Tell compiler not to warn about truncation?" float32 _PI_32 = 3.14159265358979323846f; float64 _PI_64 = 3.14159265358979323846f; // ======================================== This post is already long enough, so I'll post Part 2 later after I've had a chance to clean up and organize the other ideas. Some make sense, some don't. It's important to go into the details on both. I apologize in advance for any flames this post has intentionally, or will unintentionally re-ignite... and/or due to my ignorance of the current C++ standards and implementation. (Hey, you gotta start somewhere.) I'm looking forward to hearing on where people think C++ is going, and stimulate some discussion on this interesting topic. Please follow up all replies to the group. Cheers _Michaelangelo_ Yet another C/C++ Lover. -- Geometry is frozen Music - Pythagoras [ 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: Sun Aug 08, 2004 9:52 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa In article <92jbh0tl9urmrldo5nv0m659icd4mq11c2 (AT) 4ax (DOT) com>, Michaelangelo <Michaelangelo (AT) email-will-be-ignored (DOT) com> writes Quote: A modest (C++ Evolution) Proposal [Sorry for the LONG introduction, but it helps sets the stage of where I am coming from... and going...] I've been following C++ since I became first aware of it in the early 90's. Looking forward, once we have conforming C++ compilers (ha!), the next step is standardizing the feature set amongst platforms & compilers. I'd like to go one step further, and discuss / address what the next successor of the language might possible look like. I'll call this mythical language, C^2, as that's the name I've dubbed it in my design notes. May I suggest that you first research what is already being worked on? Visit http://www.open-std.org/jtc1/sc22/wg21/docs/papers (it seems to be down at the moment) and see the ideas already being worked on. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Terje Slettebø Guest Posted: Sun Aug 08, 2004 10:14 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa "Michaelangelo" <Michaelangelo (AT) email-will-be-ignored (DOT) com> wrote Quote: A modest (C++ Evolution) Proposal // ======================================== Synopsis: Scalability in Primitive Type Names Problem: What names are going to be used when we have even more precise (or less precise) representations of numbers? Check the C99 <stdint.h> header, also available for C++ ([url]http://www.boost.org/boost/cstdint.hpp)[/url]. There's also an alternative C++ solution ([url]http://www.boost.org/boost/integer.hpp):[/url] int_t<num bits>, etc. Quote: You can see this in the mess of how C/C++ deals with chars, integers, and floats of different sizes. float; // really 32 bit double; // really 64 bits long double; // supposed to be 80 bits, but depends on hardware // Theoretical future problem examples... // We want an 128-bit floating-point value // Are we going to continue to use such hacks as this??? long long double Real_128bit_t; //or long double double Real_128bit_t; float_t<32>, float_t<80>, float_t<128>, etc. seems like a possible solution. One might also have, analogous to <stdint.h>: float_least_t<64> (at least 64 bits), etc. With typedef templates/template aliases ([url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1449.pdf)[/url], one could also avoid the "::type", as in "float_t<32>::type" if these are implemented as regular templates. The implementation might be: template<unsigned int Bits> struct float_t; template<> struct float_t<32> { typedef float type; // (or some other implementation-specific type for "float") }; .... template<unsigned int Bits> // Template alias using float_t = float_t<Bits>::type; Use: float_t<32> value; // Declares, in this case, a variable of type "float" This creates an open-ended solution, and avoids the "long long long..." madness. To get types with the same semantics as the current types, such as "int", which is defined to be at least 16 bits, and which is supposed to have the native word size (which is typically the fastest), one could use: int_fast_t<16> value; // Alternative to "int"; the fastest type, at least 16 bits Quote: // I could imagine support for a "Half-Floating Point" // It is used in HDR for Graphic's Floating-Point FrameBuffers. // One example of support is Industrial Light & Magic's OpenEXR. // http://www.openexr.org/ short float Real_16bit_t; Or "short short short..." madness. ;) float_t<16> value; // And that's that. :) Quote: i.e. The HP48 Calculator uses RAM that is NIBBLE based, but we really expect to be running C++ on these oddball embedded CPU's? (If yes, I could imagine an int4 type being supported.) Or int_t<4> (or int_least_t<4>/int_fast_t<4>) Quote: Appears: When writing portable code for serialization, or algorithms designed to work on a specific data-type. (Color Space conversions on fixed bit-depths are a good example.) Proposal: Get rid of this "long long" crap, and adopt a consistent naming schema, with the traditional cardinal types first deprecated, and then eventually gone. i.e. // Valid ... int8 int16 int32 int64 int128 An advantage with the int_t<bits> solution is that the number of bits is parameterised, so you don't have to do a global replace or typedef, to change the number of bits. You might even compute it from traits: typedef int_t<some_trait_computation<...>::value> my_type; Regards, Terje [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sun Aug 08, 2004 10:22 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Michaelangelo <Michaelangelo (AT) email-will-be-ignored (DOT) com> writes: Quote: A modest (C++ Evolution) Proposal [...] Quote: Isn't it a little early to be talking about the "next" language, when the current one is still being standardized? C++ has been standardized for almost 5 years now. As I understand it, the question has already been asked as to whether to create a new version of the standard, stick to the current version, or abandon the standard completely. (I haven't followed the question closely lately, but I can't imagine the answer being anything but to update the standard with a new version.) [...] Quote: I'm not the first to think beyond C++, as "D", "Heron", Alexandrescu, GNU's C++ (g++), etc, have all influenced, and have addressed some of the same (deficient?) issues. I don't know about "Heron" but the other three are three radically different things: - D is presented as an alternative to C++. According to its creators, C++ can't be fixed. (That's a radical simplification, of course.) - Everything I've read from Alexandrescu is about what we can do with today's language. I don't doubt that he also has some ideas as to how to improve it, but that doesn't seem to be his principle direction. - G++ has (or had) a few extensions, but their current orientation is to implement the existing standard as strictly as possible. And not to extend it or to define a new language. [...] Quote: Aside, is there a document that summarizes the various vendors extensions to C++? Most of the "extensions" I know of are concerned with backward compatibility. Most of the implementors can't manage to implement the standard completely, much less add extensions. [...] Quote: How this all started for me, was a few years back, I was wondering why some of the things in C and C++ were such hacks, I'm not sure that "hacks" is the correct word. There are a lot of things in C and in C++ that I don't like. But the languages grew to meet concrete, pragmatic needs, not theoretical ideals. What may seem like a "hack" today was almost always an essential pragmatic compromise when it was adopted. IMHO, this is the greatest problem C++ (and C, for that matter) faces: how to go beyond the pragmatic compromises, not that the reasons which forced them have disappeared. I know that I'm not alone in fealing this, and that some very important C++ experts would like to find a replacement for the preprocessor, perhaps a better declarations syntax, or a better solution for null pointer constants. Some very competent people are also looking at simplifications like garbage collection, which modern technology makes acceptable, where as when the languages were conceived, it would have required unacceptable runtime costs. Quote: and if there was a way to "fix" them after writing tedious code in C++, especially "fast" cross-platform code, and trying to work around some of the limits the language sets, which prevented some optimizations, without resorting to verbose code. Eventually I reasoned that most of this could be automatically "translated", much the same way CFront originally extended C, but then I saw that there were a few things that here was no way it could fit into C++ model without extensive compiler changes. i.e. You can't initialize non-aggregates. Argh, in my cases, these are pseudo-POD and pseudo-classes - just a few operations on them. Ok, I'll use inheritance to work around this problem. A good example is a constant type, that: a) I don't want taking up space in the block initialization data section (integer and floating constants can often be an "immediate load" in assembly.) b) being initialized at run-time, when it should be at compile-time. i.e. const Vector3f ZERO( 0, 0, 0 ); IMHO, not a problem. Supposing that all of the functions in complex are inline (which they should be), it would be a very poor compiler which didn't lay something like: complex< double > const i( 0.0, 1.0 ) ; directly in memory. Unless, of course, the platform was such that it really didn't make a difference and the analysis necessary to find the optimization was more expensive than possible gain (the case for any modern Windows or Unix based compiler, for example). Quote: Looking back over the growth of C and C++, I see the paradigms that C++ can express becoming even more abstract, and powerful. We're already pushing the limits with generic programming - Templates + OOP + Macros. "Boost" has taken this concept to the extreme. In the past that means I have had to deal with 3 platforms: PCs, Linux, PS2, namely compilers: Microsoft's Visual C++, Gnu's G++, and Metrowerks, and tried to work around something that works on one platform and not another. That's because C++ has changed too rapidly. If cross platform compatibility is the only criteria, we should ban all changes. Quote: One of the basic issues was that I needed a portable way to designate primitive types (such as Vectors, Matrices, etc) that are - fastest on that platform (for calculations) (taking into account alignment) - a specified size, no more, no less (for serialization) That, IMHO, is the sort of thing that can only be handled by pragma. Quote: One of the things I found lacking is a naming scheme that is consistent across platforms, especially when you get to anything bigger then 32 bits. I was a big fan of C++ being a better C then C, and now that I'm more familiar with C++ (understanding how things are implemented under the hood, where the hidden costs are), I find myself in the same patten: I'm looking at a better C++ then C++. Namely anything that helps me to write less code, and automate checking. Yes, I'll list pet peeves, criticisms, and rants about the language, but I'm looking for feedback on these different ideas. I will be the first to admit, that a lot of these ideas are half-baked, and have been discussed before. But if a more advanced "Chef" can give his tips on how to "cook" them properly, and/or say "This will never taste" good (with past references), then the goal has been achieved. I also admit that I am ignorant of the many solutions used through the standards, (POSIX, Standard C++ headers,etc) so if something sounds stupid - then it probably is :) Anytime a language changes, it has to address the "Backward Compatibility" issue. In general there are 2 choices: 1) As much as possible 2) Clean slate, intentionally breaking things. At what point does language evolution go from (1) to (2) ? Never. Unless it changes the name. On the other hand, compromises are possible. There aren't just two extremes. Still, if the langauge is named C++, we expect it to compile 99% of the existing code, if not more. Quote: // ======================================== Synopsis: Scalability in Primitive Type Names Problem: What names are going to be used when we have even more precise (or less precise) representations of numbers? You can see this in the mess of how C/C++ deals with chars, integers, and floats of different sizes. float; // really 32 bit double; // really 64 bits long double; // supposed to be 80 bits, but depends on hardware On mine, it is 128 bits. On others, 64 bits. Of course, I know of hardware where float and double are 48 bits. Not that it matters. The actual precision and range are different between my current platform (Sun Sparc) and an IBM mainframe, even though the sizes are the same. Quote: // Theoretical future problem examples... // We want an 128-bit floating-point value // Are we going to continue to use such hacks as this??? long long double Real_128bit_t; //or long double double Real_128bit_t; // I could imagine support for a "Half-Floating Point" // It is used in HDR for Graphic's Floating-Point FrameBuffers. // One example of support is Industrial Light & Magic's OpenEXR. // http://www.openexr.org/ short float Real_16bit_t; The whole designation of "word", "double-word", "half-word", "short" vs "long", is a relative classification, anyways. It depends on the platform. It is a mistake to insist on this naming convention, when their intent is being mis-used. I believe this is a signal that the API wasn't well designed, when you have functions like: GetWindow( WORD handle ) GetWindow( DWORD handle ) etc. Yes, I know that it comes from an archaic time of when computers were still being designed and implemented with "innovative" solutions. In fairness, it was unimaginable that we'd have commodity computers with hardware of MULTI Gigabytes of RAM! But we should be asking these questions: i.e. Is anyone REALLY doing C++ development on machines that support 36-bit words ?? Yes. At least I think so, as such machines are still being sold today. Quote: i.e. The HP48 Calculator uses RAM that is NIBBLE based, but we really expect to be running C++ on these oddball embedded CPU's? (If yes, I could imagine an int4 type being supported.) The C++ standard requires that bytes be at least 8 bits. Quote: Appears: When writing portable code for serialization, or algorithms designed to work on a specific data-type. (Color Space conversions on fixed bit-depths are a good example.) Serialisation hasn't been a real problem, IMHO. I've written code for data transfer (Internet and pre Internet) on machines with variable word sizes. It never caused any problem. Quote: Proposal: Get rid of this "long long" crap, and adopt a consistent naming schema, with the traditional cardinal types first deprecated, and then eventually gone. i.e. // Valid ... int8 int16 int32 int64 int128 // ... and the corresponding unsigned versions... uint8 uint16 uint32 // ...etc... There's something similar in C already; I suppose it will be in the next version of C++. Of course, it does make the distinction as to whether I want the minimum efficient size with so many bits, or an exact size. Quote: // Floating-point type names (finally!) don't // depend on some hacked naming convention float16 float32 float64 float80 float128 What does that buy us? What counts with floating point is the precision, the max and min values, how rounding works, etc. These vary greatly, even when the types are the same size -- see the differences between the floating point on an IBM mainframe (base 16) and that on a PC, for example. Quote: // "Native" fast types, size is implementation dependent. int float char That's the current situation. Quote: // Character Types -- it IS 2004 after ALL. // Unicode is becoming the standard for strings, not ASCII. // especially since Unicode-16 misses about 30,000 glphys char8 char16 char32 In principle, a quality implementation would use Unicode for wchar_t on any platform where it made sense. Historical reasons interfere, however, and at least two major platformes (AIX, Windows) use 16 bit wchar_t rather than 32 bit Unicode. Again, C has a proposal (I don't think it is part of the C99 standard) for this, which will probably end up as part of C++, in some distant future. Quote: // Invalid short long double w_char What this means is that all us "library" authors no longer have to keep re-writing these definitions above in our "Types.h" file. We are free'd from having to assume the size of the primitive types, as we know their exact sizes, which are guaranteed, instead of the quasi-definition of short being bigger then a character, but smaller then an int, etc. (What we really want is something For 99% of the code, you don't care about the size (as long as it is big enough), so why worry about it. Quote: Feasibility: 1) Trivial, mostly already done today, via typedefs, except for native char32 support. 2) Time-Consuming - need to implement ALL the string functionality for 32-bit characters. Ramifications: 1) Due to legacy support, might be impossible in C++. 2) How do you safeily specifically initialize a floating point number of a certain size? How do you exactly initialize a floating point type if you don't even know its base. Two bases are current today, 2 and 16; I have worked on machines using base 10 as well, and it wouldn't surprise me if some still exist. -- James Kanze 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top M Jared Finder Guest Posted: Mon Aug 09, 2004 9:32 am    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Michaelangelo wrote: Quote: A modest (C++ Evolution) Proposal <snip> This has got me to thinking of what, in my opinion is a big problem in the standard library. numeric_limits::min (referred to as just "min") means something different for integral types and for floating point types! This makes min useless in generic code, as you have to reimplement it for the expected types. I would greatly appreciate splitting min up into "least" and "precision", both of which are useful in generic code. -- MJF [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Guest Posted: Mon Aug 09, 2004 9:34 am    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa "James Kanze" <kanze (AT) gabi-soft (DOT) fr> wrote Quote: - D is presented as an alternative to C++. According to its creators, C++ can't be fixed. (That's a radical simplification, of course.) Another way to look at that is that, in my opinion, C++ cannot be fixed without abandoning backwards compatibility. For an example, look at exported templates, which are really an attempt to graft module semantics onto C++ while retaining inclusion semantics. The result takes 2 to 3 man-years to implement, and as far as I can tell, does not deliver on its promises (faster compilation and source hiding). One or two more features like that and the evolution of C++ will ground to a complete halt. Contrast that with D, which abandons the inclusion model and replaces it with true modules. Exported templates simply drop out, and are no extra effort to implement. Quote: |> Aside, is there a document that summarizes the various vendors |> extensions to C++? Most of the "extensions" I know of are concerned with backward compatibility. Most of the implementors can't manage to implement the standard completely, much less add extensions. Digital Mars C++ adds Design by Contract extensions, and a similar proposal for DbC has been presented to the C++ committee. Intriguingly in C++ it simply has not generated any traction, but DbC in D has generated quite a bit of interest and is regularly used. In fact, DMC++ has a number of extensions to C++ that are completely overlooked (such as binary literals, hex floats, and a 'with' statement), but in D they are popular. I don't know why this is true, but it uninspires me to try out more extensions in C++. Heck, people don't even use C99 hex floats, which I think are a necessary feature for writing exacting numerics code. Quote: I'm not sure that "hacks" is the correct word. There are a lot of things in C and in C++ that I don't like. But the languages grew to meet concrete, pragmatic needs, not theoretical ideals. What may seem like a "hack" today was almost always an essential pragmatic compromise when it was adopted. True. Nearly every oddity in C++ can be traced to having to deal with backwards compatibility. Quote: IMHO, this is the greatest problem C++ (and C, for that matter) faces: how to go beyond the pragmatic compromises, not that the reasons which forced them have disappeared. I know that I'm not alone in fealing this, and that some very important C++ experts would like to find a replacement for the preprocessor, D has them - version statements, debug statements, nested functions, template mixins, contracts, etc. Quote: perhaps a better declarations syntax, Pointer to array of 16 pointers to ints: int *(*p)[16]; // C++ (or D) int*[16]* p; // D Declarations read right to left in D. Interestingly, the syntax is distinct enough from C++ that *both* declaration forms can be used. Quote: or a better solution for null pointer constants. D has the 'null' keyword. Quote: Some very competent people are also looking at simplifications like garbage collection, which modern technology makes acceptable, where as when the languages were conceived, it would have required unacceptable runtime costs. D has gc, but still supports RAII and explicit allocation if desired. Quote: |> Anytime a language changes, it has to address the "Backward |> Compatibility" issue. In general there are 2 choices: |> 1) As much as possible |> 2) Clean slate, intentionally breaking things. D obviously goes with (2), but that is why D has a distinct name from C++, as it is not C++ and C++ is not a syntactical subset of it. Quote: |> i.e. Is anyone REALLY doing C++ development on machines that support |> 36-bit words ?? Yes. At least I think so, as such machines are still being sold today. D doesn't support 36 bit machines. Oh well <g>. Quote: |> Proposal: Get rid of this "long long" crap, and adopt a consistent |> naming schema, with the traditional cardinal types first deprecated, |> and then eventually gone. |> i.e. |> // Valid ... |> int8 |> int16 |> int32 |> int64 |> int128 |> // ... and the corresponding unsigned versions... |> uint8 |> uint16 |> uint32 |> // ...etc... There's something similar in C already; I suppose it will be in the next version of C++. Of course, it does make the distinction as to whether I want the minimum efficient size with so many bits, or an exact size. Basic types in D are fixed sizes. Quote: In principle, a quality implementation would use Unicode for wchar_t on any platform where it made sense. Historical reasons interfere, however, and at least two major platformes (AIX, Windows) use 16 bit wchar_t rather than 32 bit Unicode. Again, C has a proposal (I don't think it is part of the C99 standard) for this, which will probably end up as part of C++, in some distant future. D has moved toward supporting UTF throughout. char's are UTF-8, wchar's are UTF-16, and dchar's are UTF-32. This scheme works surprisingly well, the UTF encodings can be mixed and matched, and there's no longer a need for a separate parallel set of 'w' functions that break anyway when porting from Win32 to Linux. Quote: |> What this means is that all us "library" authors no longer have to |> keep re-writing these definitions above in our "Types.h" file. We |> are free'd from having to assume the size of the primitive types, as |> we know their exact sizes, which are guaranteed, instead of the |> quasi-definition of short being bigger then a character, but smaller |> then an int, etc. (What we really want is something For 99% of the code, you don't care about the size (as long as it is big enough), so why worry about it. You're quite right. I've seen my share of code that used layers of typedefs "for portability" that broke anyway when the sizes changed <g>. The worst po rtability problem (aside from templates) is the support for international character sets (which you mentioned), and typedefs won't help much. -Walter www.digitalmars.com/d/ The D Programming Language [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michaelangelo Guest Posted: Mon Aug 09, 2004 9:36 am    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa On 8 Aug 2004 17:52:26 -0400, Francis Glassborow Quote: May I suggest that you first research what is already being worked on? Visit http://www.open-std.org/jtc1/sc22/wg21/docs/papers (it seems to be down at the moment) and see the ideas already being worked on. Thx Francis, that's exactly what I was looking for! I've also been making my way through the groups archives. I'm glad I'm not the only with these crazy extension ideas :) -- Insanity is a virtually impregnable gambit but you have to lay the groundwork early in the game - Lord Julius [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Mon Aug 09, 2004 9:40 am    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa James Kanze <kanze (AT) gabi-soft (DOT) fr> writes: [...] Quote: Some very competent people are also looking at simplifications like garbage collection, which modern technology makes acceptable, where as when the languages were conceived, it would have required unacceptable runtime costs. Yes, but 6 years ago, was it the case that making garbage collection explicitly _optional_ would have required unacceptable runtime costs? If yes, how so? No, I'm not living in the past. [...] Quote: IMHO, not a problem. Supposing that all of the functions in complex are inline (which they should be), it would be a very poor compiler which didn't lay something like: complex< double > const i( 0.0, 1.0 ) ; directly in memory. Unless, of course, the platform was such that it really didn't make a difference and the analysis necessary to find the optimization was more expensive than possible gain (the case for any modern Windows or Unix based compiler, for example). Huh? I don't understand. Could you clarify? -- Gaby [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Mon Aug 09, 2004 8:28 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Gabriel Dos Reis wrote: Quote: Yes, but 6 years ago, was it the case that making garbage collection explicitly _optional_ would have required unacceptable runtime costs? Ada made GC optional and to date no Ada compiler (excpet for one targeted at a JVM) has implemented it. Anyway, to have tried making it part of the standard would undoubtedly led to the same kind of catfights you see going on here now. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gabriel Dos Reis Guest Posted: Mon Aug 09, 2004 9:10 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Hyman Rosen <hyrosen (AT) mail (DOT) com> writes: Quote: Gabriel Dos Reis wrote: Yes, but 6 years ago, was it the case that making garbage collection explicitly _optional_ would have required unacceptable runtime costs? Ada made GC optional and to date no Ada compiler (excpet for one targeted at a JVM) has implemented it. My question was about the "unacceptable runtime costs". No whether a compiler would have implemented it. -- Gabriel Dos Reis [email]gdr (AT) integrable-solutions (DOT) net[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Mon Aug 09, 2004 11:50 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa [email]walter (AT) digitalmars (DOT) nospamm.com[/email] (Walter) wrote (abridged): Quote: Another way to look at that is that, in my opinion, C++ cannot be fixed without abandoning backwards compatibility. If we're going to do that, I'd probably go for something like Dylan, which it seems to me has many of the same objectives as C++ - including extreme low-level efficiency - without the backwards compatibility. I'd hesitate to design yet another language. I gather there are over a dozen of them called "D". Quote: D has moved toward supporting UTF throughout. char's are UTF-8, wchar's are UTF-16, and dchar's are UTF-32. This scheme works surprisingly well, the UTF encodings can be mixed and matched, and there's no longer a need for a separate parallel set of 'w' functions that break anyway when porting from Win32 to Linux. Surely those aren't needed in C++ anyway? They are there because Windows supports languages without static overloading, like C and Pascal. -- Dave Harris, Nottingham, UK [ 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 Aug 10, 2004 6:50 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Gabriel Dos Reis <gdr (AT) integrable-solutions (DOT) net> wrote Quote: James Kanze <kanze (AT) gabi-soft (DOT) fr> writes: [...] | Some very competent people are also looking at simplifications like | garbage collection, which modern technology makes acceptable, where | as when the languages were conceived, it would have required | unacceptable runtime costs. Yes, but 6 years ago, was it the case that making garbage collection explicitly _optional_ would have required unacceptable runtime costs? 6 years ago, I don't think so. But 10 years ago, I think that the perceived costs were too high. There existed some implementations of garbage collection which had acceptable cost, but their existance wasn't well known. And 10 years ago would still have been very late to try and get something that big and that important into the standard. Today of course, anyone rejecting garbage collection for performance reasons has to have their head in the sand. There are, of course, a lot of other problems involved with adding it to a language which didn't previously support it, and not all of the opponents to garbage collection are idiots. But performance is provably not a problem. And IMHO, the other problems are all sovable, and worth solving. (But that's just my opinion. Even if I know a couple of other people who share it:-).) Quote: If yes, how so? No, I'm not living in the past. [...] | IMHO, not a problem. Supposing that all of the functions in complex | are inline (which they should be), it would be a very poor compiler | which didn't lay something like: | complex< double > const i( 0.0, 1.0 ) ; | directly in memory. | Unless, of course, the platform was such that it really didn't make | a difference and the analysis necessary to find the optimization was | more expensive than possible gain (the case for any modern Windows | or Unix based compiler, for example). Huh? I don't understand. Could you clarify? OK. Basically, complex will have a constructor something like: complex::complex( double real, double imag ) : r( real ) , i( imag ) { } and no constructor, right. (I'm ignoring the templates in order to reduce the amount I have to write. I don't think they change anything.) Given this, if at namespace scope, I write: complex const i( 0.0, 1.0 ) ; - any reasonably good compiler should be able to determine the exact contents of the memory after initialization, and - since the object is const, any attempt to modify it after initialization is undefined behavior. Given this, it wouldn't be too difficult for the compiler to simply generate the initialized memory as part of the text segment (under Unix), or to put it into something which will be directly burned into a PROM (for an embedded system) -- in both cases, of course, the compiler would also suppress the dynamic initialization. So why don't we see this optimization more often? Well, on Unix systems, I suspect it is simply because the cost of doing the dynamic initialization is typically less than the cost of having the compiler look for the optimization. The dynamic initialization of variables at namespace scope isn't ever going to be in a tight loop in a critical path of the execution. I could imagine, however, that such optimizations might be useful in an embedded system. Not so much because of the runtime, but because of the space saved by eliminating the initialization code; on at least one system I worked on (long, long ago), the fact that the variable could be put into PROM instead of RAM would be important as well. (There were only 64 bytes of RAM, whereas we had a full 2 K of PROM. And no, there wasn't a native C++ compiler for the machine:-).) -- James Kanze GABI Software http://www.gabi-soft.fr 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thorsten Ottosen Guest Posted: Tue Aug 10, 2004 6:54 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa Quote: This has got me to thinking of what, in my opinion is a big problem in the standard library. numeric_limits::min (referred to as just "min") means something different for integral types and for floating point types! This makes min useless in generic code, as you have to reimplement it for the expected types. I would greatly appreciate splitting min up into "least" and "precision", both of which are useful in generic code. maybe you should take a look at the numeric conversion library in the next version of boost. you can already find it in the cvs. br Thorsten [ 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 Aug 10, 2004 6:55 pm    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa "Walter" <walter (AT) digitalmars (DOT) nospamm.com> wrote Quote: "James Kanze" <kanze (AT) gabi-soft (DOT) fr> wrote in message news:m2u0vdcn6v.fsf (AT) lns-vlq-33-82-253-242-101 (DOT) adsl.proxad.net... - D is presented as an alternative to C++. According to its creators, C++ can't be fixed. (That's a radical simplification, of course.) Another way to look at that is that, in my opinion, C++ cannot be fixed without abandoning backwards compatibility. C++ cannot be "fixed" without ceasing to be C++. Note that the backwards compatibility is one of the reasons behind C++'s success. Quote: For an example, look at exported templates, which are really an attempt to graft module semantics onto C++ while retaining inclusion semantics. I think that's a large simplification. The process is a lot more complex than that. [...] Quote: perhaps a better declarations syntax, Pointer to array of 16 pointers to ints: int *(*p)[16]; // C++ (or D) int*[16]* p; // D What's wrong with something like: variable p: pointer to array[16] of pointer to int ; Or more succinctly: var p: *[16]*int ; For that matter, many of the problems would disappear if I could just write: var int *(*p)[ 16 ] ; The real problems aren't with built-in types. The real problems occur because of the ambiguities between a declaration and certain types of expressions. Requiring declarations to start with a keyword, var or fnc, for example, would go a long way in resolving that. I'm not saying that the rest of the syntax is all that beautiful. Only that it gets the job done. Most types aren't that complicated, and there are always typedef's to help out when they are. Sure, a Pascal like syntax would be better (IMHO, at least), but it wouldn't be C++. As for just letting the [] come before the variable name, as in Java... It just doesn't seem worth the effort. You still haven't really started to address the problem. Quote: Declarations read right to left in D. Interestingly, the syntax is distinct enough from C++ that *both* declaration forms can be used. or a better solution for null pointer constants. D has the 'null' keyword. From what I hear, C++ will have it sooner or later as well. Some very competent people are also looking at simplifications like garbage collection, which modern technology makes acceptable, where as when the languages were conceived, it would have required unacceptable runtime costs. D has gc, but still supports RAII and explicit allocation if desired. Which is something that could be added to C++ as well. Quote: |> Anytime a language changes, it has to address the "Backward |> Compatibility" issue. In general there are 2 choices: |> 1) As much as possible |> 2) Clean slate, intentionally breaking things. D obviously goes with (2), but that is why D has a distinct name from C++, as it is not C++ and C++ is not a syntactical subset of it. Which raises the question: why so close? I don't know D, but I was very disappointed in Java because, freed of the constraints of C compatibility, there are a lot more things that should have been changed. Quote: |> i.e. Is anyone REALLY doing C++ development on machines that |> support 36-bit words ?? Yes. At least I think so, as such machines are still being sold today. D doesn't support 36 bit machines. Oh well <g>. Well, it's a pretty small market today:-). Still, who knows what the future will bring. Quote: |> Proposal: Get rid of this "long long" crap, and adopt a consistent |> naming schema, with the traditional cardinal types first deprecated, |> and then eventually gone. |> i.e. |> // Valid ... |> int8 |> int16 |> int32 |> int64 |> int128 |> // ... and the corresponding unsigned versions... |> uint8 |> uint16 |> uint32 |> // ...etc... There's something similar in C already; I suppose it will be in the next version of C++. Of course, it does make the distinction as to whether I want the minimum efficient size with so many bits, or an exact size. Basic types in D are fixed sizes. Why? Quote: In principle, a quality implementation would use Unicode for wchar_t on any platform where it made sense. Historical reasons interfere, however, and at least two major platformes (AIX, Windows) use 16 bit wchar_t rather than 32 bit Unicode. Again, C has a proposal (I don't think it is part of the C99 standard) for this, which will probably end up as part of C++, in some distant future. D has moved toward supporting UTF throughout. char's are UTF-8, wchar's are UTF-16, and dchar's are UTF-32. This scheme works surprisingly well, the UTF encodings can be mixed and matched, and there's no longer a need for a separate parallel set of 'w' functions that break anyway when porting from Win32 to Linux. Curious choices. The obvious choice is UTF-32 internally, and UTF-8 externally, with conversion at the interface. Just as obviously, however, you need support for all of the existing codesets, which you are going to encounter in files, etc. Quote: |> What this means is that all us "library" authors no longer have |> to keep re-writing these definitions above in our "Types.h" |> file. We are free'd from having to assume the size of the |> primitive types, as we know their exact sizes, which are |> guaranteed, instead of the quasi-definition of short being |> bigger then a character, but smaller then an int, etc. (What we |> really want is something For 99% of the code, you don't care about the size (as long as it is big enough), so why worry about it. You're quite right. I've seen my share of code that used layers of typedefs "for portability" that broke anyway when the sizes changed g>. Whereas I've seen an awful lot of code written without any typedef's, just int and long, which has ported to all sorts of different machines (including, sometimes, machines with 36 or 48 bit ints). Quote: The worst portability problem (aside from templates) is the support for international character sets (which you mentioned), and typedefs won't help much. Actually, support for international character sets is NOT a portability problem in C++. It's pretty much the same with all compilers I've seen. Non-existant. So you write your own, in portable C++, and it works everywhere. The largest portability problems in C++ come where the standard broke existing practice. The result is that compilers all have different ways of handling backwards compatibility. Including ignoring the standard, so you have the problem even when writing new code. -- James Kanze GABI Software http://www.gabi-soft.fr 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Walter Guest Posted: Wed Aug 11, 2004 9:28 am    Post subject: Re: Evolution of C++ : Thinking ahead of what's to come - Pa "Dave Harris" <brangdon (AT) cix (DOT) co.uk> wrote Quote: walter (AT) digitalmars (DOT) nospamm.com (Walter) wrote (abridged): Another way to look at that is that, in my opinion, C++ cannot be fixed without abandoning backwards compatibility. If we're going to do that, I'd probably go for something like Dylan, which it seems to me has many of the same objectives as C++ - including extreme low-level efficiency - without the backwards compatibility. Dylan is an interesting language that appeals to a lot of people, but it does not retain the look and feel of C++. D does retain the look and feel of C++. Quote: I'd hesitate to design yet another language. I gather there are over a dozen of them called "D". People keep saying there are all these D languages, but I couldn't find any when D was created that were an existing, supported implementation. If you know of any, please let me know. Quote: D has moved toward supporting UTF throughout. char's are UTF-8, wchar's are UTF-16, and dchar's are UTF-32. This scheme works surprisingly well, the UTF encodings can be mixed and matched, and there's no longer a need for a separate parallel set of 'w' functions that break anyway when porting from Win32 to Linux. Surely those aren't needed in C++ anyway? They are there because Windows supports languages without static overloading, like C and Pascal. If std::string supports UTF, I have missed it. But for a more serious answer to your question, having string templates that overload based on 'char' or 'wchar_t' (which is analogous to having a parallel set of 'w' functions) is nowhere near sufficient for supporting international character sets. I've attempted to write internationalized C++ apps that are portable between win32 and linux, and quickly ran into those inadequacies. C++ leaves far too much as "implementation defined", which translates to "write your own UTF library". Some examples: 1) There are 3 forms of UTF encodings, but C++ has only char and wchar_t. Even worse, wchar_t is "implementation defined", which translates to one cannot write portable UTF code. 2) You cannot write both char's and wchar_t's to stdout. One consequence of this is you must decide to use char or wchar_t throughout your entire app, not just in the international part. 3) The mapping of source characters to the basic character set is implementation defined, which means that you cannot portably have UTF characters in string literals. To do it portably you'd have to write in the u or U notation. That's about as enticing as writing all your string literals in hex notation. Of course, you could also write a preprocessor to convert the UTF characters in the source to U and then feed that output to the compiler. But I wouldn't call that being supported by C++. 4) File opens are char* (calling std::fopen()). Whether that is UTF-8 or not is implementation defined, which means it's not portable. -Walter www.digitalmars.com free C/C++/D compilers [ 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, 3 ... 17, 18, 19  Next Page 1 of 19   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.