Stepanov has said that if he were starting over, STL components would have no public named member functions at all. Before template function overloading that wasn’t possible, but then they were added after it was too late to take out the member functions.

Any l anguage can be misused. I think many would argue that gcc’s vec.h is a misuse of C. It would be much simpler–indeed, nonexistent–in C++. The interesting question is whether using C++, including the STL, makes it easier to write correct and/or faster code.

Considering from what I heard, the C++ standards committee has mentioned that implicit cast are bad and should never have gone in. I would have expected that they would be against implicit this also.

– Pinski

For the code I see here at Sony, they abuse templates to try to get around pointer aliasing issues and a couple other weird stuff. The wrap vector types inside a class even though we define addition and a couple other stuff like subscripting (which I am testing a patch to submit to right now). I can’t tell if they are doing this wrapping for portability or just for the fun of it.

– Pinski

davem: I agree that get rid of GC is a completely separate project. And you’re right: I find the template bloat in gold to be basically irrelevant. If it made gold slower, then it would be highly relevant. But in fact, it doesn’t. I didn’t introduce it because I like templates, I introduced it because it makes gold faster. In any case I don’t see any reason to use that sort of technique in gcc.

tromey: Sure, the developers should decide. I’m casting my vote.

atgreen: This is perhaps overly cynical, but the best way to speed up C++ compilation times would be to make them matter for gcc programmers.

Also, while I’m in favor of using C++, I am not sure that it will help with the bigger problems in GCC. Maybe we can more easily librarify a few bits by making use of an implicit “this”. But, there are plenty of other ugly things that still require lots of slogging. It may help a bit with de-GC-ification, but even that isn’t totally clear to me.

Sure, you could convert the gcc tree, and transition because the current
codebase is using the C subset of C++.

But any real use of C++ features, especially your target class idea, would
take a lot of work. You’d either have to keep a “C” non-classed target interface
around, add some kind of wrapper target class for “C” targets, or have a field
day and convert everything in one go.

I mean, by all means, if you’re motivated, go for it.

But, actually C++ is one of the things I’ve grown to dislike about gold,
especially after working with it a lot (writing a new target, fixing bugs)
and looking at the generated assembler and bloat.

I’m sorry to say this. The bloat from templates just to support both 32-bit
and 64-bit sparc is just rediculious. And this seems to be endemic of
templated code. The argument seems to be that the templates instantiations
you aren’t using aren’t even executed or brought into memory, but as a long
time C systems level programmer I find these kinds of waste unsettling. And
the fact that C++ programmers consider it an acceptable tradoff… even more
unsettling.

Really, ridding GCC of GC is a so much more worthwhile and doable
goal than a C++ conversion. Although, I suppose C++ is part of one of
your imagined plans to rid GCC of GC. If so, good luck

And it should be noted that my CIS department teaches C, Java, Python and OCaml, but not C++. C is useful and will be for the forseeable future, but what C++ brings to the table isn’t all that fantastic without an existing C codebase. So fewer schools are teaching C++, but C itself remains important as a systems language.

This said, gcc is a unique project with a large C codebase and hopefully intelligent authors. If there are tangible benefits to the work you’d have to do in transition, you may as well try it.