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 427522
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: So what?
by bnolsen on Tue 1st Jun 2010 17:02 UTC in reply to "So what?"
Member since:

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:

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:

- 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