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