Re: Why C++ is vastly superior to C

Stefan Ram <ram@zedat.fu-berlin.de> wrote:


  For curiosity I examined how that implementation handles the list
elements.

  Overhead (each element of the list makes two allocations rather than one,
one allocation for the node and another for the user data; also comparison
is done via indirect function calls via function pointers, making them
significantly slower than direct element comparisons) and lack of
type safety (everything is handled through void pointers, making it
impossible for the compiler to catch accidental mistakes in types) is to
be expected from a "generic" C implementation.

  (I have always found it quite ironic that C hackers accuse C++ of
introducing needless overhead, when it's usually the exact opposite,
with C having the needless overhead when compared to the equivalent
C++ implementation, especially when talking about generic containers.)

  The most striking problem, however, is summarized by these lines of
code in the library:

        size_t datalen = l->attrs.meter(data);
        lent->data = (struct list_entry_s *)malloc(datalen);
        memcpy(lent->data, data, datalen);

and:

            if (s->data != NULL) free(s->data);

  The library assumes that it can just make a raw bitwise copy of the
element when it needs to create a new node, and simply free the element
when it removes a node. Well, guess if you can make eg. a list of lists
with this (or, for that matter, have as list element a struct that manages
some resource which needs to be release when the struct instantiation is
destroyed).

  Sure, you could add yet another pair of function pointers to the
list_attributes_s struct (ironically adding yet more overhead that a C++
implementation would not require) for copying and destroying the list
elements. Or the coder who is using the list could make sure that the
elements are being finalized before they are removed from the list
(something that is easily error-prone in complicated programs). However,
I think this is a good representation of the natural kind of thinking in C.
Even in code that's supposed to have high encapsulation, encapsulation is
still being broken.

  And btw, there's an error in the webpage. It says:

  "sorting is always O(n logn), without worst case"

  Seeing that it uses quicksort, that's just not true. (Randomizing the
pivot does not make the worst case scenario any better than with vanilla
quicksort.)