Linked by Thom Holwerda on Tue 1st Jun 2010 15:12 UTC
General Development "I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake. 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."
Thread beginning with comment 427517
To read all comments associated with this story, please click here.
So what?
by theosib on Tue 1st Jun 2010 16:47 UTC
theosib
Member since:
2006-03-02

I guess it's vaguely interesting, but I see adding C++ to a compiler like adding C++ to a kernel: Opening up a can of worms.

I've read 6 C++ books cover to cover. I'm not a world-class expert, but I know a lot about how to write C++ code and deal with all of the gotchas (like defaulting to pass by value, to mention a relatively minor example). If you don't know what you're doing, your C++ code will have miserable performance.

The main reason to use C++ over C (which I do a lot) is the convenience of object-oriented programming. There are a lot of things that take a lot less time to write in C++, especially with some of the libraries like STL. Also, there are some great performance GAINS you can get using templates, inlining, and metaprogramming. (IIRC, the STL sort() function is said to be like 5 times faster than the glib qsort, because at compile time, it builds a template function specialized to the type you're sorting, rather than having to make calls to a compare function through a function pointer.)

So, I guess what they're going to get out of this is perhaps some more rapid development (but lower performance) and perhaps a few cases of improved performance.

Reply Score: 4

RE: So what?
by bnolsen on Tue 1st Jun 2010 17:02 in reply to "So what?"
bnolsen Member since:
2006-01-06

Keep the worms under control.

Eliminate all use of macros except for platform specific only. Use inlines and simple tempate functions instead. Use namespaces based on module names. Namespace *everything*, including anonymous namespaces.

Use the functional programming part of c++ <algorithm> to great advantage. Limit template use to providing compatibility with <algorithm>.

Replace structs with class, keep struct members public as before (it's stupid to write simple accessors for the sake of writing accessors). Avoid inheritance of any type as much as possible. Keep constructors very simple, use named "static" constructors and have "isValid" method check in every class.

Exceptions are potentially a huge black hole (what really is "exceptional?"). Getting fancy with templates is bad (reference stupid template tricks found in boost).

All in all not a bad choice. Be careful with the cannon that is C++.

Reply Parent Score: 5

RE[2]: So what?
by mat69 on Tue 1st Jun 2010 19:10 in reply to "RE: So what?"
mat69 Member since:
2006-03-29

Indeed. That is also what the original thread starter suggests later on:


I think we've decided to switch, but we haven't decided to what subset of C++ we're switching. I think that we want what might be called the "syntactic sugar" subset. For example, single inheritance to replace our C-style inheritance, constructors/destructors to replace explicit calls to required initialization/finalization functions, and member functions to implement ADTs, namespaces to save us some typing.

None of these things impacts memory use, or run-time performance.
Generally speaking, these are things that remove lines of code, help to prevent mistakes made by casting or forgetting to obey requirements of APIs, and make it easier to replace particular components without impacting large parts of the rest of the source code.


I think this is the right way to go: Using C++ to make things easier not to make them harder.
And later on if the need for another feature arises things could be discussed again, but being conservative initially is a good thing and still provides nice possiblities.

Reply Parent Score: 2

RE[2]: So what?
by google_ninja on Wed 2nd Jun 2010 02:36 in reply to "RE: So what?"
google_ninja Member since:
2006-02-05

- limit the use of clever metaprogramming only to where its needed
- use FP techniques whenever possible and appropriate
- always favor composition over inheritance, and limit inheritance hierarchies whenever possible
- use constructors to initialize the object, not as a place for logic
- have consistent validation of objects
- never use exceptions as flow control

great six points applicable to any OO programming language :-)

Reply Parent Score: 1

RE: So what?
by Morty on Tue 1st Jun 2010 17:41 in reply to "So what?"
Morty Member since:
2005-07-06

If you don't know what you're doing, your C++ code will have miserable performance.


Since they are writing a compiler, hopefully they know what they are doing and also know the language. Otherwise I don't think miserable performance will be the biggest problem.

Reply Parent Score: 5

RE[2]: So what?
by Delgarde on Tue 1st Jun 2010 23:38 in reply to "RE: So what?"
Delgarde Member since:
2008-08-19

Since they are writing a compiler, hopefully they know what they are doing and also know the language.


Not necessarily. Certainly, those responsible for the C++ compiler itself must know what they're doing. But one of the reasons they're being cautious is that many of the core developers are *C* coders, not necessarily familiar with C++.

Reply Parent Score: 2

RE: So what?
by vivainio on Wed 2nd Jun 2010 19:11 in reply to "So what?"
vivainio Member since:
2008-12-26

I guess it's vaguely interesting, but I see adding C++ to a compiler like adding C++ to a kernel: Opening up a can of worms.


I don't see the equivalence. Compiler is basically a glorified data processor, completely neutral to timings and whatnot. It's basically batch processing, something you could do in BASIC or cobol.

C++ is welcome improvement. I don't see a C based system staying competitive with llvm for a long time. C is just much less productive, less readable and as a consequence less fun.

Reply Parent Score: 3

RE[2]: So what?
by theosib on Wed 2nd Jun 2010 20:47 in reply to "RE: So what?"
theosib Member since:
2006-03-02

You're obviously not a Gentoo user. ;)

People have been complaining for a long time about GCC compilation speed, and they cheer every time it's sped up. And not just Gentoo users. Anyone who runs a compile farm for some reason or other will appreciate a fast compiler. (For instance, MetroLink had a compiler farm for their MetroX server and drivers.)

Reply Parent Score: 2