"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