compilation error

**Jesse Nowells** · Jul 19 '05, 03:25 PM

Re: compilation error

On Tue, 15 Jul 2003, John Harrison wrote:
[color=blue]
> Slightly surprised that the following didn't compile
>
> #inclue <algorithm>
> enum { C = 10 };
> int main()
> {
> char a[C];
> std::fill_n(a, C, '\0');
> }
>
> Error message points to implementation of std::fill_n and complains that
>
> unary '--' : '' does not define this operator or a conversion to a type
> acceptable to the predefined operator
>
> Essentially I think its complaining that it can't modify the value of the
> enum C.
>
> Is this correct? I expected the template to be instantiated with an int
> which could be modified using operator--.
>
> Replacing enum { C = 10 }; with const int C = 10; does compile.
>
> John
>
>
>[/color]

Your code, as above, compiles, as is, with gcc 3.2.2. Did you use fill()
instead of fill_n()?

**John Harrison** · Jul 19 '05, 03:25 PM

Re: compilation error

"Jesse Nowells" <jnowells@trans bay.net> wrote in message
news:Pine.BSF.4 .31.03071500531 30.80673-100000@localhos t...[color=blue]
>
>
> On Tue, 15 Jul 2003, John Harrison wrote:
>[color=green]
> > Slightly surprised that the following didn't compile
> >
> > #inclue <algorithm>
> > enum { C = 10 };
> > int main()
> > {
> > char a[C];
> > std::fill_n(a, C, '\0');
> > }
> >
> > Error message points to implementation of std::fill_n and complains that
> >
> > unary '--' : '' does not define this operator or a conversion to a type
> > acceptable to the predefined operator
> >
> > Essentially I think its complaining that it can't modify the value of[/color][/color]
the[color=blue][color=green]
> > enum C.
> >
> > Is this correct? I expected the template to be instantiated with an int
> > which could be modified using operator--.
> >
> > Replacing enum { C = 10 }; with const int C = 10; does compile.
> >
> > John
> >
> >
> >[/color]
>
>
> Your code, as above, compiles, as is, with gcc 3.2.2. Did you use fill()
> instead of fill_n()?
>[/color]

No I used code exactly as above, cut and paste from my compiler, except for
#include <algorithm> which I managed to mistype.

Compiler is VC++ .NET

john

**John Harrison** · Jul 19 '05, 03:25 PM

Re: compilation error

"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f13ad69.1 46526000@News.C IS.DFN.DE...[color=blue]
> On Tue, 15 Jul 2003 08:03:01 +0100, "John Harrison"[/color]
<john_andronicu s@hotmail.com> wrote:[color=blue]
>[color=green]
> >Slightly surprised that the following didn't compile
> >
> >#inclue <algorithm>[/color]
>
> Hah, there's your culprit right there. ;-)
>[/color]

The rest of the code was cut and paste, I swear!
[color=blue]
>
>[color=green]
> >enum { C = 10 };
> >int main()
> >{
> > char a[C];
> > std::fill_n(a, C, '\0');
> >}
> >
> >Error message points to implementation of std::fill_n and complains that
> >
> >unary '--' : '' does not define this operator or a conversion to a type
> >acceptable to the predefined operator[/color]
>
>
> enum E{ C = 10 };
>
> E operator--( E x ){ return static_cast<E>( x-1 ); }
>
>
>[color=green]
> >Essentially I think its complaining that it can't modify the value of the
> >enum C.[/color]
>
> Nope. It complains that enum type doesn't have a decrement operator.
>[/color]

So presumably this would also compile (don't have my compiler handy to
check)

enum { C = 10 };
int main()
{
char a[C];
std::fill_n(a, (int)C, '\0');
}

john

**Alf P. Steinbach** · Jul 19 '05, 03:25 PM

Re: compilation error

On Tue, 15 Jul 2003 09:34:34 +0100, "John Harrison" <john_andronicu s@hotmail.com> wrote:
[color=blue]
>So presumably this would also compile (don't have my compiler handy to
>check)
>
>enum { C = 10 };
>int main()
>{
> char a[C];
> std::fill_n(a, (int)C, '\0');
>}[/color]

It does.

**Fraser Ross** · Jul 19 '05, 03:25 PM

Re: compilation error

What happens if the give the enum type a name? This made it fail to compile
with BCB4.

Fraser.

**Janusz Szpilewski** · Jul 19 '05, 03:26 PM

Re: compilation error

John Harrison wrote:
[color=blue]
>
> Essentially I think its complaining that it can't modify the value of the
> enum C.
>
> Is this correct? I expected the template to be instantiated with an int
> which could be modified using operator--.
>[/color]

There is no rule excluding enum types from being the first class
citizens when it comes to instantiation of templates.

There is another issue with calling -- on enum types. According to the
C++ standard (5.3.2) one can call the (built-in) prefix operator ++ or
-- on a operand being an lvalue of an arithmetic or pointer to
completely-defined object type. No enum is mentioned in this context
however it is when i.e., the unary +/- operators are discussed.

Nevertheless many compilers will accept such an operation mainly because
of their own backward compatibility so it may be really hard to spot.

Regards,
Janusz

**Alf P. Steinbach** · Jul 19 '05, 03:26 PM

Re: compilation error

On Tue, 15 Jul 2003 09:33:50 -0400, "Ron Natalie" <ron@sensor.com > wrote:
[color=blue]
>
>"Alf P. Steinbach" <alfps@start.no > wrote in message news:3f13ad69.1 46526000@News.C IS.DFN.DE...
>[color=green]
>>
>> E operator--( E x ){ return static_cast<E>( x-1 ); }[/color]
>
>-x is not x-1
>
>E is not necessarily able to hold the value -10.[color=green]
>>
>> Nope. It complains that enum type doesn't have a decrement operator.
>>[/color]
>
>No it complains about UNARY -.[/color]

Hello? Anyone home today, Ron? Must be the heat.

**Pete Becker** · Jul 19 '05, 03:26 PM

Re: compilation error

John Harrison wrote:[color=blue]
>
> That's very strange because since enums are often used for ordinal types you
> would think that if any arithmetic operators were to be defined then it
> would be ++ and --. Just an oversight I guess.
>[/color]

Nope, deliberate. We didn't want to require compiler writers to generate
increment and decrement code for things like this:

enum flags { 0x01, 0x02, 0x04, 0x08, 0x10 };

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

**Pete Becker** · Jul 19 '05, 03:27 PM

Re: compilation error

John Harrison wrote:[color=blue]
>
> "Pete Becker" <petebecker@acm .org> wrote in message
> news:3F14860D.3 E54FFBA@acm.org ...[color=green]
> > John Harrison wrote:[color=darkred]
> > >
> > > That's very strange because since enums are often used for ordinal types[/color][/color]
> you[color=green][color=darkred]
> > > would think that if any arithmetic operators were to be defined then it
> > > would be ++ and --. Just an oversight I guess.
> > >[/color]
> >
> > Nope, deliberate. We didn't want to require compiler writers to generate
> > increment and decrement code for things like this:
> >
> > enum flags { 0x01, 0x02, 0x04, 0x08, 0x10 };
> >[/color]
>
> OK I can buy that but then why define unary minus?
>[/color]

--, ++, +=, etc. all must create values of the same type as their
operand. Unary minus, as well as the rest of the arithmetic operators,
create integral values. Read about the "usual arithmetic conversions."

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

**John Harrison** · Jul 19 '05, 03:28 PM

Re: compilation error

"Pete Becker" <petebecker@acm .org> wrote in message
news:3F154263.E D9943B8@acm.org ...[color=blue]
> John Harrison wrote:[color=green]
> >
> > "Pete Becker" <petebecker@acm .org> wrote in message
> > news:3F14860D.3 E54FFBA@acm.org ...[color=darkred]
> > > John Harrison wrote:
> > > >
> > > > That's very strange because since enums are often used for ordinal[/color][/color][/color]
types[color=blue][color=green]
> > you[color=darkred]
> > > > would think that if any arithmetic operators were to be defined then[/color][/color][/color]
it[color=blue][color=green][color=darkred]
> > > > would be ++ and --. Just an oversight I guess.
> > > >
> > >
> > > Nope, deliberate. We didn't want to require compiler writers to[/color][/color][/color]
generate[color=blue][color=green][color=darkred]
> > > increment and decrement code for things like this:
> > >
> > > enum flags { 0x01, 0x02, 0x04, 0x08, 0x10 };
> > >[/color]
> >
> > OK I can buy that but then why define unary minus?
> >[/color]
>
> --, ++, +=, etc. all must create values of the same type as their
> operand. Unary minus, as well as the rest of the arithmetic operators,
> create integral values. Read about the "usual arithmetic conversions."
>[/color]

OK makes sense, in a twisted kind of way.

john

**John Harrison** · Jul 19 '05, 03:28 PM

Re: compilation error

"Pete Becker" <petebecker@acm .org> wrote in message
news:3F15A306.5 17E614@acm.org. ..[color=blue]
> John Harrison wrote:[color=green]
> >
> > "Pete Becker" <petebecker@acm .org> wrote in message
> > news:3F154263.E D9943B8@acm.org ...[color=darkred]
> > > John Harrison wrote:
> > > >
> > > > "Pete Becker" <petebecker@acm .org> wrote in message
> > > > news:3F14860D.3 E54FFBA@acm.org ...
> > > > > John Harrison wrote:
> > > > > >
> > > > > > That's very strange because since enums are often used for[/color][/color][/color]
ordinal[color=blue][color=green]
> > types[color=darkred]
> > > > you
> > > > > > would think that if any arithmetic operators were to be defined[/color][/color][/color]
then[color=blue][color=green]
> > it[color=darkred]
> > > > > > would be ++ and --. Just an oversight I guess.
> > > > > >
> > > > >
> > > > > Nope, deliberate. We didn't want to require compiler writers to[/color]
> > generate[color=darkred]
> > > > > increment and decrement code for things like this:
> > > > >
> > > > > enum flags { 0x01, 0x02, 0x04, 0x08, 0x10 };
> > > > >
> > > >
> > > > OK I can buy that but then why define unary minus?
> > > >
> > >
> > > --, ++, +=, etc. all must create values of the same type as their
> > > operand. Unary minus, as well as the rest of the arithmetic operators,
> > > create integral values. Read about the "usual arithmetic conversions."
> > >[/color]
> >
> > OK makes sense, in a twisted kind of way.
> >[/color]
>
> Why do you call it twisted?
>[/color]

Your explanation makes perfect sense, and the current situation is not an
oversight at all (as I impudentally suggested) but a result of careful
consideration by the standard committee.

Nevertheless, from my point of view, it's still the case that the two
operators that it would make most sense for the standard to define behaviour
for (operator++ and operator--) have no behaviour defined. While operators
which are pretty meaningless for enum do have behaviour defined.

john

**Rob Williscroft** · Jul 19 '05, 03:28 PM

Re: compilation error

John Harrison wrote in news:bf48je$avr n1$1@ID-196037.news.uni-berlin.de:
[color=blue]
> Your explanation makes perfect sense, and the current situation is not
> an oversight at all (as I impudentally suggested) but a result of
> careful consideration by the standard committee.
>
> Nevertheless, from my point of view, it's still the case that the two
> operators that it would make most sense for the standard to define
> behaviour for (operator++ and operator--) have no behaviour defined.
> While operators which are pretty meaningless for enum do have
> behaviour defined.
>[/color]

If the behaviour was defined, like it is for int say, you couldn't
do this:

#include <iostream>
#include <ostream>

enum myEnum
{
A, B, C
};

myEnum operator+(myEnu m a, myEnum b)
{
int i = (int(a) + int(b)) % int(C + 1);
return myEnum(i);
}

myEnum &operator++(myE num &a)
{
int i = (int(a) + 1) % int(C + 1);
a = myEnum(i);
return a;
}

myEnum operator++(myEn um &a, int)
{
int i = (int(a) + 1) % int(C + 1);
myEnum b = a;
a = myEnum(i);
return b;
}

int main()
{
myEnum a, b, e;
a = B;
b = C;
e = a + b;

std::cout << int(e) << std::endl;

std::cout << int(++e) << std::endl;

std::cout << int(e++) << std::endl;

std::cout << int(e) << std::endl;

}

Rob.
--

http://www.victim-prime.dsl.pipex.com/

compilation error

compilation error

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment