How does BOOST_CLASS_EXPORT help me if I have my own archive serializer? Even if I'm using one of the archives the library provides for me, I think that it is unreasonable to automatically register all combinations of archivers and types because it introduces physical coupling between translation units which don't depend on each other (in a program where only one archive type is used, which is typical.)
All combinations of A and T actually used - and only those combinations - are used to instantiate code. That is, there is not dead code generated all required code IS instantiated. Daves implementation of this facility (unlike my previous one) does NOT depend on knowing in advance which archives classes might be used. It just works.
For a combination of A and T to work, you need to turn an instantiation of a << template to a boost::function call (or something similar) that doesn't use templates. Are you saying that this instantiation is somehow postponed until actually used? If not, this is code that might not be called, and in my opinion the fact that it is instantiated is a problem.
So the extended type info table has to be initialized with all the types that might be in the archive. This is what export attempts to do.
It doesn't do enough, and there is no portable thing it can do that would be enough.
Hmmm - well it does work. But I DID have to include "_export" - non portable construct to make it work - that is the function of the "force_include.hpp" header.
It does work until it doesn't. In several projects I have worked on, I have seen similar systems relying on "auto registration" to fail due to seemingly unrelated changes in the code base, or when the code is ported to another operating system or platform. The only compiler I have observed to not deadstrip such code consistently is MSVC.
That's what I found when I tested it. I addressed it in the only way I could figure out how to do it. Now it turns out that its not portable according to the standard - and can't be made so. So you have two choices - use an alternate facility (explicit registration) which is provided or not.
The serialization library provides a feature which leads to writing more non-portable code. I do want compilers to deadstrip such global objects because it makes sense and because the standard allows it. I wouldn't care if it was just any other library we're talking about; but a boost library is rather influential and should encourage portability, not the other way around.
I still think that whether it works or not is irrelevant if the documented behavior can not be delivered within the limits of the C++ standard. In my mind it only works because the compiler is not smart enough.
I don't think it is a good idea to rely on implementation-defined behavior.
Not everyone shares that opinion. For example, anyone using dynamic loading of DLLS can't be sharing that opinion.
Dynamic loading of DLLs is in fact one of the reasons why the standard does not require that initialization of global objects must be done at startup. Note also that DLLs require specific, well documented support from the compiler. The behavior the auto-registration uses is a failure to remove dead code. I hope you agree that there is a difference.
In my opinion the "auto registration" should be removed from the serialization library altogether, and replaced with an example demonstrating how it could be done, provided that your compiler doesn't dead strip this kind of code even though it is allowed to.
LOL - remember the only reason EXPORT is even in there is because it's absense was considered a "show stopper" to getting the library approved. So your idea is wildly unrealistic.
I don't remember as I was not part of that discussion. :) Are you suggesting that once a feature is added to a (boost) library, it is unreasonable for someone to argue against it?
Of course there's nothing to prevent you from stripping the EXPORT functionality from your own copy. But then, that would be the same as just not using it. So it's wierd to me that you think we should prohibit other users for using parts of the library for things that the C++ doesn't address. How does this prevent you from using the library in the way you feel is appropriate?
It's not about my own copy and whether or not I would use auto registration, rest assured that I wont. :) The only reason why I pointed out this problem a few weeks ago is that I wanted to share my own experience and opinion. I used to use auto registration in several projects I worked on. I have to admit, every time auto registration broke, I was able to fix it, at least temporarily. Eventually I got tired of it and I recognized that my efforts were misguided. We should help compilers remove dead code, not try to prevent them from doing it!