C vs C++, from the author of ZeroMQ

Bulb

Now I'm not a C/C++ programmer, but won't that do a null dereference if you pass it the start or end of the person list?

Normally you'd use a circular list either with or without head. Back when I programmed in pure C, clone of Linux list_head was my preferred tool. Of course, now whenever std::vector<something> does not work for me and something like that seems suitable, I just reach for boost::intrusive::list, which is exactly the same thing in a typesafe package.

@EvanED said:

1) You can use a circular linked list with a distinguished "end" node and avoid the special cases. (Actually... I'm not quite sure why this isn't more common. Maybe it is and I just don't do enough C to see it, and always see abstractions.)

It's not a “distinguished end”, it's either head (if the list has a head) or it's the first element again.

@cvi said:

catching the exception locally if you need to do some local cleanup

Actually, when you need to do some local cleanup, you should usually just create a guard that will do it in it's destructor.

@Nprz said:

His use of exceptions seem like he missed the point of what exceptions are good for.

There is a trouble with exceptions. Either you have to be serious about them, or leave them alone, but there is mess in the middle.

When you decide to use exceptions, you have to write the code to be exception-safe, that is that if exception is thrown through it, it will leave everything in defined state. You'll find yourself using a lot of RAII and std::swapping from temporaries and hiding stuff in pImpls that can be swapped like that. It can be done, but it is a big change in programming style.

Of course writing exception-safe code has a huge advantage, because such code is also resilient against resource leaks caused by simply forgetting to clean up, so you really should write it anyway. It goes without saying that this has no equivalent in C.

@dkf said:

it's quite a lot harder to make a stable ABI with C++ than with C

Well, yes, I hate that too. Basically in C++ you have to specifically write a façade to hide the actual code behind. And templates (that are otherwise the too you use C++ for) can't be hidden, so when you use them, they are set in stone. Fortunately this problem only matters for system libraries and frameworks.

@Maciejasjmj said:

In a sensible language you'd also have a finally block to simplify matters, but in this case you can probably set checking to false in the catch clause just fine.

That's what the guards are for. Basically you write, once for all similar cases (or get somewhere), something like

template <typename T> class Restore {
    T old_value;
    T &variable;
public:
    Restore(T &var, T val) : old_value(var), variable(var) { var = value; }
    ~Restore() { variable = old_value; }
};

and then you simply

Restore<bool> rc(check, true);

(it can be improved to infer the type, with a bit of magic even in C++03) instead of check = true. And now it will be restored after exception, but you now also can't forget to restore it.

@Maciejasjmj said:

C++ was the best of the worst before, but Bjarne still botched it by insisting on backwards compatibility with C - it exposed way too many naughty bare-metal bits for people to get hurt on.

Rust is the first language that can do most of the cool things I use in C++ and brings something useful as a bonus. D had the features, but not that much new stuff, but it failed due to disagreement about how standard library should look. Java and C# don't come even close. That does not mean Java or C# would not be better tools for many jobs. Hell, for GUI I'll take Python or JavaScript over C++ any time.

But most importantly, neither Java nor C# are portable between mobile platforms, so if you want that, you are still stuck with C++ — unless javascript is good enough for you, which, honestly, for many application it now is.

cvi

@Bulb said:

@Maciejasjmj said:
In a sensible language you'd also have a finally block to simplify matters, but in this case you can probably set checking to false in the catch clause just fine.

That's what the guards are for. Basically you write, once for all similar cases (or get somewhere), something like

...

Or you use something like BOOST_SCOPE_EXIT (which, with C++11 can be made significantly less ugly).

Bulb

My general impression is that it's like he was complaining that modern car is more complex than model T while failing to mention that the modern car is faster and significantly safer.

For example, he's comparing C code of

struct foo
{
    ...
};

int foo_init ()
{
    ...
}

int foo_term ()
{
    ...
}

int foo_bar ()
{
    ...
}

to C++ code like

class foo
{
public:
    foo () : state (semi_initialised)
    {
         ...
    }

    int init ()
    {
        if (state != semi_initialised)
            handle_state_error ();
        ...
        state = intitialised;
    }

    int term ()
    {
         if (state != initialised)
             handle_state_error ();
         ...
         state = semi_terminated;
    }

    ~foo ()
    {
         if (state != semi_terminated)
             handle_state_error ();
         ...
    }

    int bar ()
    {
         if (state != initialised)
             handle_state_error ();
         ...
    }
};

But that is not equivalent. C++ equivalent of the C code would be just

class foo
{
public:
    int init ()
    {
        ...
    }

    int term ()
    {
         ...
    }

    int bar ()
    {
         ...
    }
};

It would die hard if the user failed to call init and term, but so does the C version. The extra code in the C++ version is a cost, but it provides some benefit too, namely additional safety.

Besides, I can't think of a case where extra variable would be needed. Initialization can only fail if the object holds some resources and a NULL handle can be used to indicate the object was not (successfully) initialized.

Even more so, deinitialization generally shouldn't fail. What do you do if releasing a resource fails? It can only happen if you cardinally screwed up and are passing invalid handle, in which case trying to salvage it is usually futile, because your state is likely fubar anyway.

Exception is operations that flush and close a resource like fclose(3). In this case, the destructor should probably assert(3) in debug to make the mistake of forgetting to call the finalizer easier to find (which, again, C can't do at all) and just log and discard it in release (to make the code resilient). It's still better than leaking the handle.

dkf

@Bulb said:

Fortunately this problem only matters for system libraries and frameworks.

What do you think some of us are supporting?

Bulb

[…] the very ideology of the object-orientedness makes developers think in specific ways and design their algorithms and data structures accordingly.

I think this might be his primary and main fault. C++ is not about object-orientation. It is about implicit resource management (RAII) and generic programming and it also happens to support object oriented stuff.

std::list <person*> people;

The most stupid think in this is the *. If he put the object in the list by-value, as is usual (unless you need dynamic polymorphism, which in C is pain anyway), the result would be equivalent to the C version and simpler and safer.

Bulb

@dkf said:

What do you think some of us are supporting?

Of course I understood you are supporting a library. And yes, I hate the fact maintaining stable library ABI is pain. And even more hate the way Microsoft runtime versions are mutually incompatible (gcc had some ABI transitions too, but it's been quite long since the last one). But it's still relatively small part of all work done in C++.

In fact the product I work on also comes with a library, but we solved the problem by providing a thin library with C API that controls the actual application over IPC. Fortunately the API does not need to be that large.

Zecc

@EvanED said:

C gives you qsort; C++ gives you std::sort. One of those is significantly faster than the other. (Hint: it's not qsort.)

Why might that be?

Is something preventing qsort's code from being optimized?
Something to do with its API or ABI?

dkf

@Bulb said:

In fact the product I work on also comes with a library, but we solved the problem by providing a thin library with C API that controls the actual application over IPC. Fortunately the API does not need to be that large.

I'm supporting a programming language that's pretty widely used industrially. We have our own API→ABI compiler that allows us to keep it extremely stable, much more so than you'd usually get with C (let alone C++, which is far too keen to spray knowledge of things like type sizes around). Some of the techniques we used were inspired by what the Windows API does, and others are based on what ELF dynamic linkers do (but ported to be cross-platform and coupled into our version management infrastructure).

20 year support of any interface is not simple, especially when you're wanting to be able to evolve that interface as well…

dkf

@Zecc said:

Is something preventing qsort's code from being optimized?

There are other sorts that are potentially faster (qsort depends heavily on having good partitioning) and if they're comparing the sorting of int vs int* there's a whole world of possibilities for complexity right there. (Cache coherency is the most likely candidate for trouble, and that's not something that most performance analyses consider.)

Zecc

@dkf said:

There are other sorts that are potentially faster (qsort depends heavily on having good partitioning)

I wouldn't think qsort necessarily needs to be implemented as a quicksort.

So if I'm reading you correctly, the problem here is that C doesn't support templates and you can't specialize with different algos for different classes?

Bulb

@Zecc said:

Is something preventing qsort's code from being optimized?

Yes. The use of function pointers.

std::sort is a template. Those are code-generated for each instantiation and the substituted type defines what to call for comparison, so everything is there for the compiler to inline it. On the other hand qsort uses function pointers and is compiled just once and lives in the library. This means it is not available for the compiler for inlining.

It's a trade-off. The std::sort is almost always inlined, so it's faster, but there is more code. The qsort exists just once, but it is slower due to the overhead of calling otherwise trivial function (comparisons usually are very simple) via indirection.

EvanED

@lightsoff said:

Because a linked list is almost always the wrong datastructure, especially for a modern target CPU.

That's nice. They're still pretty common, and I'm not sure why the "circular list with a linear-list interface" isn't a larger proportion. (Or maybe they are. Who knows.)

@lightsoff said:

The "next" and "prev" items probably aren't in the CPU cache, and might even be paged out.

This is totally true. Not just that, but the next/prev pointers themselves decrease cache density. This can make something like vectors faster even in cases where it seems like a list "should" be faster.

(An example article by Stroustrup.)

@lightsoff said:

As you can't even work out how many you have without walking the whole list, they are ludicrously slow.

Get a less awful list implementation.

OK, that's a bit , but plenty of linked list implementations explicitly track the size, and it's not hard to do it yourself with a homegrown list.

EvanED

@Bulb said:

It's not a “distinguished end”, it's either head (if the list has a head) or it's the first element again.

"Distinguished head" is probably a better term, but "end" isn't wrong. :-)

EvanED

@Bulb said:

gcc had some ABI transitions too, but it's been quite long since the last one

Two nitpicks.

First, note that there is one going on right now: C++11 mandates some behavior changes that require ABI changes. Now, new features allow that to be applied somewhat on-demand -- a preprocessor macro can control which you get -- but I think it is default with -std=c++11 in the latest GCC version. (I could be wrong.)

Second, while what you say is true for recent versions supporting the API of older versions, at least IME the reverse is not very true. It's extremely easy to write some source file that will compile with an older (4.x) GCC and run on a system with a recent one, but not vice versa.

Gąska

@Bulb said:

On the other hand qsort uses function pointers and is compiled just once and lives in the library. This means it is not available for the compiler for inlining.

Wrong. GCC is able to inline some function pointer calls, eliminating indirection. And I believe Clang and MSVC can do it too.