"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
"Emil Dotchevski" <emildotchevski@hotmail.com> writes:
Or did I completely misunderstand the documentation? Robert, was the intended meaning that *if* you explicitly call a function from foo.cpp, then using the class export macro guarantees that class foo is properly registered with the serialization library?
My intention is and was that proper registration will occur whether or not the type is explicitly referred to.
"Whether the type is explicitly referred to" is completely irrelevant. The question is whether any objects or functions from the translation unit containing the EXPORT are used. Did you intend that proper registration occur even if no objects or functions from the translation unit containing the EXPORT are used?
That was my goal and I believe it has been achieved for all compilers that boost supports.
I would be very surprised if that were the case for Metrowerks; as pointed out by Emil, that compiler is very good at optimizing out unused translation units.
In order to accomplish this I resorted to compiler specific syntax not described by the standard.
Not for every compiler... and there is no guarantee that the next version of GCC or MSVC won't apply the optimization more aggressively.
Now it seems the question being raised is whether this is/was the right thing to do.
No, I don't think that is the question at all, at least, not mine. My question is what promises you can legitimately make to users about what will happen, and whether you have made your promises sufficiently explicit.
Its not really a C++ question but a more general and interesting one. What is a library writer to do when the language standard conflicts with the way you and/or your target audience want to do things? In some cases, you stick to the standard and suffer some inconvience in order to guarentee portability. In other cases - portability is not a requirement. In this case I "squared the circle" by "solving the issue" for each compiler in a different way so that its "portable" between this subset and still considered convenient.
That's a legitimate thing to do, but I think you need to be very explicit about what you're doing.
That is certainly the only correct way to document it unless we find other means to make that work.
I would say it has been made to work
I would be very surprised. Do any of your tests actually exercise the case where the EXPORT is in a TU with no used functions or objects?
- its just not guarenteed to be portable to new compilers.
Or new versions of existing compilers. -- Dave Abrahams Boost Consulting www.boost-consulting.com