1) If the INTERFACE provided by the DLL is indeed a C++ interface, then yes, it makes it hard (if not impossible) for other languages to interface with the DLL.
C++ is more complex to interface with than C, because of the more complex structure of classes (this
pointer being passed along, virtual function pointers/VTABLE layout) and exception handling (where the called code has to handle the fact that the exception happened in some way, and to do that, the code needs to be able to "unwind" the call-stack of the code that threw the exception and destroy any objects created on the way until it finds a catch
- if that's not present in the call-stack within the DLL you'll get problems - this unwinding is not part of the C++ standard, because the standard does not wish to restrict which architectures and what features a processor needs/should have to implement C++ more than necessary). Catching exceptions within the DLL will solve issues here.
In other words, if the language is not C++ [and possibly from the same vendor] that is calling the code, there is a need for some handling of the C++ to whatever language is calling it. This can get pretty complicated.
Any C++ object need to be translated from/to the relevant language in the calling code. For basic types in common with C, this is generally not a problem, but classes, structs, etc, will have to be matched up against something compatible in the local language.
On the other hand: A C function is very easy to interface with: put the arguments on the stack, call the function, and clean up the arguments on return. Nothing strange happens, no hidden function parameters, no need to unwind stacks. The only slight complication is functions returning a struct
(that is bigger than a certain size) - but that's a pretty special case in C. C's "objets" are much simpler, and most languages have types that correspond well to the basic C language types (but C style struct
can still cause some interesting problems, and union
can be a real challeng if it's used "cleverly").
2) Choosing languages is a complex business, and it largely depends on how the DLL is supposed to be used or what sort of interface it is supposed to provide, and what interfaces it itself should connect to - if your DLL is interfacing to another C++ DLL (or some other C++ code), then you probably want to use C++. But there are ways to produce a C++ DLL that has a C interface, by using extern "C"
for the interface functions (and ensuring that nothing throws
over the wall to "C", because that will definitely cause problems).
Conclusion:
Obviously, by limiting the interface to "only use C++", then there is a further complication in that anyone using the library from, say, C, Python or Lisp [all of which can probably call C functions fairly easily], that user will have to wrap the C++ code in a C language wrapper. And yes, this can be done, and is used quite regularly when some really good library is available in C++, that someone wants to connect to a language that has a C style interface available. It's pretty much the same solution as the "provide a C to C++ interface within the DLL", except it's not provided by the producer of the DLL.