C++Talk.NET Forum Index C++Talk.NET
C++ language newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The Barton Nackmaniac, or our dearly departed friend name in

 
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated)
View previous topic :: View next topic  
Author Message
Glen Low
Guest





PostPosted: Sat Aug 07, 2004 9:34 am    Post subject: The Barton Nackmaniac, or our dearly departed friend name in Reply with quote



OK folks, am trying to get my head around the Barton Nackman trick,
friend name injection and vagaries of compiler implementation...

Unless I'm hallucinating, gcc (up to 3.3) doesn't implement the
Standard C++ friend name injection rules (while Comceau and VC++ 7.1
appear to)? (How about Metrowerks and IBM XLC++?)

The following code needs to work correctly on both gcc and more
conforming compilers:

template <typename T> struct Z
{
};

template <typename T> struct A
{
A (Z <T>) { ... }

friend A operator+ (A, A) { ... }
};

The main reasoning behind the B-N-like friend operator is so that you
can mix and match A <T> and Z <T>, which you can't do if operator+
were a function template.

I want the following behavior:

A <int> a;
Z <int> z;
a + a; // OK
a + z; // OK
z + a; // OK
z + z; // not OK

.... which is the expected, correct behavior with conforming compilers,
which find operator+ through ADL.

However since gcc injects the friend at the point of instantiation,
you get the following inconsistent, incorrect results:

Z <int> z;
z + z; // error
A <int> a;

Z <int> z;
A <int> a;
z + z; // not an error, found the injected friend after A <int> is
instantiated.

How do I fix this, short of changing my compiler or declaring
operator+ as a set of function templates?

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Back to top
Carl Barron
Guest





PostPosted: Sun Aug 08, 2004 10:07 am    Post subject: Re: The Barton Nackmaniac, or our dearly departed friend nam Reply with quote



In article <9215d7ac.0408062308.47a24a52 (AT) posting (DOT) google.com>, Glen Low
<glenlow (AT) pixelglow (DOT) com> wrote:

Quote:
OK folks, am trying to get my head around the Barton Nackman trick,
friend name injection and vagaries of compiler implementation...

Unless I'm hallucinating, gcc (up to 3.3) doesn't implement the
Standard C++ friend name injection rules (while Comceau and VC++ 7.1
appear to)? (How about Metrowerks and IBM XLC++?)
this code compiles with Metrowerks 9.2


template <typename T> struct Z{};

template <typename T> struct A
{
A(Z<T>){}
A(){}
friend A operator + (A,A) {return A();}
};

void test()
{
A<int> a;
Z<int> z;
a+a;
a+z;
z+a;
z+z;
}

add a default constructor for A. but otherwise it compiles without any
warnings or errors.

note that I see no probelm with z+z since each z is converted to an
A<T> with only one conversion so I see failure as non compliance.
only one conversion per argument is needed here. I could be wrong.'

--

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Glen Low
Guest





PostPosted: Mon Aug 09, 2004 9:28 am    Post subject: Re: The Barton Nackmaniac, or our dearly departed friend nam Reply with quote



Quote:
void test()
{
A<int> a;
Z<int> z;
a+a;
a+z;
z+a;
z+z;
}

add a default constructor for A. but otherwise it compiles without any
warnings or errors.

note that I see no probelm with z+z since each z is converted to an
A<T> with only one conversion so I see failure as non compliance.
only one conversion per argument is needed here. I could be wrong.'

IMHO the reason why z+z should not work is ADL. When interpreting z+z
it looks for operator+ in the associated classes of Z<int>, and since
A<int> is not a superclass it won't find operator+ and thus fail to
compile. On the other hand, a+a, a+z and z+a all have A<int> as one
the parameters so it will find operator+, notice it is not a function
template and proceeed to convert any Z<int> into A<int>.

The acid test to see if Metrowerks behaves like gcc (i.e. injecting
friends at template instantiation rather than depending on ADL) would
be:

void test1 ()
{
A <int> a;
Z <int> z;
z + z; // if this fails, it is standard-conforming; if this passes, it
is like gcc
}

Another example that's probably closer to the code I use is:

template <typename T> struct A
{
A () { ... }
A (T) { ... }

friend A operator+ (A, A) { ... }
};

void test ()
{
A <Z> a;
Z z;
a + a;
z + z; // what happens here?
}

The additional issue behind this code is that T could be an inbuilt
type without an operator+ itself.

The behavior of the conversion and interaction with operator should
work "just like" std::string and std::complex with respect to their
underlying raw data types.

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Glen Low
Guest





PostPosted: Mon Aug 09, 2004 9:29 am    Post subject: Re: The Barton Nackmaniac, or our dearly departed friend nam Reply with quote

Quote:
void test()
{
A<int> a;
Z<int> z;
a+a;
a+z;
z+a;
z+z;
}

Sorry posted too quickly, the acid test should be:

#ifdef A

void test1 ()
{
A <int> a;
Z <int> z;
z + z; // #1
}

#else

void test2 ()
{
Z <int> z;
z + z; // #2
}

#endif

If the implementation is standard conforming, both #1 and #2 should
fail. If the implementation has gcc-like friend injection, then #1
should pass but #2 should fail. Any else is, um, "implementation
defined".

And my problem is I need to get #1 to fail on an implementation where
#1 passes. *grumble*

Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Shaun Joseph
Guest





PostPosted: Wed Aug 25, 2004 11:47 am    Post subject: Re: The Barton Nackmaniac, or our dearly departed friend nam Reply with quote

[email]glenlow (AT) pixelglow (DOT) com[/email] (Glen Low) wrote in message news:<9215d7ac.0408081638.2314e6ea (AT) posting (DOT) google.com>...
Quote:
Sorry posted too quickly, the acid test should be:

#ifdef A

void test1 ()
{
A <int> a;
Z <int> z;
z + z; // #1
}

#else

void test2 ()
{
Z <int> z;
z + z; // #2
}

#endif

If the implementation is standard conforming, both #1 and #2 should
fail. If the implementation has gcc-like friend injection, then #1
should pass but #2 should fail.

Right. You guessed correctly that gcc gets this wrong; it uses the old
rules that inject the friend name unconditionally on instantiation.
Check out the bug report:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7874

Looks like the fix is targeted for 3.5.

Quote:
And my problem is I need to get #1 to fail on an implementation where
#1 passes. *grumble*

You know, this might be completely wacky, but you could just throw in
an uncompilable catch-all function template to prevent the implicit
conversion from Z<T> to A<T>. For instance:

template <typename X> X operator+(X,X) { sizeof(void); }

That would cause #1 and #2 to fail, since overload resolution would
prefer the function template instantiation over implicit conversion.
On the other hand, all the calls with at least one A<T> argument would
correctly resolve to the function injected via A<T> (if both arguments
have type A<T>, overload resolution prefers the non-template "prefect
match"; if only one is A<T>, template argument deduction can't match
it to the template pattern anyway, so you get the non-template as
well).

It seems horrible to introduce a catch-all function template for an
operator into the global namespace, but I guess it can't hurt since
it'll always break your compile if you select it anyway Smile. This might
be more a "trick" than a solution...

Good luck,
Shaun

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Back to top
Display posts from previous:   
Post new topic   Reply to topic    C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.