Board index » jbuilder » enum

enum


2005-12-25 04:05:18 AM
jbuilder10
Hello
In JB05 SP4 where do I put in the -source 1.5 to allow compiling simple
enums in jdk1.4? I have 1.5 as a jdk, but I am tageting everything less
than 1.4 in Project|Properties and I still get this error message. I
have been over the faq and searched and cannot see where I can put in or
configure that option. tia.
 
 

Re:enum

cpanon wrote:
Quote
In JB05 SP4 where do I put in the -source 1.5 to allow compiling simple
enums in jdk1.4? I have 1.5 as a jdk, but I am tageting everything less
than 1.4 in Project|Properties and I still get this error message. I
have been over the faq and searched and cannot see where I can put in or
configure that option. tia.
I'm not sure you can do that.
You *could* set (in the Build/Java tab in the Project Properties) that
Language Features are set to v 5.0, but Target VM is v 1.4), but I'm not
sure whether that'll allow Enums to be compiled. Still, no harm in trying.
 

Re:enum

Shankar Unni wrote:
Quote
cpanon wrote:

>In JB05 SP4 where do I put in the -source 1.5 to allow compiling
>simple enums in jdk1.4? I have 1.5 as a jdk, but I am tageting
>everything less than 1.4 in Project|Properties and I still get this
>error message. I have been over the faq and searched and cannot see
>where I can put in or configure that option. tia.


I'm not sure you can do that.

You *could* set (in the Build/Java tab in the Project Properties) that
Language Features are set to v 5.0, but Target VM is v 1.4), but I'm not
sure whether that'll allow Enums to be compiled. Still, no harm in trying.
I'm positive that you can't do it. Enums are one of those changes that
cause the class version to change. There are other 1.5 features (like
Autoboxing) that can be used in older JRE's because they only change the
source code syntax, not the generated bytecodes. But enums are new
bytecodes, so they won't be recognized in older JRE's
So basically, the only way to get enums to work is to have -source 1.5
and -target 1.5
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the
newsgroups and the FAQ-O-Matic before posting your next
question.
Google Advanced Newsgroup Search
www.google.ca/advanced_group_search
Other Newsgroup Searches:
www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
www.visi.com/~gyles19/fom-serve/cache/1.html
 

{smallsort}

Re:enum

I tried this:
enum { minSigned32BitValue= -(__int64)0x80000000 };
but there is an error for "numeric constant too large". The message is
wrong because the value fits within a signed int.
minSigned32BitValue= (int)-(__int64)0x80000000
The above gives no messages.
Fraser.
 

Re:enum

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
Quote
I tried this:
enum { minSigned32BitValue= -(__int64)0x80000000 };
but there is an error for "numeric constant too large". The
The compiler does not check the actual value of the constant,
it is the type of that value itself that triggers the error.
Even this line causes the same error:
enum { a = (__int64) 0 };
The standard says (7.2.5):
The underlying type of an enumeration is an integral type that
can represent all the enumerator values defined in the
enumeration. It is implementation-defined which integral type
is used as the underlying type for an enumeration except that
the underlying type shall not be larger than int unless the
value of an enumerator cannot fit in an int or unsigned int.
The constant-expression that defines the enumerator value
shall be of integral type too (or enumeration type) (7.2.1).
As __int64 is not an standard integral type the compiler seems
to be right.
Vaclav
 

Re:enum

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
Quote
The message is wrong because the value fits within
a signed int.
I forgot to comment on this:
The value DOES NOT fit within a signed int (clip copied from
BCB2007 Watch Window):
Watch Name Value
-(__int64)0x80000000,x 0xFFFFFFFF80000000
An absolute value of the minimal signed int never fits in the
same signed int type (talking about Two's complement integers).
signed char: -128 to 127 (128 out of range)
signed short int: -32768 to 32767 (32768 out of range)
etc.
Vaclav
 

Re:enum

"Vaclav Cechura"
Quote
The compiler does not check the actual value of the constant,
it is the type of that value itself that triggers the error.
The compiler must check the value of the integer literal to decide upon
the smallest possible integer representation and whether it will be
signed.
Fraser.
 

Re:enum

"Vaclav Cechura">
Quote
"Fraser Ross"

>The message is wrong because the value fits within
>a signed int.

I forgot to comment on this:

The value DOES NOT fit within a signed int (clip copied from
BCB2007 Watch Window):
(__int64)0x80000000
This vale is of type __int64. It is then negated to -0x80000000 still
type __int64. That value is the lowest possible value of int which it
is casted to.
Fraser.
 

Re:enum

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
Quote
"Vaclav Cechura"
>The compiler does not check the actual value of the constant,
>it is the type of that value itself that triggers the error.

The compiler must check the value of the integer literal to decide upon
the smallest possible integer representation and whether it will be
signed.
If we talk strictly about the standard, this is true only if
the initializers are of standard integral type, which is not
the case of __int64.
BTW, see my other post. The value does not fit in an int.
Vaclav
 

Re:enum

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
That value is the lowest possible value of int which it
Quote
is casted to.
The point is: it isn't. Lowest possible value of a 32-bit
signed int is -0x7FFFFFFF, and the binary representation of
this number in two's complement code is 0x80000000 (the same as
the binary representation of an usigned int 0x80000000).
The number -0x80000000 is a number that a 32-bit signed int
cannot hold.
Vaclav
 

Re:enum

"Vaclav Cechura"
Quote

"Fraser Ross"
>"Vaclav Cechura"
>>The compiler does not check the actual value of the constant,
>>it is the type of that value itself that triggers the error.
>
>The compiler must check the value of the integer literal to decide
upon
>the smallest possible integer representation and whether it will be
>signed.

If we talk strictly about the standard, this is true only if
the initializers are of standard integral type, which is not
the case of __int64.
I'm not sure if that matters. The type long could be 64 bit.
Quote

BTW, see my other post. The value does not fit in an int.
The value assigned does. Its -0x80000000.
Fraser.
 

Re:enum

"Vaclav Cechura" < XXXX@XXXXX.COM >wrote:
Quote

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
That value is the lowest possible value of int which it
>is casted to.

The point is: it isn't. Lowest possible value of a 32-bit
signed int is -0x7FFFFFFF, and the binary representation of
this number in two's complement code is 0x80000000 (the same as
the binary representation of an usigned int 0x80000000).

The number -0x80000000 is a number that a 32-bit signed int
cannot hold.

Vaclav



Sorry, I must have been blind.
The number -0x80000000 is a number that a 32-bit signed int
definitely CAN hold and it's binary representation in two's
complement code is 0x80000000.
Vaclav
 

Re:enum

"Fraser Ross" < XXXX@XXXXX.COM >wrote:
Quote
I'm not sure if that matters. The type long could be 64 bit.
But as it looks long int is only 32 bits wide in BCB2006.
Quote
The value assigned does. Its -0x80000000.
Yes it is. My mistake. -0x80000000 is represented by 0x80000000
in two's complement.
Vaclav
 

Re:enum

Fraser Ross wrote:
Quote
enum { minSigned32BitValue= -(__int64)0x80000000 };
but there is an error for "numeric constant too large".
Just curious if there is something wrong with this...
enum { minSigned32BitValue= 0x80000000 };
printf( "min int = %i \n", minSigned32BitValue );
Gives -2G.
 

Re:enum

Is it possible to obtain an enum value greater than 0x7FFFFFFF with BCB?
If I try this:
enum { maxUnsigned32BitValue= (unsigned int)0xFFFFFFFF };
__int64 test(maxUnsigned32BitValue);
test is -1.
Fraser.