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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode