On Sun, 2010-05-30 at 17:26 -0700, Mark Mitchell wrote: > I am pleased to report that the GCC Steering Committee and the FSF have > approved the use of C++ in GCC itself. [...] > > For example, I think it goes without question that at this point we are > limiting ourselves to C++98 (plus "long long" so that we have a 64-bit > integer type); C++0x features should not be used. Using multiple > inheritance, templates (other than when using the C++ standard library, > e.g. std::list<X>), or exceptions also seems overly aggressive to me. > We should use features that are relatively easy for C programmers to > understand and relatively hard for new C++ programmers to misuse. (For > example, I think constructors and destructors are pretty easy and hard > to misuse.)
Either I wrongly understand this last sentence, or I rather strongly disagree with it, at least within our current practice inside GCC. I would believe on the contrary that constructors & destructors can too easily be misused, in particular for GGC garbage collected data that GCC need to have. See also http://gcc.gnu.org/wiki/gengtype In general, and independently of GGC, constructor should only *initialize* the object, and should avoid doing any processing on it. So ideally, a constructor should only initialize the own field of the class (after having implicitly called the parent constructor), and not do much else. I believe it can be tempting for newcomers to add a lot more processing inside constructors, and this IMHO should be avoided. Symetrically, destructors should clear objects; however, we should be very careful about destructors of GTY-ed data. At last, there is a very important issue when switching to C++. What is our "ideal" class hierarchy? Do we aim at a large forest, or on the contrary at a single tree of classes, so we have a single root class, providing common services (dump or debug printing, serialization, ...) or not? What is the relation between our C++ classes & gengtype or GGC (I am strongly convinced that even with C++ we need a garbage collection to tame the complexity of GCC and of our circularities in data). Actually, I would believe that many of our C++ class declarations should be generated by a gengtype like tool, which would add support for garbage collection & for some meta-data on the classes. Generating the class declarations [perhaps even from an input which has a simpler syntax -e.g. an S-expr syntax- than what gengtype parses today] is far more easier than extending gengtype to parse all the class syntax permitted in C++. That could be difficult. There is also the case of RTTI & dynamic_cast? Do we allow them or not? What about data structures with a last field which is an array (e.g. in gimple.h the gimple_statement_with_ops). Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
