Namespace and Specialization Trouble moving 2.95.2 code to 3.0.
Benjamin Scherrey
scherrey@innoverse.com
Sat Aug 11 11:59:00 GMT 2001
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 10 August 2001 04:00 pm, Phil Edwards wrote:
> On Fri, Aug 10, 2001 at 03:21:38PM -0400, Benjamin Scherrey wrote:
> > It complains that I'm "specializing 'struct std::less<Armour::VHandle<T>
> > >' in different namespace from definition of 'template<class _Tp> struct
> > std::less'.
>
> Yeah... this may be cheesy, and your code may actually be valid -- I have
> not checked the standard -- but you need to reopen the std namespace in
> order for your specialization to show up in the right place. (Maybe that's
> just our implementation, I dunno.)
Phil,
Thanx very much or your help. That got it going. I'm still running into
other issues trying to upgrade code for 3.0 (particularly declaring partially
instantiated template classes as friends, which used to work) but so far I've
been able to address them reasonably well. Requiring reopening of the std
namespace to specialize an implementation seems counter-intuitive at best.
I'm trying to think about how to justify that requirement and my only guess
is that maybe an ambiguity would be formed when its time to resolve the call.
This argument, however, doesn't hold much water in any circumstances I've
been able to think of off hand as standard overloading scope resolution seems
to solve any of these problems. I'd ask the rules lawyers here to consider
this issue and see if the implementation needs fixing as this breaks a lot of
our code. Fortunately the workaround is quite simple but it is messy.
best regards & later,
Ben Scherrey
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQA/AwUBO3V/s2j9nzX41wUgEQI7twCgqQjTgSgOYcTzYL1SB+dFMBnEuaAAoPM8
TddjCXXRzqdmUJwXckiL77cK
=qdtR
-----END PGP SIGNATURE-----
More information about the Gcc
mailing list