LWN: Comments on "GCC begins move to C++"

GCC begins move to C++

etienne — Mon, 07 Jun 2010 10:01:30 +0000

Maybe the FAQ of the FQA worth a read?
http://yosefk.com/c++fqa/faq.html
For me, I thank brinkmd for this FQA link, worth a read.

malloc() failure

nye — Mon, 07 Jun 2010 09:47:29 +0000

There are other reasons malloc can fail beyond having no free memory. In zfs-fuse they recently had to add code to increase max_map_count dynamically because ZFS makes so many allocations that it could easily blow right past the default limit, causing memory allocation failures.

GCC begins move to C++

vonbrand — Sat, 05 Jun 2010 15:48:12 +0000

The problem with stuff like C++'s strings or the proposed uint64_t use of "magic" is that as long as the magic doesn't leak out (i.e., the result is usable by mere mortals) everything is fine. As soon as the would-be magician looks into the book, caos as in the Disney classic Magician's Apprentice ensues.

You need magicians to write the magic code, and disciplined programmers who know that they shouldn't try their hand at magic... the last part is next to hopeless.

GCC begins move to C++

daglwn — Fri, 04 Jun 2010 15:40:17 +0000

No, it's really not very useful. Any FAQ (or "FQA") that starts with an ideological statement about its purpose being to "convince people...There is no reason to use C++ for new projects" is of course inherently biased. It's nothing more than childish whining (or a childish pissing contest, take your pick).

Yes, there are some issues with C++. Many are even being addressed in C++0x. But this "FQA" demonstrates a fundamental misunderstanding of the language, its design and its purpose. It's worse than useless. It will actually steer people in the wrong direction. Not just away from C++ (there are many cases where C++ is not appropriate) but away from sound technical analysis (maybe I don't need garbage collection) and into blind faith in highly dynamic systems.

GCC begins move to C++

brinkmd — Fri, 04 Jun 2010 15:05:38 +0000

No mention of C++ should go without mention of the C++ FQA (Frequently Questioned Answers):

http://yosefk.com/c++fqa/

It's a rebuttal of the C++ FAQ, and is a much more honest and useful explanation of the pitfalls of C++ than any other resource I found. If you ever thought while programming C++: "I can't be the first to try to do that, why is this so hard?", then the C++ FQA comes to the rescue.

GCC begins move to C++

dlang — Fri, 04 Jun 2010 10:06:28 +0000

the problem is that there are so many insane developers around (in every language, I'm not picking on C++ here :)

GCC begins move to C++

jrn — Fri, 04 Jun 2010 09:53:44 +0000

> Because C programmers routinely use examples which no sane C++ developer will ever write to prove that C++ is BAD BAD BAD.

Good point. I get annoyed when C programmers do it, too. :)

malloc() failure

jrn — Fri, 04 Jun 2010 09:46:12 +0000

On Linux, this is true but mostly irrelevant. Most systems overcommit (it is hard to find a saner thing to do if the user wants large programs to be able to fork() but does not provide the swap to back them) and malloc almost never fails.

GCC begins move to C++

daglwn — Thu, 03 Jun 2010 21:09:33 +0000

It's true that "OO" (it's a very overloaded term) can be done in many languages. The important thing is how much the compiler/interpreter can help you. I can write OO-style code in C with virtual functions and everything but then I have to implement my own vtables (violating the "don't write code you don't have to" rule) and I don't get the safety of access specifications, among other things.

The traditional UNIX paradigm of "everything is a file" is a fine example of OO design. What language it's implemented in is of little importance.

To me the important considerations for language choice do not include how powerful it is (they're all Turing complete in the end) but rather how well it maps to the problem domain and how many tools exist to help me find and fix problems.

You are right of course...

khim — Thu, 03 Jun 2010 21:07:11 +0000

This is exactly why you CAN'T write such code in gcc. malloc is forbidden there at include file level. Instead you'll use xmalloc - it can not ever return NULL, so there are no need to check the error code.

GCC begins move to C++

cdmiller — Thu, 03 Jun 2010 17:20:51 +0000

Huh, I was taught many years ago OOP is a style, independent of the programming language. See: http://openlibrary.org/books/OL1877952M/Object-oriented_a... for an example of this in action. Further, there are some applications where OOP will work well, and others OOP will overly complicate.

GCC begins move to C++

dgm — Thu, 03 Jun 2010 16:41:12 +0000

Why? Maybe I don't care if there is a problem with g, or I could do nothing sensible.

What I assume is that g-written-in-C cannot change the flow of control. That assumption doesn't hold in C++ with exceptions. That doesn't make C better, just different. Different enough, in fact, that converting C code straight to C++ is not that easy.

By the way:

@gowen: it's just an example.
@Cyberax: maybe g() can handle the NULL case gracefully, as it should if properly written.

GCC begins move to C++

dgm — Thu, 03 Jun 2010 16:31:42 +0000

Exactly, remember that it could not be the case initially, but the project will hopefully continue evolving, and thus the assumptions that made the code correct will change.

That's basically the problem. Adding exceptions to an established code base changes basic assumptions programmers would probably have made (nobody in his right mind would lose time writing exception-safe code if your language has no exceptions!).

GCC begins move to C++

mpr22 — Thu, 03 Jun 2010 13:50:45 +0000

C inflicts syntactic salt on me every time I want to do arithmetic on ordered pairs of integers; C++ doesn't :)

GCC begins move to C++

sylware — Thu, 03 Jun 2010 10:44:25 +0000

A proper C++ compiler is a monster compared to a proper C compiler, and that without any optimization framework. I dislike my software being dependent on a piece of software that is that hard to rewrite. "A kernel is already enough" sort of illustrate my opinion. I know many other components have faulted (from my point of view) the same way, but I feel better to remove them than add more. Till gcc does not need a C++ compiler to compile its C compiler, I'll stay quiet. If the steering comity decided othewise and it does happen, I will start to depart from gcc or try to make gcc C++ parts needed for the C optimizing compiler optional. In the case I depart from it, I'll feel the pain of losing the optimization part of gcc, but I'll try my best to depart from it. There are not many alternatives, since I do contribute GNU GPL only code...

Additionnaly, as I percieve it (I was a C++ coder), C++ helps too much (way more than C) coders to create brain damaged object orientish designs that ends up kludge/bloat. The mental dicipline in order to avoid such deviance can perfectly be applied to C too, then better be C which is easier to write a compiler for.

This is a part of my personal perception of that specific issue which explains for a bigger part my choices and my behavior: for all software use cases, I'm looking to reduce as much as possible size/complexity of the software stack. I really dislike the feature freakness and "over abstraction" many coders are falling for (I try to avoid it myself, it's hard). Down to the C++ issue, actually I do feel the same way for all langages. C is the less worse choice in my opinion.

GCC begins move to C++

HelloWorld — Thu, 03 Jun 2010 10:17:41 +0000

C++ was never at any point in its history any sort of pre-processor for C.

It depends on whether you consider "C with Classes" to be part of the history of C++. Stroustrup writes in hos book "Design and Evolution of C++" (page 27):

In October1979 I had a running preprocessor, called Cpre, which added Simula-like classes to C

However, that thing was replaced by Cfront not much later.

GCC begins move to C++

njs — Thu, 03 Jun 2010 05:44:41 +0000

That code is incorrect in C -- it fails to check g's return value for an error code. This may be (often is) a *much* more serious error than a leak.

You're assuming that g-written-in-C cannot fail, while g-written-in-C++ can, and then saying that that makes C better... which I guess is true given your assumptions, but if you have a method to write error-free code in C then you should share *that*, it'd be a much more compelling argument!

Better Than Exceptions

jamesh — Thu, 03 Jun 2010 01:43:06 +0000

The version using goto is a lot more readable.

While it is possible to write spaghetti code with gotos, they're also the most concise and readable way of implementing the equivalent of a "try {} finally {}" block in C. So there is no real reason to avoid their use in error handling of this type.

GCC begins move to C++

dvdeug — Thu, 03 Jun 2010 00:24:17 +0000

If either = or + in a = b + c(); can throw exceptions, then it's not the same code. You're looking at something like

a = copy_foo (add_foo (b, c()));

in C. If C++ would have thrown an exception, then a will have an error code in it (and a will have to support error values, and that value will have to be checked just like you have to catch an exception), a will have trash in it (and you'll have to check it--if you can) or the whole thing will crash, like if copy_foo assumes that add_foo can't return errors or trash.

The coding standards are the least of your worries!

daglwn — Wed, 02 Jun 2010 23:41:37 +0000

Some guiding principles:

Most of these are good. A few comments and additional suggestions follow.

Use inheritance only when you are dealing with similar but different behaviors. I.e. only when one inherits to implement pure virtual functions.

This seems too strict to me. There are reasons to inherit beyond overriding virtual functions. The Curiously Recurring Template Pattern is a prime example (replacing dynamic polymorphism with static polymorphism).

Isolate responsibilities into a class.

I think I know what you mean, but we have to be careful with how we define "class" or "object." A class does not necessarily have all of its functionality in member functions (see below).

Write down every piece of behavior only once.

If I understand your meaning, this is good in every language. Factoring out common behavior is always important. If I've missed your point, please follow up. It's good to learn from others.

Variables are private and never public. They may be protected when subclasses need access to them.

I would go even stronger than that. Rather than make the variables protected, make the accessors (possibly getters/setters) protected. That way you minimize impacts of data member changes.

Avoid using `friend'. Don't use private and protected inheritance, these are meaningless.

This also seems overly restrictive. In general, yes, one doesn't need private or protected inheritance, but they have their uses, especially when composing behaviors from several classes (aha! see the next point :) ).

Don't use multiple inheritance. It is a can of worms. When you think you need it, you likely have violated the first two principles.

This is by far my biggest pet peeve of most "good C++ practice" lists. MI is incredibly useful. What one usually doesn't want to do is create a diamond hierarchy where base classes have data members. The problem with data members in diamond hierarchies is the ambiguity of initialization. The most-derived class needs to take care of initializing base class data members, which breaks encapsulation. But MI is very, very useful for imparting properties and/or varying behaviors on a common class (template). Mixins are wonderful things. MI gets used all over the place when template metaprogramming is involved (c.f. Modern C++ Design, boost, etc.).

I would add these guidelines:

Make all virtual functions private with a public API when necessary. This allows one to insert various behaviors (debug messages, etc.) in the public API once and have it apply to all invocations of the (private) virtual function.

Example:

class Base {
private:
  virtual void doItImpl(void) = 0;

public:
  void doIt(void) {
    debug("Calling doIt!");
    doItImpl();
  }
};

class Foo : Base {
private:
  void doItImpl(void) {
    doSomething();
  }
};

Enforce const correctness (applies to C as well).
Use RAII liberally.
Use exceptions.
Use type generators to specify data structure types. Do not hard-code std::map<>, etc. When C++0x is ready, use template aliases. This allows one to easily swap out data structure implementations and specialize them for various types. This is quite useful when working to optimize runtime.

Example:

template<typename Key, typename Value>
struct MapGenerator {
  typedef std::map<Key, Value> type;
};

template<typename Value>
struct MapGenerator<int, Value> {
  typedef MyFancyEfficientIntMapper<Value> type;
};

typedef MapGenerator<double, std::string>::type DoubleStringMap;
typedef MapGenerator<int, std::string>::type IntStringMap;

Prefer free functions. This may seem counterintuitive, but actually makes generic programming easier. Compare boost.Range(Ex) and the standard algorithms. Having freestanding begin() and end() functions is super useful. The same pattern applies to many intrinsic operations. Making them free functions instead of members means that one can adapt existing classes to the interface without having to muck around with changing the class (adding member functions, etc.).

And my number one guideline:

Do not write code unless you have to. This may seem obvious but there are countless examples of projects that refuse to use existing libraries like boost and end up reimplementing them. Badly. Reimplement the stuff if necessary, by all means (to solve proven performance bottlenecks, for example), but make a darn good case for doing so. This is right up there with "Don't optimize prematurely."

GCC begins move to C++

anselm — Wed, 02 Jun 2010 22:26:04 +0000

You can probably do functional or generic programming in assembly language, only (similar to the C++ vs. plain C situation) it is enough of a hassle that, on the whole, people don't bother these days because more convenient methods are available.

The coding standards are the least of your worries!

ikm — Wed, 02 Jun 2010 21:34:21 +0000

> Well if you want your class to be a Werewolf but don't want the world to know about it your class really isn't a werewolf but has-a werewolf.

Maybe to the world, but not to him. To him, he is a werewolf. At night, when there is a full moon, he transforms into an unholy beast and hunts basic_strings. The world doesn't have to know.

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 21:21:44 +0000

Well if you want your class to be a Werewolf but don't want the world to know about it your class really isn't a werewolf but has-a werewolf.

Your Foo class in your example is now a QThread except that it isn't: the outside world cannot call any of the methods that make it a QThread.

That you find yourself forced to use protected inheritance in your example is due to a modelling flaw in the QThread class. Not unlike the situation in which I found myself forced to subclass a HTTPConnection only to be able to get to the headers of a HTTP request. The QThread class should have something like a Worker member having the run() method. You implement a Worker (ie subclass it and implement the virtual run() function). You have a Qthread instance var, feed it your worker implementation, and call start() on your QThread.

A useful way, BTW, to find out whether you have woven different concepts into a single class, that thus should be decomposed into different classes is this:

Picture all the instance variables of your class and it superclass on one side. Likewise, picture all functions on the other side. Now draw a line between a function and a variable when said function uses that variable, If the resulting class now tends to consists of several unconnected graphs you have reason to consider decomposing your classes: the belong to the same hierarchy but appear to be unrelated.

Applied to the QThread example: the designers of the QThread should have asked themselves the question: is it desirable that an implementation of the run() function have access to the protected instance variables? The answer is no. Because QThread deals with the machinery of threading while the run() functions deals with matters of the user's problem domain, like reading messages from a queue. The stuff in the run() function is therefore another beast that needs to sit in its own class.

I find your 'moron' remark rather odd. Firstly, no language is perfect, no language designer is. Secondly, C++ was conceived at a time when understanding of OO was, by today's standards, rather limited.

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 20:57:29 +0000

I forgot.

To recapitulate:

When you write an HAS-A as an IS-A you really tied two concepts into one which are not.

Suppose you have class D: C

Suppose later you need another flavor of C, say B, or you have to rewrite D You will have to rewrite D and its relationship.

Now write:

class D {
private:
C c;
}

You one day need a B. Introduce an abstract base class A for both B and C:

class D {
private:
A a;
}

Now you have the advantage that you can easily change 'a' to be a B or a C.

BTW, there's people that take this advantage to the next level. They recognized that A has become a dependency of D. And rather than hard-wiring this dependency in your code created tools that allow you to specify in a configuration file whether 'a' should be an B or a C. Some day another kind of A is needed? Write a class E, deploy it, modify the config file and there you go.

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 20:38:27 +0000

Well.. a HAS-A relationship being modelled as an ISA-A?

Please see my HTTP connection example in my post http://lwn.net/Articles/390256/ to see why this is, in general bad.

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 20:18:18 +0000

@Ed_L & Tobu

Surely. These are guidelines. And my list is not complete I might add. I like to formulate them a bit strict. Firstly to make them clear. Secondly to steer programmers with little OO experience away from the abuse their instinct seems to drives them to. You are allowed to break the rules when you understand them a kind of being the motto.

There will always be situations where we have to break the rules. Rules cannot deal 100% with all the details a quirks of reality.

And, of course, there are always situations where the nature of the underlying problem is such that deviation from the rules is the required solution, such as building a class hierarchy, or using friends.

The coding standards are the least of your worries!

ikm — Wed, 02 Jun 2010 20:09:59 +0000

And by the way, it is still an IS-A relationship, since I can access inherited protected members and override virtual functions. This relation isn't exposed to the outside world, though. Imagine a Class which is a Werewolf, but it doesn't actually want anybody to know about that fact :)

What I want to say is, protected/private inheritance makes sense. A classic example is when you want to make an active object:

class Foo: QThread
{
...
private:
virtual void run();
}

You don't want start() and stop() to be exposed to the outside world, and yet you want it to be a thread (by being able to override the actual thread function).

Lastly, stating that something in the language is plain "meaningless" is implying that the people who agreed to add it to the standard are morons. This rarely makes sense.

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 19:55:47 +0000

Well I may have jumped to conclusions about the OO awareness of the GCC team. If that is the case, sorry.

I've become a little touchy on the issue having seen so many C programmers struggle and failing with OO and seen so many programmers when asked about code quality jump right into detail issues like naming conventions and where to place the opening brace. Significant issues but the overall issues are way more fundamental.

See my post elsewhere for a comment on the guidelines.

The coding standards are the least of your worries!

ikm — Wed, 02 Jun 2010 19:54:41 +0000

> writing a HAS-A relationship as if it where an IS-A relationship.

Yes, that's exactly what I'm doing. What's wrong with it, exactly?

The coding standards are the least of your worries!

rev — Wed, 02 Jun 2010 19:48:16 +0000

Because they amount to delegation to a private/protected member. What you are doing when using private/protected inheritance is writing a HAS-A relationship as if it where an IS-A relationship.

Java advantage

man_ls — Wed, 02 Jun 2010 19:37:43 +0000

In this respect Java is definitely better than both: you define attributes and methods on the same file, and you don't need separate declarations.

It has always bothered me that I needed to add something in two places to get an accessible function. With a little perspective header files look like a way to make the preprocessor happier at the cost of developer time. Why C++ didn't fix this little detail is beyond me.

Better Than Exceptions

mjthayer — Wed, 02 Jun 2010 19:15:41 +0000

> This example reminds me of the "obvious solution" which leads you to the tar pit .

Somehow I feel that this must also be an answer to the original question of "what is wrong with exceptions" (in C++). That they are sufficiently non-obvious to use that almost twenty years after they were first introduced electrons are still being spend explaining how to use them safely, and people still feel the need to debate on lwn.net whether or not they are a good thing. I can't put it down entirely to people being stuck in the past.

The coding standards are the least of your worries!

ikm — Wed, 02 Jun 2010 18:50:48 +0000

> Don't use private and protected inheritance, these are meaningless.

And why is that, exactly?

GCC begins move to C++

Cyberax — Wed, 02 Jun 2010 18:47:09 +0000

That's a good point :)

GCC begins move to C++

ikm — Wed, 02 Jun 2010 18:45:30 +0000

> Why shouldn't C++ developers do the same?

Maybe because they don't have a problem with C?

GCC begins move to C++

Cyberax — Wed, 02 Jun 2010 18:35:23 +0000

"I cannot imagine an experienced C programmer using
for (i = 0; i < strlen(line); i++)
except to prove a point, for exactly this reason."

Nope, it's a great example. Because C programmers routinely use examples which no sane C++ developer will ever write to prove that C++ is BAD BAD BAD. Why shouldn't C++ developers do the same?

"How does one explain the Linux kernel? Of course it includes abstraction where appropriate, just like most reasonably-sized C programs do."

Linux is good because it's not actually quite that big. Most of code is in the drivers. And its infrastructure code if fairly compact and has quite clean abstractions.

The coding standards are the least of your worries!

Cyberax — Wed, 02 Jun 2010 18:27:30 +0000

This is exceedingly bad design. Any good C++ programmer will write:

std::auto_ptr<C_BAR> bar(new C_Bar());

...or something like it. It's exception- and leak-proof.

In one of my projects we had a 'no naked new' rule. So the result of EACH 'new' must be wrapped in a smart pointer (there were only a few carefully audited places where this policy was relaxed). Worked wonders.

GCC begins move to C++

jwakely — Wed, 02 Jun 2010 18:05:08 +0000

You can do exactly the same in C++, since it's almost a strict superset, how is C better at it?
There are also other alternatives in C++, with their own pros and cons.

GCC begins move to C++

Cyberax — Wed, 02 Jun 2010 18:01:12 +0000

This code will most probably SEGFAULT in C if allocation fails and malloc() returns NULL.

Is it better than a thrown exception?

GCC begins move to C++

cry_regarder — Wed, 02 Jun 2010 17:48:23 +0000

Whatever. Your argument is equivalent to saying that generic programming and functional programming are facilitated by assembly language.