Can you use a class in C? (opens in new tab)

What you are saying certainly applies neatly to getters and setters, but consider that classes are used for far more complex use cases than as a simple data holder. Indeed, if all you need is to store two integer components, you might not need a class.

Of course, in Smalltalk and it's ilk, you only have objects. So there is no opportunity to access data from within a structure (externally) without passing messages.

If you want to do generic programming, it's much better to write f(a, b) instead of a.f(b).

Suppose I'm writing a generic algorithm that needs some function distance(A a, B b) for generic A and B. Distance is probably a commutative function, why would a.distance(b) be better than b.distance(a)? It's arbitrary.

Secondly, if functions are first-class citizens, and I don't "own" the types A and B, it's much easier to implement distance(A a, B b) myself than it is to extend the types A and B with a member function `distance`.

The best paradigm in programming has to be procedural style. The cleanest code I’ve written and read has always been procedural. I even maintain a monster VBA Word Macro at work and - after some much needed refactoring - its pretty easy to understand (ignoring VBA’s warts).

The flow of logic and dependencies on data is much easier to follow in procedural.

I recently watched a talk on just what precisely Functional Programming is, and the whole time I just thought "wait, doesn't everyone do this? Isn't this just the overwhelmingly obvious way to write code?" Around the same time, I found myself running into some very OO projects, and simply couldn't understand the actual reason for all of the ceremony and ridiculous amounts of encapsulation. And this wasn't in Java, which of course is infamous for its seemingly infinite amount of ceremony -- this was the documentation of a widely-used GUI library for Python.

Like, to my mind, classes are useful when you need to create objects whose values are unknown, i.e. the analogy where the class is a "cookie cutter" which creates the cookies. Classes are perfectly fine for that use-case but by no means should it be that which forms the backbone of your project; my (admittedly limited) view is that stand-alone functions are far and away the lowest-overhead and reliable device for composing parts of a system.

I really get the feeling that OOP is sort of like how synths were in the 80s -- everyone just kinda lost their minds for a second and used them everywhere, whether it made sense for the music or not. But from what I can tell, OOP just isn't really the right paradigm for a whole bunch of projects, and often the design of the code vs the design of the thing feels like ramming a square peg into a round hole.

Edit: all that said, if the above smacks of the Dunning-Krueger effect, I'd love to be made aware of that.

    package hello
    
    type cat int
    
    func greet(c cat) cat {
       return c + 1
    }
    
    type dog string
    
    func greet(d dog) dog { // greet redeclared in this block
       return d + "one"
    }

    package hello
    
    type cat int
    
    func (c cat) greet() cat {
       return c + 1
    }
    
    type dog string
    
    func (d dog) greet() dog {
       return d + "one"
    }

The biggest benefit is the structure, you get an API that can control any aspect of the app out of the box without the need to redeclare stuff.

I am so much used to the idea of swapping out functionality (set of functions and a state). For example, just recently I had to swap out an Excel spreadsheet reader/writer library in Go for performance reasons, and would have bled a lot (due to refactoring) had it not been encapsulated as an interface.

Interfaces are much better. What's the difference? It's this: no inheritance.

Still, with interfaces your complaints remain unsatisfied. But add generic functions and then you can have the mix of OO-like and not-OO-like APIs you have in mind.

Generally true, but not guaranteed by the standard: https://stackoverflow.com/questions/1241205/

Of course the issue for C++, unlike the other examples here, is that it does not have a runtime layer that can be used to bridge the gap. So we either write a wrapper in C++ using extern C, or use a tool to do it.

It seems there was a GSOC effort for SWIG to generate C wrappers for C++ libs but it might not have made it all the way? I don't see C as a target language on SWIG's site.

Still, a bespoke, high level design for the C wrapper is always going to be less painful for the consumer.

    struct Rational2;
    struct Rational2 *make_rational(int,int);

    Rational2 *make_rational(int n,int d){
        return (Rational2 *)new Rational(n,d);
    }

    void del_rational(Rational2 **pp){
        delete (Rational2 *)*pp;
        *pp=nullptr;
    }

    #ifdef __cplusplus
    class Rational { ... };
    #else
    struct Rational;
    typedef struct Rational Rational;
    #endif

(Another suggestion I would have is to bracket the entire header in the ifdef'd extern "C" {...} block, which limits the amount of extra crap you have in the header and per function. I think you can direct clang-format not to indent these blocks.)

I didn't supposed that anything really meaningful can come...

I wonder if placement new would run into the same linker problem that the article mentions -- I'll have to try it at some point :)

I did too, all the way up to (IIRC) 2011. My happiness levels improved when I stopped working on C++ and, for the type of native-code problems that I used C++ for, used plain C instead.

My goal is to ship code, with a trade-off between delivery dates, runtime performance and robustness. As the problem gets more complex, I find that C++ muddies the waters even more, impacting on all three axis' above.