Inheritance in C: good, bad, or other?

Question

We have a large C code base that has been developed over several decades. One of the features of the code is a large dependence on function pointers and pseudo inheritance. The idiom (as discussed here) follows like so:

typedef struct twod_ {
    double x, y;
} twod;

typedef struct threed_ {
    twod super;
    double z;
} threed;

threed *point_3d;
twod *point_2d = (twod *)point3d;

At which point point_2d->x and point_3d->x are the same block of memory.

My questions are:

Is this idiom still popular in modern production code? (Any recommended open source examples)
This code has a requirement for performance -- does this idiom help with speed and/or memory usage?
The way that it has been implemented (or due to many years of code bloat) it now feels a bit like spaghetti code -- generally speaking, is this a problem with the implementation, or the idiom? Or to put it another way, in an ideal world, would 500k LOC with this idiom be quickly understood?

Of course, the adage "if it aint broke, don't fix it" would be a good one to keep in mind; however, that isn't really helping us at the moment, so we think we might have to go deeper with refactoring...

Thanks!

I would say you will end up in undefined behavior there once you attempt to dereference your "twod" variable, but if you just replace the last line by `twod *point_2d = &point3d.super;` the waters are good. — jørgensen, Jan 19 '12 at 15:57
I don't think any 500k LOC can be quickly understood, regardless of idiom — AndersK, Jan 19 '12 at 15:57
I think by twod *point_2d = (threed *)point3d; you actually meant twod *point_2d = (twod *)point3d; — MetallicPriest, Jan 19 '12 at 16:05
The idiom, to a C programmer, is familiar, everyday usage and perfectly understood. That's not a problem. I'd guess your problem is the half-million strands of spaghetti. — Pete Wilson, Jan 19 '12 at 16:07

score 2 · Accepted Answer · answered Jan 19 '12 at 15:59

2

I'd say it's fine, although of course it can be easy to go confused since it becomes rather verbose.

For me, the flagship open source implementation of "C with classes" is probably GTK+, specifically the gobject module.

answered Jan 19 '12 at 15:59

unwind

391,730
64
469
606

To mention a few more: the GNOME desktop, GIMP (ofc GTK+ as you have mentioned!!), GStearmer also use GObject – another.anon.coward Jan 19 '12 at 16:06

WoLfulus · Answer 2 · 2012-01-19T16:20:19.413

This will work, but the problem you have to keep in mind that the compiler will not warn/say anything to you about problems related to variable access or anything like that. This method not type-safe because sometimes this explicit casts can be evil. Take this example as example:

typedef struct _A
{
    double x, y;
} A;

typedef struct _B 
{
    A super;
    double z;
} B;

typedef struct _C 
{
    A super; // we wanted B, but wrote A by mistake
    double w;
} C;

C* c;
B* b = (B*)c;

// will write to C::w instead of B::z and no one will warn you about this.
// you'll need to track this by hand after your application crashes.
b->z = 1234;

This type of thing can put an airplane on the ground easly. :)

About performance, this will end up doing the same thing as if you take the pointer to super by hand (more safe than casting):

A* a;
B* b = &a->b;

Also I don't think this is popular these days (at least not for younger programmers like me that grew programming in more modern compilers)

Also, C++ compiler is an option? More modern compilers these days that allows struct inheritance - better than casting it this way.

score 0 · Answer 3 · answered Jan 19 '12 at 16:07

Like (almost) everything in C, as long as you know what do you do, it's fine. But be aware that problems can appear very easyly - for example, if you have an array of threed, you can't cast it to an array of twod. (accessing members of that casted array is undefined behavior)

score 0 · Answer 4 · answered Jan 19 '12 at 16:26

Is this idiom still popular in modern production code? (Any recommended open source examples)

It is somewhat rare, though you see it now and then. I wouldn't call it popular, the uses of polymorphism in C programs are often few.

This code has a requirement for performance -- does this idiom help with speed and/or memory usage?

It will certainly not make the code more efficient than a struct containing all 3 members. At worst, the heritage will make the code less efficient. The best way to tell is to disassemble to compiler output for your specific platform and see for yourself.

...is this a problem with the implementation, or the idiom?

Inheritance in general should be used carefully, inheritance for the sake of inheriting fills no purpose. That is true for all OO languages.

Personally, I do think this particular idiom and similar attempts to include mildly useful OO features in C are problematic. Mainly because they add significant complexity to the program. Things like this were preached in the book "Object-orientated programming with ANSI-C" (Axel-Tobias Schreiner, released early 90s). I personally find most things in that book quite horrible.

in an ideal world, would 500k LOC with this idiom be quickly understood?

That depends a lot more on the program structure, file structure and coding standards, than on this little OO idiom. Though of course 500k loc will not be quickly understood even if the program is state of the art.

Inheritance in C: good, bad, or other?

4 Answers4