By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,369 Members | 966 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,369 IT Pros & Developers. It's quick & easy.

compilation error

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a


On Tue, 15 Jul 2003, John Harrison wrote:
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()?

Jul 19 '05 #2

P: n/a

"Jesse Nowells" <jn******@transbay.net> wrote in message
news:Pine.BSF.4.31.0307150053130.80673-100000@localhost...


On Tue, 15 Jul 2003, John Harrison wrote:
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
Jul 19 '05 #3

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message
news:3f****************@News.CIS.DFN.DE...
On Tue, 15 Jul 2003 08:03:01 +0100, "John Harrison" <jo*************@hotmail.com> wrote:
Slightly surprised that the following didn't compile

#inclue <algorithm>
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
Jul 19 '05 #4

P: n/a
On Tue, 15 Jul 2003 09:34:34 +0100, "John Harrison" <jo*************@hotmail.com> wrote:
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.

Jul 19 '05 #5

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

Fraser.
Jul 19 '05 #6

P: n/a
John Harrison wrote:

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

Jul 19 '05 #7

P: n/a
On Tue, 15 Jul 2003 09:33:50 -0400, "Ron Natalie" <ro*@sensor.com> wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message news:3f****************@News.CIS.DFN.DE...

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


-x is not x-1

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

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


No it complains about UNARY -.


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

Jul 19 '05 #8

P: n/a
John Harrison wrote:

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
Jul 19 '05 #9

P: n/a
John Harrison wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
John Harrison wrote:

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


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
Jul 19 '05 #10

P: n/a

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
John Harrison wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
John Harrison wrote:
>
> 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 };


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


OK makes sense, in a twisted kind of way.

john
Jul 19 '05 #11

P: n/a

"Pete Becker" <pe********@acm.org> wrote in message
news:3F**************@acm.org...
John Harrison wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
John Harrison wrote:
>
> "Pete Becker" <pe********@acm.org> wrote in message
> news:3F***************@acm.org...
> > John Harrison wrote:
> > >
> > > 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 };
> >
>
> 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."


OK makes sense, in a twisted kind of way.


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
Jul 19 '05 #12

P: n/a
John Harrison wrote in news:bf************@ID-196037.news.uni-berlin.de:
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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 19 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.