Emil Dotchevski wrote:
On Tue, Feb 17, 2009 at 9:43 AM, Sohail Somani <sohail@taggedtype.net> wrote:
Emil Dotchevski wrote:
On Tue, Feb 17, 2009 at 7:27 AM, Sohail Somani <sohail@taggedtype.net> wrote:
Ok, that is a start. Thanks.
Still, why intentionally restrict portability even further when the alternative was not burdensome to begin with? I would have better luck implementing a portable export (the previous version) rather than figuring out hacks for each compiler.
I think the export documentation should be modified to say (in big fat bold letters) that it should not be used in portable code. I think it's better to deprecate BOOST_CLASS_EXPORT altogether. If the new policy is to only support specific compilers for this functionality, I would agree with that.
Header ordering is a problem you can work around and still use the library. Compiler-specific hacks, not really.
I think there is a misunderstanding here.
"Header ordering" doesn't mean that BOOST_CLASS_EXPORT would be portable. The compiler-specific hacks would be necessary no matter what. The BOOST_CLASS_EXPORT problem is that the C++ standard allows the compiler to strip away all of the instantiations it triggers, and good compilers do it. The "hacks" exploit holes in that functionality.
Hmm, yes you are right. I guess the bottom line is that export/base_object is so fragile it is not worth using any more. void_cast_register and register_type it is! Thanks for your comments, it has helped me a lot. -- Sohail Somani http://uint32t.blogspot.com