GCC begins move to C++

Posted Jun 1, 2010 16:36 UTC (Tue) by dgm (subscriber, #49227)
In reply to: GCC begins move to C++ by rev
Parent article: GCC begins move to C++

return codes don't change control flow. That's the reason avik had to introduce auto_ptr<> and RAII besides exceptions in his example above.

consider for instance:

void f(void)
{
    T * p = malloc (sizeof (T));
    g(p);
    free(p);
}

This code does not leak memory in C, but can leak in C++ with exceptions.

Remember we are talking about a _large_ amount of C code that was not written with exceptions in mind.

GCC begins move to C++

Posted Jun 1, 2010 17:03 UTC (Tue) by avik (guest, #704) [Link] (2 responses)

It's possible to transition incrementally:

1. Pick a function
2. Modify its callers to expect exceptions from it (adding try/catch if necessary)
3. Convert it to throw exceptions instead of returning error codes
4. Modify it to expect exceptions from its callees (removing try/catch if necessary)
5. Repeat

If correctly applied, an entire code base can be converted with very little explicit try/catch blocks remaining.

GCC begins move to C++

Posted Jun 1, 2010 17:23 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

It's certainly doable, but I would bet the cost is too high to make it worthy. I believe the GCC code base is above one million LOC. Assuming half include a function call, the task looks daunting.

GCC begins move to C++

Posted Jun 1, 2010 18:01 UTC (Tue) by avik (guest, #704) [Link]

I have successfully applied this technique to a code base that was about a quarter of that size (though considerably less gnarly). Whether it will be worth the effort or not is very subjective.

GCC begins move to C++

Posted Jun 2, 2010 11:13 UTC (Wed) by gowen (guest, #23914) [Link]

How about...

void f(void)
{
    T p;
    g(&p);
}

GCC begins move to C++

Posted Jun 2, 2010 18:01 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

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

Is it better than a thrown exception?

You are right of course...

Posted Jun 3, 2010 21:07 UTC (Thu) by khim (subscriber, #9252) [Link]

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.

malloc() failure

Posted Jun 4, 2010 9:46 UTC (Fri) by jrn (subscriber, #64214) [Link] (1 responses)

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.

malloc() failure

Posted Jun 7, 2010 9:47 UTC (Mon) by nye (subscriber, #51576) [Link]

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++

Posted Jun 3, 2010 5:44 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

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!

GCC begins move to C++

Posted Jun 3, 2010 16:41 UTC (Thu) by dgm (subscriber, #49227) [Link]

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.