3 ms·

Hang on, from all these comments we are saying that nobody ever does dynamic_cast ???

Asooka 10y ago
dynamic_cast doesn't work across .sofiles loaded with dlopen: https://stackoverflow.com/questions/23383102/dynamic-cast-troubles-over-shared-libraries https://stackoverflow.com/questions/23383102/dynamic-cast-tr... I've seen it first hand crap itself on Mac OS X. The gist of it is that if you have a plugin architecture, you can't pass an object allocated in one plugin to another and have the latter do a dynamic_cast. For the same reason exceptions thrown in a plugin can't be caught in another unless the type is defined in the host binary. I.e. suppose the main application has: class HostException { virtual ~HostException() {} }; class FooInterface { virtual void doBar()=0; }; Then inside plugin A you do try { foo->doBar(); } catch (HostException& ex) { // stuff } where foo was allocated in plugin B. Then, // in plugin B class FooImpl : public FooInterface { virtual void doBar() override; }; class MyException : public HostException { virtual ~MyException() {} }; void FooImpl::doBar() { throw HostException(); // should be just fine throw MyException(); // here be dragons } For that reason in places where we call foreign code that we know could throw we just do a blanket catch(...) and bail out on any exception. Similarly we don't rely on dynamic casts at all anywhere, we use our own type system. The OOP features of C++ are fine for small toy programs but ironically they break when you try to use them for actual large ones that would benefit the most from them. Stick to virtual functions, static and reinterpret casts and nothing else.
- _pmf_ 10y ago
  Microsoft's COM probably exists because of this.
- pjmlp 10y ago
  It works on Windows since the 16 bit days, actually. You just need to declspec(dllexport) the classes, with the caveat that thanks to the lack of standard ABI you need the same compiler on both sides.
  - Asooka 10y ago
    Yes, it does work on Windows. Not anywhere else.
    - pjmlp 10y ago
      Which makes it a compiler issue, not a language one. Then again, most other platforms never were too C++ friendly and rather lean on C. BeOS, Symbian, Genode and Windows are probably the only OSes that give C++ some love.
      - Asooka 10y ago
        It is ultimately a linker issue with how it interacts with the implementation of certain C++ constructs. There is one ABI per platform and deviating from that is more pain than just not using those constructs. And the ABI is so opaque and complicated, and subject to change, other native languages don't have a good interoperability story, so you can't for example link together haskell and C++ like you can C and everything else. Which means you can't gradually migrate away from C++ and keep binary compatibility. Rant over, sorry for that.

dynamic_cast doesn't work across .sofiles loaded with dlopen: https://stackoverflow.com/questions/23383102/dynamic-cast-troubles-over-shared-libraries https://stackoverflow.com/questions/23383102/dynamic-cast-tr... I've seen it first hand crap itself on Mac OS X. The gist of it is that if you have a plugin architecture, you can't pass an object allocated in one plugin to another and have the latter do a dynamic_cast. For the same reason exceptions thrown in a plugin can't be caught in another unless the type is defined in the host binary. I.e. suppose the main application has: class HostException { virtual ~HostException() {} }; class FooInterface { virtual void doBar()=0; }; Then inside plugin A you do try { foo->doBar(); } catch (HostException& ex) { // stuff } where foo was allocated in plugin B. Then, // in plugin B class FooImpl : public FooInterface { virtual void doBar() override; }; class MyException : public HostException { virtual ~MyException() {} }; void FooImpl::doBar() { throw HostException(); // should be just fine throw MyException(); // here be dragons } For that reason in places where we call foreign code that we know could throw we just do a blanket catch(...) and bail out on any exception. Similarly we don't rely on dynamic casts at all anywhere, we use our own type system. The OOP features of C++ are fine for small toy programs but ironically they break when you try to use them for actual large ones that would benefit the most from them. Stick to virtual functions, static and reinterpret casts and nothing else.

_pmf_ 10y ago
Microsoft's COM probably exists because of this.
pjmlp 10y ago
It works on Windows since the 16 bit days, actually. You just need to declspec(dllexport) the classes, with the caveat that thanks to the lack of standard ABI you need the same compiler on both sides.
- Asooka 10y ago
  Yes, it does work on Windows. Not anywhere else.
  - pjmlp 10y ago
    Which makes it a compiler issue, not a language one. Then again, most other platforms never were too C++ friendly and rather lean on C. BeOS, Symbian, Genode and Windows are probably the only OSes that give C++ some love.
    - Asooka 10y ago
      It is ultimately a linker issue with how it interacts with the implementation of certain C++ constructs. There is one ABI per platform and deviating from that is more pain than just not using those constructs. And the ABI is so opaque and complicated, and subject to change, other native languages don't have a good interoperability story, so you can't for example link together haskell and C++ like you can C and everything else. Which means you can't gradually migrate away from C++ and keep binary compatibility. Rant over, sorry for that.