
GCC starts move towards implementation in C++ - Anon84
http://article.gmane.org/gmane.comp.gcc.devel/114407
======
stingraycharles
I find this statement particularly interesting:

 _For example, I think constructors and destructors are pretty easy and hard
to misuse._

Now, I am aware that the competence of the average GCC committer probably
exceeds that of the average programmer, but still, constructors and
destructors are easy to misuse: throwing an exception in the constructor comes
to mind, in which case the destructor isn't called. Anything about C++ can be
probably misused in the hands of the inexperienced.

Other than that, I think this is a good move, and it'll be interesting to see
how this develops. There probably are a lot of (heavy) opinions on this inside
the GCC community, and it it'll be interesting to see which directions they
choose to go.

~~~
devinj
_throwing an exception in the constructor comes to mind_

I don't know C++ and thus don't know all the different ways to break
constructors and destructors, but this particular way will be banned--
exceptions are off-limits.

I kind of think that the worst part of all of this will not be the C++ code
that is added to gcc, but the massive bikeshedding that looks to be inevitable
at the start.

~~~
stingraycharles
Yes, that would indeed be the case if they compiled with -fno-exceptions,
which they just might do indeed, - otherwise, you can still cause exceptions
to be thrown without using them yourself (for example, if you're out of
memory, 'new Foo ()' causes a std::bad_alloc () exception to be thrown).

And yes, I feel for the people in the GCC community that have to lead the team
through this process of coming up with an acceptable policy most people agree
with. I'm pretty sure it will be a challenging task with lots of egos
colliding.

~~~
rwmj
Why wouldn't a compiler just abort if it runs out of memory? A compiler seems
to be a short running program -- I wouldn't even bother too much freeing up
allocated memory.

~~~
scott_s

        PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
      19087 scschnei  25   0  412m 333m 5480 R  100 16.6   0:07.62 cc1plus
    

Your C++ compiler would be unusable for some modern C++ programs. You're
judging how you expect a compiler to behave based on how you've used them in
the past. C++ with heavy template meta-programming (like what I was compiling
there) can take an enormous amount of memory and CPU time to finish.

------
yason
Yes, they just allowed it. They're not going to rewrite gcc in C++.

But still, why, oh why?

Eventhough C++ allows, in some cases, the possibility to use easier syntax for
certain constructs, it's not particularly more expressive language than C. I
don't know gcc codebase but if they decided to actually reimplement something
in C++, it would take a lot of time just to make it comparable to the current
C implementation.

While something like a Haskell/OCaml implementation would probably be too
cutting-edge, considering the conservative inertia of such a big project, I
wonder why they didn't consider _some_ high-level language better suited for
compiler writing.

For a project like gcc, even designing a domain specific compiler-writing-
language wouldn't be too far fetched given the limited problem domain and the
big yields that a finely targeted language might give.

~~~
blub
...because large-scale C projects end up reinventing C++ features in a more
complicated, error-prone way.

C++ is much more expressive than C. It can compete on equal terms with other
high-level OO languages, it has some functional features and it contains all
of C. On the downside, it's difficult to learn and takes much time to become
proficient in.

Once you become proficient there's no contest.

~~~
boris
_because large-scale C projects end up reinventing C++ features in a more
complicated, error-prone way_

You are spot on. Here is an excerpt from a blog post on writing a GCC plugin:

 _The GCC AST itself is a curious data structure in that it is an
implementation of the polymorphic data type idea in C (next time someone tells
you that polymorphism works perfectly in C and they don’t need “bloated” C++
for that, show them the GCC AST). The base “handle” for all the AST nodes is
the tree pointer type. Because the actual nodes can be of some “extended”
types, access to the data stored in the AST nodes is done via macros. All such
macros are spelled in capital letters and normally perform two operations:
they check that the actual node type is compatible with the request and, if
so, they return the data requested._

[http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-...](http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-
cxx-with-gcc-plugin-part-2/)

------
madrik
"Both C and Lisp will be available as system programming languages." \- From
the GNU manifesto

Maybe just implement GCC in Lisp? Or am I just nitpicking?

~~~
randombit
All of the machine descriptions are written in Lisp. See gcc/config/i386.md
for an example.

------
implicit
This could be really great for GCC if they pick the right subset.

For instance, I could imagine that a GCC that takes advantage of namespaces,
overloaded functions, and template functions (notably: not classes,
exceptions, or implicit type coersion) to be quite a lot easier to understand
than today's deeply preprocessor-dependent GCC.

It's easy to assume that C++ implies OO, but you really don't need to go that
way, and you might not want to if you're starting with a project as old and
hardened as GCC.

~~~
danudey
I've heard anecdotal reports from a few developers that OS X's IOKit driver
framework, and its limited subset of C++, works very well. It's very limited
in terms of the language features available, and sounds like it strikes a good
balance.

Of course, this is all anecdotal. YMMV.

------
antirez
When I read this stuff, like what to ban, what to allow and so forth, it's
impossible for me to avoid thinking that actually C++, Objective-C, and D, are
not enough. We are still in a world where a "better C" is needed as the
available choices are not good enough.

~~~
protomyth
Out of curiosity, how did you lump Objective-C and D into this. I haven't
heard of people banning the use features of Objective-C and D like they do
with C++.

//well, except where the platform doesn't support the feature (e.g.
iPhone::Garbage Collection).

~~~
antirez
I don't think the reasons are the same. C++ is too complex, and while it's
true that exploiting advanced features it's possible to do a great deal of
things, it's not hard to imagine an object system for C much simpler and still
able to achieve most of the benefits.

I think Objective-C is taken alive by the fact that Apple is pushing it
forward, IMHO this is already telling enough about it. A few things are nice
but it's too verbose, the syntax is not nice, some semantic is tricky (memory
management is confusing for newcomers), and I feel in it a strange mix of high
level features with other things that are too low level or not well conceived
(like @synthesize).

D has other problems (like two different flavors and other stuff related to
the fact it's pretty recent) but I think it does not qualify as the "better C"
that can really be accepted in short time, as the difference with C is too
strong and it's not a strict superset of C.

What I think it's needed is a C with classes without fancy features and with a
solid standard library that makes good use of the new OOP stuff. The layer
that's enough to avoid to write structures and function pointers to fake
objects, just that tiny layer, but done right. Not claiming this is easy at
all, but probably there are very little people interested in solving this
problem right now.

------
dacav
AFAIK gcc is not the best designed program in the world (I just compiled it
once, and to me it seemed to be a huge bunch of patches over patches).

At the same time I know C++ enough to consider it extremely error-prone,
expecially if not managed correctly!

Put together the two things and ...maybe it's time to have a look to some
other compiler. What about TCC? :P

~~~
gvb
...or LLVM :-P

<http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine>

"The Low Level Virtual Machine (LLVM) is a compiler infrastructure, _written
in C++_ , which is designed for compile-time, link-time, run-time, and "idle-
time" optimization of programs written in arbitrary programming languages. "

~~~
protomyth
I am hoping LLVM / clang actually give GCC some competition. I like the
direction of using the same code for the compiler in tools.

------
icefox
"Before we start to actually use C++, we need to determine a set of coding
standards that will apply to use of C++ within GCC."

So we have another two months of bike shedding right here.

------
wglb
An interesting metric for this is if the resulting code is smaller. Wouldn't
we expect that to be the case using a higher-level language?

------
Bjoern
For those who don't know it: <http://yosefk.com/c++fqa/>

Very interesting read about the problems of C++.

