[serialization] vc6 and Header Ordering
Hi Robert, The header ordering issue is solved... except on vc6. Unfortunately the technique depends on instantiating static members of templates with more than two dependent types, which leads ultimately to the same problem described here: http://www.boost.org/libs/serialization/doc/implementation.html#vc6. I've made lots of clever attempts at workarounds, but this compiler bug is etremely stubborn. If you're interested in a fix for the issue that doesn't work on vc6, or if you're ready to drop support for vc6, then I'll proceed. Otherwise, please let me know and I'll check my work in on a branch for posterity. Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com
can the export.hpp be replaced with something like #if msvc 6 #include old_export.hpp #else ... new code here or new export #endif That way vc6 is still supported subject to the header ordering restriction while for other compilers the restriction is eliminated. Since the old code is already written and tested, there is no cost to doing this. It also provides an "escape hatch" should we come upon some other compiler that can't handle the new code. I'll be curious to see how you did this. I did spend a lot of time trying to find a better solution. I'm also curious to see if it solves some code instantiation failures with code warrior. congratulations. Robert Ramey David Abrahams wrote:
Hi Robert,
The header ordering issue is solved... except on vc6. Unfortunately the technique depends on instantiating static members of templates with more than two dependent types, which leads ultimately to the same problem described here: http://www.boost.org/libs/serialization/doc/implementation.html#vc6. I've made lots of clever attempts at workarounds, but this compiler bug is etremely stubborn.
If you're interested in a fix for the issue that doesn't work on vc6, or if you're ready to drop support for vc6, then I'll proceed. Otherwise, please let me know and I'll check my work in on a branch for posterity.
Thanks,
"Robert Ramey" <ramey@rrsd.com> writes:
can the export.hpp be replaced with something like
#if msvc 6 #include old_export.hpp #else ... new code here or new export #endif
That way vc6 is still supported subject to the header ordering restriction while for other compilers the restriction is eliminated.
Yes, that's possible. It leaves an unfortunate quantity of cruft in the code, but what can you do? I guess you could think really hard about dropping vc6 support. I should warn you: supporting broken compilers is an addictive habit that's hard to break. But I've found it's worth breaking in the end ;-)
Since the old code is already written and tested, there is no cost to doing this. It also provides an "escape hatch" should we come upon some other compiler that can't handle the new code.
I'll be curious to see how you did this.
It relies on the fact that the signatures and return types of overloaded function templates need to be instantiated during overload resolution even if they're never called. There's one such overload per archive type, and they are considered each time a class is exported. If the return type of an overloaded function is nested in a class template, that class template gets instantiated during overload resolution, and at that point you have the archive type and the type being exported. There are various ways of tying a class body instantiation to the instantiation of a static data member.
I did spend a lot of time trying to find a better solution. I'm also curious to see if it solves some code instantiation failures with code warrior.
I'll check codewarrior again when I come back to this. I have to spend a few days on other things first. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Robert Ramey" <ramey@rrsd.com> writes:
can the export.hpp be replaced with something like
#if msvc 6 #include old_export.hpp #else ... new code here or new export #endif
That way vc6 is still supported subject to the header ordering restriction while for other compilers the restriction is eliminated.
Yes, that's possible. It leaves an unfortunate quantity of cruft in the code, but what can you do? I guess you could think really hard about dropping vc6 support.
I'm not sure I fully understand what pointer_oserializer et al are up to, but one other possibility here might be to introduce one layer of runtime polymorphism for these cases (maybe just when using vc6)... ...but first, how did you avoid this bug with pointer_oserializer? AFAICT any static member of a template with two parameters is susceptible. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Robert Ramey" <ramey@rrsd.com> writes:
can the export.hpp be replaced with something like
#if msvc 6 #include old_export.hpp #else ... new code here or new export #endif
That way vc6 is still supported subject to the header ordering restriction while for other compilers the restriction is eliminated.
Yes, that's possible. It leaves an unfortunate quantity of cruft in the code, but what can you do? I guess you could think really hard about dropping vc6 support.
I should warn you: supporting broken compilers is an addictive habit that's hard to break. But I've found it's worth breaking in the end ;-)
Fortunately I found a workaround. See my other posting. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams -
Robert Ramey