Robert Ramey wrote:
Just to let everyone know:
Between 1.34 and the present export has undergone a lot more that one change. The one's I recall are ( more or less in order)
ehancement to eliminate header order requirement
enhancement to support multi-threading. This required implemenation of a suitable singleton and changing a lot of code to use it.
enhancement to support serialization code dispurseed accross dynamically DLLS.
enhancement to remove dependence on __LINE__ to maintain some unique names.
Can you please describe this further? I thought __LINE__ is the best way to maintain unique names.
clarification in the documentation as to the best way to use export.
And after all there this there is ONLY ONE regression? (maybe two - recently detected).
I hope that I have not come across as saying that I disagree with you there. I am also very pleased that this is the only regression!
So I'm personally very pleased to take credit for all this.
Oh I dunno, Dave had something to do with it ;-)
Note that its not all that easy to detect such regressions from looking at the trunk tests. The table shows as errors such things as usage with libraries which don't support wide characters or don't support spirit. Also some test platforms arn't setup correctly. And often there is a lapse of time between the change is made and when the error shows up. And also results hang around a long time so there is no easy way to see that one has actually fixed something.
Thanks for explaining. The Boost test harness is pretty awesome but part of that awesomeness results in information overload.
So as far as SunCC is concerned: I've reviewed the latest trunk tests and it looks to me that a little effort could resolve the problems with instantiation of extended_type_info for these types. In the worst case, probably a SunCC specific macro could be included. In any case, it'll have to be addressed by someone who has the compiler on hand. I'd would much like to see this looked at. The only other compiler which shows problems is the VACPP and I have it on qt that that maybe on the road to getting addressed as well.
I will be looking at it but if Steven is looking at it, I will lose the race. One thing I was experimenting with was a macro with the explicit purpose of calling some function before main. As you have mentioned, this is not portable but that is the point. So for SunCC it looks something like: #define BOOST_SUNCC_PRAGMA(x) _Pragma(#x) #define BOOST_INIT(function) BOOST_SUNCC_PRAGMA(init(function)) For GCC/Visual C++, the macro expands into a singleton as is currently done with a call to function() in the constructor. Then if you wanted to execute some type-specific code at initialization time, you could modify BOOST_CLASS_EXPORT to do so. So I am thinking something like the following (pretend that names are unique): #define BOOST_CLASS_EXPORT_GUID(T,K) \ namespace \ { \ void register_function() \ { \ singleton<type_info_implementation<T>::type> \ ::get_mutable_instance().key_register(K); \ } \ } \ BOOST_INIT(register_function) BOOST_INIT(x) guarantees that x() is called before main. I believe x must be a vanilla function (not function template) to work portably. The benefit is that there are equivalent attributes for UNIX platforms that *specifically* implement this init behaviour so it is more likely to be portable. I guess this doesn't really solve the problem with SunCC not instantiating ptr_serialization_support::instantiate but atleast has a specific place for porting purposes. Thanks for your time. -- Sohail Somani http://uint32t.blogspot.com