Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > overload resolution / integral promotion / standard

Reply
Thread Tools

overload resolution / integral promotion / standard

 
 
Alexander Stippler
Guest
Posts: n/a
 
      10-29-2003
Hi,

I have got a question concerning the overload resolution rules of C++ and
enumeration types. The following little test program illustrates the
situation:

enum { red, green, blue };


template <class A, class B>
A
operator+(const A &a, const B& b)
{
return a;
}


int
main()
{
int i = 0;
i = i + green;

return 0;
}


The code does not really make much sense, but illustrates my problem: I
would never have guessed that every compiler I tried uses the template
operator+ instead of a builtin +.
IMO the compiler has to prefer the builtin + according to the standard:

1) both the user-defined + and the builtin + are in the candidate set.
[13.3.1/13.3.2] and [13.6.2/13.6.12].
2) both are viable.
3) but the built-in + is better [13.3.3].

By the way, I have neglected the fact, that the enum is an unnamed type, so
that the compiler should not choose the template version anyway (or should
it?)

Are my considerations wrong or the compilers (gcc3.3, como4.3, icc7.01)?

regards,
alex
 
Reply With Quote
 
 
 
 
Rob Williscroft
Guest
Posts: n/a
 
      10-29-2003
Alexander Stippler wrote in news:(E-Mail Removed)-ulm.de:

> Hi,
>
> I have got a question concerning the overload resolution rules of C++
> and enumeration types. The following little test program illustrates
> the situation:
>
> enum { red, green, blue };
>
>
> template <class A, class B>
> A
>operator+(const A &a, const B& b)
> {
> return a;
> }
>
>
> int
> main()
> {
> int i = 0;
> i = i + green;
>
> return 0;
> }
>
>
> The code does not really make much sense, but illustrates my problem:
> I would never have guessed that every compiler I tried uses the
> template
>operator+ instead of a builtin +.
> IMO the compiler has to prefer the builtin + according to the
> standard:
>
> 1) both the user-defined + and the builtin + are in the candidate set.
> [13.3.1/13.3.2] and [13.6.2/13.6.12].
> 2) both are viable.
> 3) but the built-in + is better [13.3.3].


Well the builtin requires an extra conversion enum to int. Note that
argument conversion sequences are considered before other rules,
for instance the "prefere non-template over template" rule.

>
> By the way, I have neglected the fact, that the enum is an unnamed
> type, so that the compiler should not choose the template version
> anyway (or should it?)
>


I've read this argument before, though I've never read of a compiler
that actually doesn't treat unnamed enum's as though they have a
type-name.

Ok just found one:

enum { red, green, blue };

template <class A, class B>
A operator+(const A &a, const B& b)
{
return a;
}

struct Dumby {};

Dumby operator + ( Dumby const &, int );

int main()
{
Dumby i;
i = i + green;

return 0;
}

"sourceFile.cpp", line 17: error:
a template argument may not reference an unnamed type
i = i + green;
^
The compiler is at http://www.dinkumware.com/exam/dinkumExam.aspx

It gives:

"sourceFile.cpp", line 13: error:
identifier "green" is undefined
i = i + green;
^

for your original code.

I don't know what EDG version this is. So I've now idea if its more
recient than the como compiler you tried.

Clearly the compiler doesn't consider SFINAE to apply, I would
hazard a guess that this is an illegal substitution not a
"Substitution Failure", hence it doesn't select the builtin op +
anyway.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
 
Reply With Quote
 
 
 
 
Rob Williscroft
Guest
Posts: n/a
 
      10-29-2003
Rolf Magnus wrote in news:bno9fc$sf5$07$(E-Mail Removed)-online.com:

>> By the way, I have neglected the fact, that the enum is an unnamed
>> type, so that the compiler should not choose the template version
>> anyway (or should it?)

>
> Why should there be any difference between a named and an unnamed enum
> type?
>


IIUC because it needs a name with external linkage to base the
external-linkage name it's going to give to the instantiated
operator + < A, <unnamed-type> >( A const &, <unnamed-type> const &).

Rob.
--
http://www.victim-prime.dsl.pipex.com/
 
Reply With Quote
 
Alexander Stippler
Guest
Posts: n/a
 
      10-29-2003
Rob Williscroft wrote:


>>
>> enum { red, green, blue };
>>
>>
>> template <class A, class B>
>> A
>>operator+(const A &a, const B& b)
>> {
>> return a;
>> }
>>
>>
>> int
>> main()
>> {
>> int i = 0;
>> i = i + green;
>>
>> return 0;
>> }
>>
>>


>
> Well the builtin requires an extra conversion enum to int. Note that
> argument conversion sequences are considered before other rules,
> for instance the "prefere non-template over template" rule.
>
>>


Your completely right here.
Well,
the standard says: "If a substitution in a template parameter or in the
function type of the function template results in an invalid type, type
deduction fails." A unnamed type is and invalid type, so what?
como emits the error message:
"a template argument may not reference an unnamed type"
So it notices that it is an unnamed type, but it doesn't treat it as invalid
type in template argument deduction. Would it not have to?
intel C++ and gcc choose the template version anyway.

regards,
alex
 
Reply With Quote
 
tom_usenet
Guest
Posts: n/a
 
      10-29-2003
On Wed, 29 Oct 2003 13:58:37 +0100, Alexander Stippler
<(E-Mail Removed)-ulm.de> wrote:

>Well,
>the standard says: "If a substitution in a template parameter or in the
>function type of the function template results in an invalid type, type
>deduction fails." A unnamed type is and invalid type, so what?
>como emits the error message:
>"a template argument may not reference an unnamed type"
>So it notices that it is an unnamed type, but it doesn't treat it as invalid
>type in template argument deduction. Would it not have to?
>intel C++ and gcc choose the template version anyway.


The list of substitutions that cause type deduction to fail are listed
in 14.8.2/2. This one isn't mentioned (using a non-extern type), so
14.8.2/5 applies and I assume it should give an error (as EDG does).

Tom
 
Reply With Quote
 
Alexander Stippler
Guest
Posts: n/a
 
      10-29-2003
tom_usenet wrote:

> On Wed, 29 Oct 2003 13:58:37 +0100, Alexander Stippler
> <(E-Mail Removed)-ulm.de> wrote:
>
>>Well,
>>the standard says: "If a substitution in a template parameter or in the
>>function type of the function template results in an invalid type, type
>>deduction fails." A unnamed type is and invalid type, so what?
>>como emits the error message:
>>"a template argument may not reference an unnamed type"
>>So it notices that it is an unnamed type, but it doesn't treat it as
>>invalid type in template argument deduction. Would it not have to?
>>intel C++ and gcc choose the template version anyway.

>
> The list of substitutions that cause type deduction to fail are listed
> in 14.8.2/2. This one isn't mentioned (using a non-extern type), so
> 14.8.2/5 applies and I assume it should give an error (as EDG does).
>
> Tom


I think the standard is not very precise here. IMO a compiler should not
consider a template function in the given context, since it would have to
instantiate it with an unnamed type, what is not allowed. And the standard
says:

"Template arguments can be deduced in several different contexts, but in
each case a type that is specified in terms of template parameters(call it
P) is compared with an actual type (call it A). and an attempt is made to
find template argument values ( ... ) that will make P, after substitution
of the deduced values (call it the deduced A), compatible with A.
[14.8.2.4] IMO a compiler should therefore not try any unnamed type as
template parameter anyway in this process, since this does not make sense -
they are not allowed. So why try them?
To me - independent of what the standard says - it would make sense to
handle it the way I proposed. What do you think?

regards,
alex
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      10-30-2003
Alexander Stippler wrote:

> Hi,
>
> I have got a question concerning the overload resolution rules of C++
> and enumeration types. The following little test program illustrates
> the situation:
>
> enum { red, green, blue };
>
>
> template <class A, class B>
> A
> operator+(const A &a, const B& b)
> {
> return a;
> }
>
>
> int
> main()
> {
> int i = 0;
> i = i + green;
>
> return 0;
> }
>
>
> The code does not really make much sense, but illustrates my problem:
> I would never have guessed that every compiler I tried uses the
> template operator+ instead of a builtin +.


You can overload operators for enum types just the same as for classes
(13.5p6), so your overloaded template operator gets called for it.

> IMO the compiler has to prefer the builtin + according to the
> standard:
>
> 1) both the user-defined + and the builtin + are in the candidate set.
> [13.3.1/13.3.2] and [13.6.2/13.6.12].
> 2) both are viable.
> 3) but the built-in + is better [13.3.3].
>
> By the way, I have neglected the fact, that the enum is an unnamed
> type, so that the compiler should not choose the template version
> anyway (or should it?)


Why should there be any difference between a named and an unnamed enum
type?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C++ 42 11-04-2008 12:39 PM
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C Programming 45 11-04-2008 12:39 PM
Bit-fields and integral promotion Carsten Hansen C Programming 117 02-08-2005 12:22 AM
Usual arithmetic conversions + integral promotion for short? Niels Dekker (no reply address) C++ 10 05-22-2004 04:09 PM
Question re. integral promotion, signed->unsigned Fred Ma C Programming 9 02-09-2004 03:25 AM



Advertisments