4 ms·

C++ APIs are made far better by templates (and soon concepts), smart pointers, objects, better type checking, etc, not just RAII. C-style APIs really can't com

C++ APIs are made far better by templates (and soon concepts), smart pointers, objects, better type checking, etc, not just RAII. C-style APIs really can't compete, IMO. > Never mind ABI issues. A C ABI is far more brittle than a C++ one.

neutronicus 5y ago
Let's play "who's supposed to call 'free' on this pointer"!!!
- maccard 5y ago
  And which free do you call? Do you call "free", "my_free", "3rdparty_typea_free" or "3rdparty_typeb_free"?
- corysama 5y ago
  This is why I really, really like unique_ptr. You either explicitly take responsibility (and it implicitly gets handled) or you explicitly hand it off.
forrestthewoods 5y ago
Uhhhh no. A C API can called by every language under the sun. C is the lingua franca of computer science. A C++ API can't even be reliably called by other C++ programs. If I produce a shared library with C API it can be used broadly and easily. If I produce a shared library with a C++ it can only be used by C++ programs compiled with precisely the same settings. Providing a C++ API really just means "compile this entire library from source". I do indeed compile a lot of great third-party C++ code from source. That's not always possible or even desirable. If I need to use that code from a different language - for example C# for Unity or matlab for data science - then that C++ API is worthless and needs to be wrapped with a C API. I've recently been integrating some C++ libraries into C++ based Unreal Engine. It's easier to integrate a C API with Unreal C++ than it is to integrate random C++ project with C++ based Unreal. The fact that C++ doesn't have a standard build system doesn't help. Integrating a C++ library to compile from source requires adapting random build system A with your build system B. There's a reason C++ projects love single-header (or single header + single cpp) C++ libraries with no additional dependencies. Because they don't require jumping through a million hoops.
- SubjectToChange 5y ago
  > A C API can called by every language under the sun. And is usually only used as a last resort. I've lost count of the number of libraries reimplemented in different languages just to avoid using a C-style API at all. > C is the lingua franca of computer science. Is it? If you were to randomly draw a developer from the body of working programmers, how confident would you really be that they could competently write a good portable C program, or even write one at all? I certainly wouldn't put any money on it. C++ is the preferred language of web browsers, interpreters, games/game engines, GUIs, heterogeneous programming frameworks, and every relevant C compiler. And to reiterate, a C ABI is inherently more fragile than a C++ ABI simply due to the lack of name mangling, among other things. The fact that platforms choose to never touch their libc doesn't change that. But if you have to maintain a C library you will feel this.
  - AnimalMuppet 5y ago
    > > C is the lingua franca of computer science. > Is it? If you were to randomly draw a developer from the body of working programmers, how confident would you really be that they could competently write a good portable C program, or even write one at all? I certainly wouldn't put any money on it. Perhaps what they meant is more like "C is the lingua franca of linking". CS people or developers may not be great at writing C code, but almost everything can execute it. C++ of course, but also Java and Python. I think even Haskell can call C code, but I'm not certain of that.
- bloodycxx 5y ago
  You can use WASM to integrate C++.
eska 5y ago
As a C programmer I find it really telling when an API is full of smart pointers. It means the heap is completely unmanaged and I have no control over memory allocation. It makes most c++ libraries completely unusable in embedded, high performance, and high reliability environments (all of which don’t randomly allocate memory at random sizes throughout their run time).
- SubjectToChange 5y ago
  > It means the heap is completely unmanaged and I have no control over memory allocation. It really doesn't mean that. But even if it did it'd still be worth it. > It makes most c++ libraries completely unusable in embedded, high performance, and high reliability environments Most libraries are completely unusable in those environments, including most C libraries.

neutronicus 5y ago

Let's play "who's supposed to call 'free' on this pointer"!!!

maccard 5y ago
And which free do you call? Do you call "free", "my_free", "3rdparty_typea_free" or "3rdparty_typeb_free"?
corysama 5y ago
This is why I really, really like unique_ptr. You either explicitly take responsibility (and it implicitly gets handled) or you explicitly hand it off.

forrestthewoods 5y ago

Uhhhh no. A C API can called by every language under the sun. C is the lingua franca of computer science. A C++ API can't even be reliably called by other C++ programs. If I produce a shared library with C API it can be used broadly and easily. If I produce a shared library with a C++ it can only be used by C++ programs compiled with precisely the same settings. Providing a C++ API really just means "compile this entire library from source". I do indeed compile a lot of great third-party C++ code from source. That's not always possible or even desirable. If I need to use that code from a different language - for example C# for Unity or matlab for data science - then that C++ API is worthless and needs to be wrapped with a C API. I've recently been integrating some C++ libraries into C++ based Unreal Engine. It's easier to integrate a C API with Unreal C++ than it is to integrate random C++ project with C++ based Unreal. The fact that C++ doesn't have a standard build system doesn't help. Integrating a C++ library to compile from source requires adapting random build system A with your build system B. There's a reason C++ projects love single-header (or single header + single cpp) C++ libraries with no additional dependencies. Because they don't require jumping through a million hoops.

SubjectToChange 5y ago
> A C API can called by every language under the sun. And is usually only used as a last resort. I've lost count of the number of libraries reimplemented in different languages just to avoid using a C-style API at all. > C is the lingua franca of computer science. Is it? If you were to randomly draw a developer from the body of working programmers, how confident would you really be that they could competently write a good portable C program, or even write one at all? I certainly wouldn't put any money on it. C++ is the preferred language of web browsers, interpreters, games/game engines, GUIs, heterogeneous programming frameworks, and every relevant C compiler. And to reiterate, a C ABI is inherently more fragile than a C++ ABI simply due to the lack of name mangling, among other things. The fact that platforms choose to never touch their libc doesn't change that. But if you have to maintain a C library you will feel this.
- AnimalMuppet 5y ago
  > > C is the lingua franca of computer science. > Is it? If you were to randomly draw a developer from the body of working programmers, how confident would you really be that they could competently write a good portable C program, or even write one at all? I certainly wouldn't put any money on it. Perhaps what they meant is more like "C is the lingua franca of linking". CS people or developers may not be great at writing C code, but almost everything can execute it. C++ of course, but also Java and Python. I think even Haskell can call C code, but I'm not certain of that.
bloodycxx 5y ago
You can use WASM to integrate C++.

eska 5y ago

As a C programmer I find it really telling when an API is full of smart pointers. It means the heap is completely unmanaged and I have no control over memory allocation. It makes most c++ libraries completely unusable in embedded, high performance, and high reliability environments (all of which don’t randomly allocate memory at random sizes throughout their run time).

SubjectToChange 5y ago
> It means the heap is completely unmanaged and I have no control over memory allocation. It really doesn't mean that. But even if it did it'd still be worth it. > It makes most c++ libraries completely unusable in embedded, high performance, and high reliability environments Most libraries are completely unusable in those environments, including most C libraries.