C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  *OBJECTIVE* reason to not use MI? Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Bret Pehrson Guest Posted: Mon Feb 02, 2004 8:35 am    Post subject: *OBJECTIVE* reason to not use MI? (I've been living in a cave for the last 3 years, so I'm not all that up w/ current events. I've searched Google and Google Groups for answers, but didn't find anything definitive on this topic that didn't degrade into a senseless war.) What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) I'm not interested in SUBJECTIVE reasons. (I consider subjective reasons: bad design, because there is a better way, because it can be done without MI, because my boss doesn't like it, because it is confusing, slower, etc.) I thank you for your objective and rational comments. PS: Objective reasons to USE multiple inheritance would also be welcomed. -- Bret Pehrson mailto:bret (AT) infowest (DOT) com NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Mon Feb 02, 2004 3:56 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? Hi, Quote: What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. So long, Thomas [ 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 Feb 02, 2004 4:06 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? In message <401DE680.6AC7C008 (AT) infowest (DOT) com>, Bret Pehrson <bret (AT) infowest (DOT) com> writes Quote: PS: Objective reasons to USE multiple inheritance would also be welcomed. I think you will find several pertinent examples in TCPPL 3ed. { TCPPL stands for "The C++ Programming Language (third edition)" by Bjarne Stroustrup. -mod/vdv } -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bret Pehrson Guest Posted: Mon Feb 02, 2004 7:45 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? I consider performance-related issues to be subjective (what is fast for me may be slow for you), but I appreciate your comment. Any other reasons that you are aware of? Thomas Richter wrote: Quote: Hi, What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. So long, Thomas -- Bret Pehrson mailto:bret (AT) infowest (DOT) com NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ed Avis Guest Posted: Tue Feb 03, 2004 11:03 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Bret Pehrson <bret (AT) infowest (DOT) com> writes: Quote: I consider performance-related issues to be subjective (what is fast for me may be slow for you), but I appreciate your comment. What exactly would you consider an 'objective' reason? Beyond correctness, clarity, and performance, there isn't much to compare one programming style to another. (Although when writing code you may settle for a worse style because it is quicker or easier for you to write.) -- Ed Avis <ed (AT) membled (DOT) com> [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bert Klaps Guest Posted: Tue Feb 03, 2004 11:06 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote Quote: Hi, What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. On the other hand: in C++ that `diamond-of-death' is the exception rather than the rule. At least I've only come across it once in a real project (and yes, MI was unnecessarily abundant). You can perfectly use MI without ever encountering a diamand shaped class diagram and even when you do, it's not necessarily a problem. If it is, virtual inheritance provides a way out, of course at some cost. Also see http://www.gotw.ca/gotw/037.htm for reasons when MI can be usefull. Regards, Bert Klaps [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top llewelly Guest Posted: Tue Feb 03, 2004 11:14 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Bret Pehrson <bret (AT) infowest (DOT) com> writes: Quote: (I've been living in a cave for the last 3 years, so I'm not all that up w/ current events. I've searched Google and Google Groups for answers, but didn't find anything definitive on this topic that didn't degrade into a senseless war.) What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. I suggest you read: (a) Stroustrup, _The C++ Programing Language_ 3rd or SE, section 15.2, _Multiple Inheritance_ . (b) The Meyers _(More) Effective C++_ items on multiple inheritance. (c) Sutter _(More) Exceptional C++_ items on multiple inheritance. (If you don't have the exceptional C++ books, you can get the gist from www.gotw.ca/gotw/03{7,8,9}.htm .) (d) Cline's _C++ FAQ_. (The lite version is on the web: http://www.parashift.com/c++-faq-lite/multiple-inheritance.html ) (e) Coplien's _Advanced C++, Programming Styles and Idioms_, section 5.7 is useful, though dated; cross-check it against (f) below. (f) After you feel you understand the above, chapters 10 and 12 of the C++ standard are helpful, particularly: 10.1/6, 10.2/3, 10.2/5, 10.3/2, 10.3/9-12, 12.4/6, 12.6.2, 12.8/13 None of the above describe reasons not to use multiple inheritance - they describe problems you may encounter, and how to avoid or solve those problems. Quote: (I consider something like the 'dreaded diamond' an objective reason.) Here a few rules for dealing with diamonds: (a) Derived classes should be non-assignable. (b) Know whether you need a real diamond, or a tree; diagram your inheritance hierarchies. All examples of virtual inheritance from a particular base class represent the same subobject. Each example of non-virtual inheritance from a particular base class represents a unique subobject of the base class type. The 'Java rule' also prevents problems with diamonds, but it sterilizes the idiom of making virtual funcions protected, and wrapping them with public inline functions. Problems with the 'dreaded diamond' are primarily a hobgoblin of newsgroups; outside of that habitat they are endangered. Quote: I'm not interested in SUBJECTIVE reasons. (I consider subjective reasons: bad design, because there is a better way, because it can be done without MI, because my boss doesn't like it, because it is confusing, slower, etc.) Slower? Get a high-precision timer, a profiler, and measure. Multiple inheritance does have both time and space overhead, though the precise tradeoffs are quite implementation-dependent. But IMO, there are usually more profitable places to concentrate one's optimizing energies, like replacing poorly chosen algorithms and data structures, reducing uses of dynamic allocation, avoid std::string, etc. Adress those kinds of issues first, and only turn to MI-related issues later. MI can impact upcasts, downcasts, typeid, object size, and virtual function call overhead, though not necessarily all in the same implementation. Quote: I thank you for your objective and rational comments. Objectivity is too much trouble, so I apologize for not being objective. ;-) Quote: PS: Objective reasons to USE multiple inheritance would also be welcomed. If a type models an entity (such as airplane), public base classes (usually) represent categories (such as physical_object) or attributes (has_ai). Real-world entities fall into multiple categories, and have multiple attributes. If your program must model multiple categories, multiple inheritance is an appropriate tool. For example, suppose you need to model that an airplane that: (a) obeys physical laws, (b) has an ai pilot, and (c) has a polygon model that can be drawn on the screen. The following code does not compile, but it should give you a vague idea: struct physical_object { physical_object(); virtual inertial_reference frame()const; virtual box collison_bounds()const; virtual double mass()const; virtual ~physical_object(){} private: physical_object(physical_object const&); physical_object& operator= (physical_object const&); //... }; struct has_ai { virtual ai::ai& ai()= 0; virtual ai::ai const& ai()const= 0; virtual ~has_ai(){} private: has_ai(has_ai const&); has_ai& operator=(has_ai const&); }; struct has_model { virtual draw::model const& model()const= 0; virtual ~has_model(){} private: has_model(has_model const&); has_model& operator=(has_model const&); }; struct airplane : virtual physical_object ,virtual has_ai ,virtual has_model { virtual ai::ai& ai(); virtual ai::ai const& ai()const; virtual draw::model const& model()const; virtual ~airplane(){} }; Notes: In real code, I don't make virtual functions public; I make them protected, and call them via public inline non-virtual wrappers that provide a place for contract checking, debug/trace messages, timing, etc. Here they are public and virtual because I view that issue as seperate from multiple inheritance. In the real code, all the members of physical_object except the desturctor are non-virtual and inline; I changed it inorder to avoid arguments about whether or not a function should be virtual (which is also independent of multiple inheritance issues.) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Keith H Duggar Guest Posted: Tue Feb 03, 2004 11:34 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Quote: What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) The "dreaded diamond" is not caused by multiple inheritance. It is caused by multiple virtual inheritance. Quote: I'm not interested in SUBJECTIVE reasons. (I consider subjective reasons: bad design, because there is a better way, because it can be done without MI, because my boss doesn't like it, because it is confusing, slower, etc.) Those are nice examples; in reality humans can offer only one kind of reasoning: subjective. Quote: PS: Objective reasons to USE multiple inheritance would also be welcomed. The book "Scientific and Engineering C++ : An Introduction with Advanced Techniques and Examples" by Barton and Nackman contains extensive examples of using multiple examples to great effect. They also demonstrate that the "dreaded diamond" is not dreaded at all if you virtually inherit only interfaces and not implementations. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bjarne Stroustrup Guest Posted: Tue Feb 03, 2004 11:40 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote Quote: Hi, What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. So long, Thomas For performance issues, see the ISO C++ Standard committee's technical report on performance (link on my C++ page). Guessing about performance penalties can sometimes get unpleasently close to FUD. Please note that (1) the overhead for MI compared to SI is small (in many cases non-existent) and (2) workarounds also cost something (roughly as little as MI if done well). - Bjarne Stroustrup; http://www.research.att.com/~bs [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Vladimir Kouznetsov Guest Posted: Tue Feb 03, 2004 11:43 am    Post subject: Re: *OBJECTIVE* reason to not use MI? Hi, I wonder if you have an equivalent example without MI that doesn't suffer from the same overhead? Also, please note that MI doesn't necessarily require virtual inheritance. thanks, v "Thomas Richter" <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote Quote: Hi, What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ivan Vecerina Guest Posted: Tue Feb 03, 2004 2:23 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? "Bret Pehrson" <bret (AT) infowest (DOT) com> wrote Quote: What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) I do not thing there are objective reasons *never* to use MI. However, multiple inheritance does have drawbacks. First of all, encapsulation is weakened inheritance, a fortiori by multiple inheritance. Access to more data and function members means more error opportunities, complex overloaded name access rules, increased dependencies, as well as maintenance problems. Virtual member functions, in C++, are particularly error-prone, because they cannot be hidden by private inheritance. A function defined in a subclass may accidentally override a virtual function implemented in any of its base classes. And things get really messy when two classes in a hierarchy want to independently implement the same abstract base class or callback interface. Quote: I'm not interested in SUBJECTIVE reasons. (I consider subjective reasons: bad design, because there is a better way, because it can be done without MI, because my boss doesn't like it, because it is confusing, slower, etc.) I thank you for your objective and rational comments. PS: Objective reasons to USE multiple inheritance would also be welcomed. First of all, multiple inheritance has many uses in C++ outside of the scope of polymorphic behavior. But even in classic OOD, there are real uses for MI - some designs just ask for it. A particular form of multiple inheritance has become quite popular in recent years: *interface* inheritance, where base classes only contain pure virtual functions. The complexity of MI is mitigated through the absence of data members and base class functions. However, function name collisions have remained an issue. This has been especially apparent in platforms and languages such as Microsoft COM and Java, which have pushed the Interface Inheritance concept to extremes. Java introduced solved the issue with 'inner classes': adapter objects that dispatch virtual calls without requiring multiple inheritance. An even more de-coupled alternative is to replace interfaces with a callback or event mechanism, as found in Qt's MOC (Slots & Signals), or in Delphi and .NET (Events & Delegates). In C++, these alternatives to Multiple Inheritance can also be taken advantage of: - a simple call forwarder can easily be implemented using the boost::function template library (recommended) See: http://www.boost.org/doc/html/function.html - an 'adapter' member can implement an interface and forward calls to the contained class, much like Java's Inner Classes do: http://groups.google.com/groups?selm=3cc79b65%40news.swissonline.ch http://groups.google.com/groups?selm=9kvt93%246uh92%241%40ID-86670.news.dfncis.de http://groups.google.com/groups?selm=966698440.46753%40unet.urbanet.ch I have used variants of this approach in various projects, but do not know of a general C++ event/delegate framework that safely manages the lifetime of a connection. Multiple inheritance has caveats. But simple inheritance itself has problems: when possible, containment should be preferred as it better preserves encapsulation. All in all, multiple inheritance is just another powerful tool: it can easily be abused or misused. But sometimes there just isn't any good replacement for it... template <class E, class T = char_traits class basic_iostream : public basic_istream<E, T> , public basic_ostream<E, T>; Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form Brainbench MVP for C++ <> http://www.brainbench.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Balog Pal Guest Posted: Tue Feb 03, 2004 2:25 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? "Bret Pehrson" <bret (AT) infowest (DOT) com> wrote Quote: What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) [in _practical_ terms] As long as you have only SE all object pointers can be reinterpret_cast to each other, without problem. With ME in picture that's no longer true. Some pointers will need adjustments. There are some environments and programs where you are practically forced such casts. When you pass infromation through some system that knows only bytes, DWORDs, LPARAMs. Say, Windows has a zillion of such situations, 'itemdata' for listview raws, listboxes, and most other USER elements, the MSG structure itself, a plenty of callbacks... In such environment you better think twice before allowing MI, or if you do, you must look very carefully to do all the cast to the conservative rules, casting back only to the _exact_ type the pointer was originally. Not its base. Or not directly to the actual type, when really a base pointer was passed. (certainly the same applies when all you use is T1* --implicit-> void* --static_cast->T2*. With SI only you're okey as long as both T1* and T2* is type-correct to access the actual object. with MI only --static_cast->T1* --static_cast->T2* is safe.) Quote: PS: Objective reasons to USE multiple inheritance would also be welcomed. MI is pretty handy when you inherit from distinct hierarchies. One parent is from the API framework chain, the other does the real, app-specific stuff. Possibly they're tied by a template creating the final thing. Paul [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Rob Guest Posted: Tue Feb 03, 2004 2:36 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? "Bret Pehrson" <bret (AT) infowest (DOT) com> wrote Quote: [Snip] What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) I'm not interested in SUBJECTIVE reasons. (I consider subjective reasons: bad design, because there is a better way, because it can be done without MI, because my boss doesn't like it, because it is confusing, slower, etc.) Firstly, I wouldn't necessarily describe "it is confusing" as a subjective reason. If a particular design or implementation technique confuses 80% of people who review the code, that is an objective reason. I also wouldn't describe the "dreaded diamond" as an argument against MI; the design should identify circumstances where tha occurs, and specify what approach is needed (eg virtual inheritence vs. non-virtual inheritence). Quote: PS: Objective reasons to USE multiple inheritance would also be welcomed. OK; arguments for and against MI. 1) Implementing MI is typically more of a challenge for compiler writers than other language features. That means more of a chance of buggy implementations, meaning the code won't always port cleanly between compilers. This is more relevant when using older compilers; it is certainly a rare issue with good quality modern compilers. 2) MI (and in fact any inheritence) can be avoided altogether by a mix of aggregation and forwarding techniques (a member function of a class calls the member function of a contained object). That is effectively what several compilers do behind the scenes anyway. For the humble programmer, using inheritence (or MI) tends to be less complicated than the equivalent based on aggregation and a compiler will tend to have more opportunities for optimisation (increasing speed, reducing executable file size, etc). 3) Multiple inheritence is a language feature, subject to abuse and misuse like any other. If the misuse scenarios are severe enough, you will not wish to use MI. 4) Some designs are more easily implemented using MI (if your language supports it). For example, MI of implementation allows use of "mixin" classes. This is not possible with MI of interface (as per the Java approach) and obviously not possible with languages that don't support inheritence. If a language feature allows something to be implemented more easily and maintainably, that usually translates into development or maintenance cost savings (i.e. hard cold cash). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Tue Feb 03, 2004 6:47 pm    Post subject: Re: *OBJECTIVE* reason to not use MI? Hi, Quote: I wonder if you have an equivalent example without MI that doesn't suffer from the same overhead? Also, please note that MI doesn't necessarily require virtual inheritance. Sure, but everything has its price. Instead of class A {...}; class B : public virtual A {...}; class C : public virtual A {...}; // and several more... class D : public B, public C {...}; you can possibly get away with the following: class A {...}; class B : public A {...}; template<class Base> public C : public Base {...}; class D : public C<B> {...}; Now, no "adapter functions", but instead code-bloat for every B-type since the C-code gets duplicated. Besides, it makes the "diamond" rather unsymmetric and might be unpleasent for this reason, but it avoids *one* overhead at the cost of another (but non-run-time). So long, Thomas [ 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: Wed Feb 04, 2004 10:39 am    Post subject: Re: *OBJECTIVE* reason to not use MI? [email]bs (AT) research (DOT) att.com[/email] (Bjarne Stroustrup) wrote in message news:<188b3370.0402021609.53e38dc0 (AT) posting (DOT) google.com>... Quote: Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote in message news:<bvl5p4$f5i$3 (AT) mamenchi (DOT) zrz.TU-Berlin.DE>... What I'm looking for are OBJECTIVE reasons to not use multiple inheritance. (I consider something like the 'dreaded diamond' an objective reason.) Well, I just met one yesterday: It causes a certain amount of overhead in the code that might be undesirable. Typically, methods of a virtually derived class requires a tiny "adapter function" that re-aligns the "this" pointer to point to the proper object, and references to members of the base class typically require another level of indirection within these methods. For certain speed-critical applications this might be undesirable. For performance issues, see the ISO C++ Standard committee's technical report on performance (link on my C++ page). Guessing about performance penalties can sometimes get unpleasently close to FUD. I've not read the committee's technical report, but I'm tempted to say that anything other than concrete measures with your actual application (and compiler, and system) is just guessing. And that if the concrete measures do show a problem, trying a different compiler might be a solution -- I remember some very real problems in terms of object size, many years back, which were solved by simply upgrading compilers -- from an older CFront based version to HP's more recent aCC. Seem's CFront had a bug in its generation -- didn't affect correction, or runtime (except for caching issues), but blew up the size of the objects something horrible. Quote: Please note that (1) the overhead for MI compared to SI is small (in many cases non-existent) and (2) workarounds also cost something (roughly as little as MI if done well). IF performance is critical (and I agree that you shouldn't believe it until you've seen the measures), it is sometimes advantageous to make the cost explicit. I remember in the early days of virtual memory, applications which were rewritten to take advantage of virtual memory, instead of explicitly loaded overlays, often ran several orders of magnitude slower. The virtual memory itself was actually faster than loading an overlay, but when you had to load it explicitly, you thought about locality a lot, lot more. Still, given modern compilers, I'm very dubious that MI would fall into this category. -- 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 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.