Hacker News Reader

Comment by rini17 | Hacker News Reader

There are other OOP paradigms, no need to force 'this' pointers on everyone like C++ does. Both 2 and 3 could be done with semantic-aware macros instead.

View on HN

I believe the C++ way would be the right thing for C. Note that this does not mean in any way to inherit all the stuff from C++, nor even constructors and stuff like that. Simply a way to avoid doing this:

    list_add(&mylist,1);

But instead:

    mylist->add(1);

Note that doing this is not an option:

    mylist->class->add(&mylist,1);

It's not just ugly (even if often used), but also uses an additional pointer, which in some application (like Redis) is a no-go because of memory usage.

Maybe you would like UFCS: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

e.g. Nim has it, and it lets you do this:

  proc add(self: MyList, e: int) =
    # [insert append code here]

  mylist.add(1) # equivalent to
  add(mylist, 1)

Though I'm not sure how well it would work with C, considering it lacks function overloading.

Perhaps, though I think one should be careful, as reproducing C++ in this fashion runs awfully close to reproducing what I see as C++'s largest sin...

Let me explain, I feel iteration speed is of utmost importance. So C++'s mistake of mixing interface and implementation (data layout specifically) leads to massive include bloat, and ultimately contributes significantly to the compilation time problem in C++. In contrast, in C, functions are almost entirely decoupled from structure data layout, and implementation, this promoting much more svelte headers and reduced compilation time for many projects.

So, IMO, it would be important to seperate object interface, from the layout, or risk a major, if not the most major, advantage of using C over C++

Reply on news.ycombinator.com