From: David Abrahams (dave_at_[hidden])
Date: 2006-05-23 07:51:01
"Robert Ramey" <ramey_at_[hidden]> writes:
> can the export.hpp be replaced with something like
> #if msvc 6
> #include old_export.hpp
> ... new code here or new export
> 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