Re: Converting GCC to compilation with C++

[Joe Buck <Joe dot Buck at synopsys dot COM>]

This discussion is probably moot because we aren't in danger of a
C++ rewrite in the near term.  However ...

Gabriel Dos Reis wrote:
> > Templates, overloading and multiple inheritance work for me and
> > all other programmers I know of or have met.

On Tue, Jul 13, 2004 at 10:01:47AM -0400, Robert Dewar wrote:
> Well I must say I entirely agree with David Korn that there are
> real risks, and I find it worrisome that Gaby does not see them.

Well-architected C++ programs are lower-risk than C programs, and
can be much more robust, because we can come much closer to the
Write Things Once ideal than we can in C, that is, that design
decisions are almost always reflected in one localized place in
the source code, rather than scattered all over the program.
Architectural decisions that would result in unmaintainable C
code can result in highly maintainable C++ code (because, for
example, destructors can assure that resources are always freed).
Data structures can be completely changed with far less disturbance to the
code that accesses those data structures.

The fears that you are raising are irrelevant in a project where all
proposed patches are carefully reviewed.  Yes, it's possible to write
completely opaque operator overloading schemes in C++, but only
rank beginners ever try something like that, and any patch that
did that would be rejected.

> Indeed if we have people around who are C++ advocates and do not
> see the risks, that's a problem, and likely to lead to difficult
> to maintain code.

The problem is that you and Gaby are using different terms.  What you
are calling a "risk" Gaby would call "incompetent C++ coding".  Simply
put, many of us have a decade of experience with C++, and we know what
works and what doesn't work.  C++ is not some unproven new thing being
proposed by radicals without real world experience.

> For someone to say that they see no problems
> with MI is frankly quite amazing to me. Now if someone said
> "I am an expert, I know how to use MI without introducing
> problems", OK, but that's not what Gaby said above, he said
> that all the programmers he knows of have no problems with MI.

No, Gaby said above that the features "work", not that no one has
ever had problems.

C++ beginners overuse MI; in practice it is rarely the best way to
solve a design problem, but sometimes it is.  When it is, it is an
efficient solution.  Patches that use MI inappropriately would be
rejected.

> As for overloading, I would be quite impressed if Gaby can
> reproduce the exact rules from memory, but certainly he may
> be able to, but to tell me that all the programmers he knows
> of know these rules precisely is simply not credible (unless
> he knows very few other C++ programmers).

Again, you confuse the issue.  Good C++ programmers use overloading
sparingly, and rarely run into situations where the detailed rules
of overloading is an issue.  Patches that misuse overloading would
also be rejected.

> Note that I would have similar worries for Ada, though it is
> probably less likely in Ada than in C++ to "go bananas",

You know Ada well, so you would not "go bananas" in that language.
Gaby and I know C++ well, so we would not "go bananas" in C++.

> I would say the coding in gcc at the moment has a reasonable
> style, except for the abominably complex conditionals that
> people seem quite fearless in writing.

That is a very big "except".

> In fact this tendency
> of people to have no compunction in writing very complex
> logic is exactly what makes me worry about letting the C++
> folks who are quite fearless when it comes to complex use
> of templates and multiple inheritance etc have at it.

If people just started whacking arbitrary C++ concepts into an
existing C design, without first spending time designing an
architecture, we would have problems.

> I still think that it will be hard to maintain discipline.
> In the case of the way C is used in GCC, there is a kind
> of community discipline that is imposed which generates
> a reasonably uniform and non-obfuscatory style (with the
> exception I note above :-)

Certainly discipline is required.

> Probably the next step in taking this discussion past
> generalities (including the above) which have characterized
> it so far is for someone to propose a detailed set of coding
> standards. I am guessing that this is the point at which it
> will be impossible to gather a consensus, but perhaps I am
> mistaken. Gaby, why don't you take a shot at doing that,
> and try to restrain yourself as much as possible in an
> attempt to get something that more people might sign up to.

You seem to think that the right way of achieving "discipline"
is to, in effect, create a language subset that rejects many
useful features of the language.  For the most part, this is
wrong.  Certainly there are many useful coding style rules
out there, but they mostly have to do with avoiding problematic
*interactions* between language features.  Wise use of the
very C++ features you seem to dislike can result in more
robust design.

> I was asked to do the same, and I could, but my subset
> would look far more like C than C++ :-)

Then there's little point.  Most of the unreliable C++ programs
out there suffer from being too C-like (e.g. using fixed length
character arrays rather than the std::string class to store
user-supplied input, resulting in buffer overflows).