You haven't demonstrated the capability of Generics though (which C doesn't really have, only a minimal version). For this particular example, C++ does function overloading on parameters which C cannot hence you need this silly Generic macro hack, it is not clear how much of a win it is. Reminds of the saying that C is the most dynamic programming language since it has void*

It is much cleaner in C++ where you don't need to declare two separate functions names like you did.

  #include <iostream>
  #include <cmath>

  struct Rectangle {
      double width;
      double height;
  };

  struct Circle {
      double radius;
  };

  double area(const Rectangle& rect) {
      return rect.width * rect.height;
  }

  double area(const Circle& circle) {
      return M_PI * circle.radius * circle.radius;
  }

  int main() {
      Rectangle rect{5.0, 3.0};
      Circle circle{2.5};

      std::cout << "Rectangle area: " << area(rect) << std::endl;
      std::cout << "Circle area: " << area(circle) << std::endl;
      return 0;
  }

Though, bear in mind that _Generic is not generic templating. Highly useful, but it's more of a macro.

You can run into issues with aliased types, or where types of the same size accidentally fall through into the wrong parts of the _Generic selector.

Interestingly though, compatibility in the reverse direction has actually gotten better over time. C99 allows variables to be declared at any point in a function. Before C99, the all variables up front rule used to be the single biggest reason that C-style C++ code wouldn't compile under a C compiler.

Partially, ISO C++ has been updating the underlying C standard library reference, to the extent it is compatible with C++, C++23 refers to C17 and the upcoming C++26 will refer to C23, standard library that is.

However this is exactly the golden example why guest languages never own the platform (in this case UNIX/POSIX/C trio), and eventually the platform and guest always diverge.

Even though both share the same birthplace, as usual adoption takes different routes.

If one never wants to face this, regardless how many pain points the language owning the platform has, sticking to it always wins out in the long run.

I feel like the article is already implying this:

> Despite this, C++ preserves a huge amount of C heritage and many C programs will compile just fine with a C++ compiler

It preserves "a huge amount", not "backwards compatability". "Many" C programs will compile, not "all". Hell, the author didn't even go as far as to say "most".

Also the author says:

> The original version of C++ WAS basically an object oriented version of C ("C with classes") BUT AT THIS POINT it has been around for 40-odd years and so HAS DIVERGED VERY SIGNIFICANTLY

[my emphasis / capitalization]

I'm not sure what point you're making that's not already in the article.

Or "constructor acquires, destructor releases". When I learned about RAII for the first time, its meaning was not clear at all from the phrase "resource acquisition is initialization".

Which is the point. RAII is very much not only used for memory nor construction.

Not saying it is a good term, but we are stuck with it and trying to change it to a better one will only make it worse.

> Next Up: Smart Pointers

> RAII is a powerful technique but what we've seen so far is only a partial solution. Things are (mostly) fine when working with objects but if we want to work with pointers, as in our Rectangle example, then we need to implement custom copy constructors, copy assignment operators, etc. if we want them to be safe. This is true even if we want to store on object on the heap but have a pointer on the stack. In the next post I'll be covering a technique called "smart pointers" that helps address these problems.