3 ms·

C++ exceptions cannot pass DLL boundaries. Are you sure this isn't just a C++ problem? It's a well known fact that due to name mangling, C++ compiled by differ

C++ exceptions cannot pass DLL boundaries. Are you sure this isn't just a C++ problem? It's a well known fact that due to name mangling, C++ compiled by different compilers (even different versions of the same compiler!) can't always be called.

saurik 14y ago
This is due to the different libraries possibly being compiled against different versions of the C++ standard library or C runtime, and is thereby somewhat relevant to and "caused by" this specific feature (where different libraries can do this in the first place). The same thing could happen if two people, for example, linked against different major versions of an XML parser: they would be unable to share state, as data returned from one library would have been generated with one XML library and then would be modified by another, even though the types matches for the purposes of the C compiler. In practice, different major versions should simply be considered different libraries, and many argue it is an encapsulation mistake to allow your public interface to be bound up with details of the libraries you use; however, this kind of use case is much more likely to either work correctly or fail horribly on Linux, as opposed to ending up in some kind of weird uncanny valley of stability. People then reference C++ with regards to this, because C++ happens to have a library that acts on tons of core data types, and yet by default (you can build setups where this doesn't happen, but it requires coordination over the DLLs you are mingling) compiles trivial parts of the algorithms inlined into your logic (so there isn't even a function boundary at all, much less code that could be shared easily). The result is that if C++ touches your public interface, you are almost certainly, at bare minimum, wanting to share something "simple" like a string or a vector, or alternatively wanted to use exceptions somewhere. You now, however, run into the XML library issue. Some people believe this is simply bad API design (as C++ should be treated as a library to encapsulate), while others believe it is a language deficiency. I argue that to the extent it is the latter you probably do control the DLLs that are acting as a set, and external APIs should operate under the former regime (as yes: you also have to worry about name mangling there, although compilers have gotten very good at that: we now tend to see them as part of the system ABI).

saurik 14y ago

This is due to the different libraries possibly being compiled against different versions of the C++ standard library or C runtime, and is thereby somewhat relevant to and "caused by" this specific feature (where different libraries can do this in the first place). The same thing could happen if two people, for example, linked against different major versions of an XML parser: they would be unable to share state, as data returned from one library would have been generated with one XML library and then would be modified by another, even though the types matches for the purposes of the C compiler. In practice, different major versions should simply be considered different libraries, and many argue it is an encapsulation mistake to allow your public interface to be bound up with details of the libraries you use; however, this kind of use case is much more likely to either work correctly or fail horribly on Linux, as opposed to ending up in some kind of weird uncanny valley of stability. People then reference C++ with regards to this, because C++ happens to have a library that acts on tons of core data types, and yet by default (you can build setups where this doesn't happen, but it requires coordination over the DLLs you are mingling) compiles trivial parts of the algorithms inlined into your logic (so there isn't even a function boundary at all, much less code that could be shared easily). The result is that if C++ touches your public interface, you are almost certainly, at bare minimum, wanting to share something "simple" like a string or a vector, or alternatively wanted to use exceptions somewhere. You now, however, run into the XML library issue. Some people believe this is simply bad API design (as C++ should be treated as a library to encapsulate), while others believe it is a language deficiency. I argue that to the extent it is the latter you probably do control the DLLs that are acting as a set, and external APIs should operate under the former regime (as yes: you also have to worry about name mangling there, although compilers have gotten very good at that: we now tend to see them as part of the system ABI).