> So the language that forces me to do just that for the sake of convenience for the language designer and compiler writers is just plain stupid.

Nothing prevents you from getting the same ABI hiding in C++, but the users of your code will greatly benefit: no possibility of memory leaks, ownership is enforced since copy & move are disabled, etc:

    /// Adder.hpp ///
    struct Adder {
      public:
        Adder(int, int);
        ~Adder(); 
        
        int operator()();

      private:
        struct Impl;
        std::unique_ptr<Impl> impl;
    };

    /// Adder.cpp ///
    struct Adder::Impl { 
        // your private stuff
    };

    Adder::Adder(int x, int y)
      : impl{std::make_unique<Impl>(x, y)} { 
      
    }

    Adder::~Adder() = default; 

    int Adder::operator()() { 
      return impl->stuff * 2;
    }

    /// main.cpp ///

    int main() {
        Adder adder{1, 2};
        return adder();        
    }

    /// your main.c ///

    int main(int argc, char** argv) {
        struct Adder* adder = adder_create(); // must not forget
        adder_setup(adder, 1, 2); // must not forget
        int res = adder_operate(adder); // note how all lines are longer
        adder_delete(adder); // must delete
        return res; // we had to introduce a specific variable just for the sake of keeping the return value else we wouldn't be able to delete
    }

Of course, your code wouldn't pass code review in either cases: introducing indirections through implementation hiding like this kills performance, in C and C++ likewise. And it's not like hiding your stuff in another object file will prevent anyone from knowing your impl... disassembly & code recreation tools are extremely powerfuls nowadays.