This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Using C++ in GCC is OK


On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
> Basile Starynkevitch wrote:
> 
> > 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?
> 
> There's no reason to get into these kinds of questions at this point.
> The goal is not to reimplement GCC from the ground up using modern
> OO/C++ techniques.  The goal is simply to permit ourselves to use C++
> features where appropriate in the codebase.


Except that perhaps these questions are important for any gengtype
enhancement. In particular, one could consider that marking a GTY-ed
data would be done by a virtual method (generated by gengtype), and then
having every GTY-ed data inheriting from an abstract class providing
this method will make both gengtype & ggc*.c simpler.

The same can be said about PCH serialization, or debug dumping.

In addition, if we want to parse C++ class declaration from gengtype,
that could be much more difficult than parsing struct (as gengtype is
doing today). This is why I thought perhaps of some simpler syntax for
the description of all our GTY-ed data, which would generate
appropriately the C++ header files describing them.

But nothing is possible without a rather broad consensus. Nobody will
start a branch on these ideas without having some probability that such
changes will be accepted. 

 
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} ***



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]