[Ragnarork]

> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.

Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).

And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.

[hmry]

Yeah, it's not a very convincing argument imho. You can write C libraries in C++ or Rust or D or Zig, and people do it all the time.

In fact, some popular C++ libraries don't even have a stable C++ API, only a C API. LLVM comes to mind. DuckDB is another example

[MeetingsBrowser]

> It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface

Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?

I've only seen it done for C++ that is more C than C++, or for libraries that were designed to "bail out" to a C interface.

[Ragnarork]

> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?

If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes.

My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.

But that if you design something from the ground up, then it's rather easy (with a certain set of constraints). My bad for not conveying that better.

[vrighter]

Then the statement "Stuff can't interoperate with c++" is true. Nothing from c++ ever gets exposed. You have to explicitly write a C interface yourself, or avoid using c++ features (write C in c++) so everything looks like C in the first place and all you need is #ifdef __cplusplus extern "C" #endif. But then you're not writing c++ either.

[Ragnarork]

> Then the statement "Stuff can't interoperate with c++" is true

Where is that statement? The statement I reacted to (and with some caveats) was the following: "Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++."

Which in my opinion is not true for the reason I mentioned.

> Nothing from c++ ever gets exposed

Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.

[hmry]

That's definitely true. Can't have generics / compile time evaluation across languages. Need to design your code around that restriction ahead of time. SQLite being dynamically typed luckily doesn't have any problems with that.

I've actually run into a similar problem with a C library before, because it heavily used macros as part of its API. Glad most developers don't do that.

[bluGill]

You lose most of the advantages of C++ if you can't use vector, unique_ptr and the like in your APIs. Classes are also useful for a lot of things.

[Ragnarork]

You do lose the ability to use some features, that's true. Mostly RAII around the interface. You can still leverage it internally in the implementation, and if using context objects it would be even easier. The main pain point is if you want to let client of the library use their own allocators. It's still doable, but quite a pain.

Classes can be wrapped with a bit of effort. You do need to write the constructors and the destructors manually and invoke a pair of new/delete on the C side, but it's just as you would handle a type allocated by a C library itself. You'd use it the same way. You just have the liberty to have the implementation use (mostly) C++.

[hmry]

You can still use them inside your code, just not as arguments or return values from the API.

And it's not like that's a point in favor of C, since C doesn't have vector or unique_ptr either