compilation error

[John Harrison]

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

 

[Jesse Nowells]

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

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

 

[John Harrison]

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

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

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]

Hah, there's your culprit right there. ;-)

The rest of the code was cut and paste, I swear!

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

enum E{ C = 10 };

E operator--( E x ){ return static_cast<E>( x-1 ); }

Essentially I think its complaining that it can't modify the value of the
enum C.

Nope. It complains that enum type doesn't have a decrement operator.

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]

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');
}

It does.

 

[Fraser Ross]

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

Fraser.

 

[Janusz Szpilewski]

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--.

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]

-x is not x-1

E is not necessarily able to hold the value -10.

No it complains about UNARY -.

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

 

[Pete Becker]

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.

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]

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."

--

"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]

--, ++, +=, 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."

OK makes sense, in a twisted kind of way.

john

 

[John Harrison]

Why do you call it twisted?

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]

John Harrison wrote in

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.

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+(myEnum a, myEnum b)
{
int i = (int(a) + int(b)) % int(C + 1);
return myEnum(i);
}

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

myEnum operator++(myEnum &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.