E. Gladyshev wrote: > --- Edward Diener <[EMAIL PROTECTED]> wrote: >> Exporting/importing C++ classes is completely >> implementation dependent, due >> mainly to name mangling, and requires a DLL for a >> particular >> platform/compiler/release to be built. > > There are several issues with DLL and C++, to name > few: > 1. Name mangling > 2. Using inline methods in the exported class. > 3. Global class instanses in the DLL. > > How does boost ensure that inline methods don't > conflict with the exported methods. The conflict can > be platform specific. > > Is it allowed to have global instances of a class in > boost's DLLs? > > Are there any development policies on how exported C++ > classes should be implemented/tested in boost?
Good questions, but as I have never attempted to export classes with inline methods or have global instances of classes in a DLL in my own non-Boost work, Boost implementors will have to answer you on these items. I admit that I have stayed away from "inline" in my career, and no doubt I will soon be castigated by all those who will tell me why "inline" speeds up code execution. As for global objects, like many C++ programmers I use them as little as necessary, and would never think to export a global object itself as opposed to class definitions and their member functions. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
