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. That was my goal and I believe it has been achieved for all compilers that boost supports. In order to accomplish this I resorted to compiler specific syntax not described by the standard. Now it seems the question being raised is whether this is/was the right thing to do. For me the answer was easy. The comments in the first review made it clear that this was a feature considered necessary by a significant number of users. Given that I had set the goal of getting this library into boost, I felt I had to find a way to do it. This is re-inforced by my feeling that using the export macro is the way that most users prefer to address this issue. This permits better scalabilty and automatic registration of those and only those types included. So the question is - what do you tell those users who want this? 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. Was this the wroing decision? Should I have tried harder to say - You shouldn't want that facility because it's not going to be guareteed to be portable. I tried that and it didn't fly. Writing a library that hopes to become the most widely used in its class is about a lot more than adhering to the standard. This is reflected in some aspects of the serialization library. I would wager that this is not the only one that has done this.
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 - its just not guarenteed to be portable to new compilers. Robert Ramey