469,127 Members | 1,371 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,127 developers. It's quick & easy.

enum + long

If I understand well, an enumeration is only garantee to hold at most an
int (6.7.2.2-2). So I would like to know:

how to store a long in an enum?

enum { p2_31 = 1L << 31 };
// boom

how to define a synonym of a constant address?

enum { p = (ptrdiff_t)&address_of_an_unknown_variable };
// boom, ptrdiff_t is generally of type long.

The important aspect is the constness since I would like to use the new
identifier to initialize static data. It is mainly the second case which
interests me, even if both are equivalent.

Note that I cannot use the preprocessor since my problem rises after the
cpp phase. This is why I don't know the variable identifier when I need
to take its address (but I know it when I can define the enum).

Thanks.

a+, ld.
Mar 17 '06 #1
12 2839


Laurent Deniau wrote On 03/17/06 12:25,:
If I understand well, an enumeration is only garantee to hold at most an
int (6.7.2.2-2). So I would like to know:

how to store a long in an enum?

enum { p2_31 = 1L << 31 };
// boom
An enum constant *is* an int, never a long or a short
or an unsigned int or anything else. Therefore, it is not
possible to define an enum constant whose value is less
than INT_MIN or greater than INT_MAX.

Although the enum constants are ints, the enum type
itself can be any kind of integer the compiler chooses
(but it must choose a type that can represent all the
values of the associated constants). Thus, it is just
possible that in

enum { A, B, C } x;

.... `x' might actually be a long, and you might actually
be able to store a long value in it: `x = LONG_MAX'.
However, there is no portable way to discover exactly
what type the compiler selected for `x', hence no way to
predict whether the assignment will work as desired.
how to define a synonym of a constant address?

enum { p = (ptrdiff_t)&address_of_an_unknown_variable };
// boom, ptrdiff_t is generally of type long.
When you specify a value for an enum constant, you must
use a compile-time constant expression. Addresses are not
compile-time constants.
The important aspect is the constness since I would like to use the new
identifier to initialize static data. It is mainly the second case which
interests me, even if both are equivalent.

Note that I cannot use the preprocessor since my problem rises after the
cpp phase. This is why I don't know the variable identifier when I need
to take its address (but I know it when I can define the enum).


"When you define the enum" must be "when you write the
source code," which in turn must be "before the preprocessor
runs," so I do not understand why the preprocessor cannot do
what you want. What, exactly, are you trying to do?

--
Er*********@sun.com

Mar 17 '06 #2
On Friday 17 March 2006 17:25, Laurent Deniau opined (in
<dv**********@sunnews.cern.ch>):
If I understand well, an enumeration is only garantee to hold at most
an int (6.7.2.2-2). So I would like to know:

how to store a long in an enum?
You can't...
enum { p2_31 = 1L << 31 };
// boom

how to define a synonym of a constant address?
I'm not sure I understand this, but it's late in the day...
enum { p = (ptrdiff_t)&address_of_an_unknown_variable };
// boom, ptrdiff_t is generally of type long.

The important aspect is the constness since I would like to use the
new identifier to initialize static data. It is mainly the second case
which interests me,
Why are you insisting on using `enum` for something that, to me, seems
like a constant pointer? Why an array of these, indexed by an `enum`
won't do (if you still insist on using `enum`)?
even if both are equivalent.
They don't look equivalent to me. `ptrdiff_t` is not guaranteed to be
defined as `long`.
Note that I cannot use the preprocessor since my problem rises after
the cpp phase. This is why I don't know the variable identifier when I
need to take its address (but I know it when I can define the enum).

Thanks.

a+, ld.


--
BR, Vladimir

The closest to perfection a person ever comes is when they fill out a
job application.

Mar 17 '06 #3
Eric Sosman wrote:

Laurent Deniau wrote On 03/17/06 12:25,:
If I understand well, an enumeration is only garantee to hold at
most an int (6.7.2.2-2). So I would like to know:

how to store a long in an enum?

enum { p2_31 = 1L << 31 }; // boom

An enum constant *is* an int, never a long or a short or an unsigned
int or anything else. Therefore, it is not possible to define an
enum constant whose value is less than INT_MIN or greater than
INT_MAX.


Yes. This is what I was saying. The example above was the goal
(according to the next point which is my real care), not the way to do it.
how to define a synonym of a constant address?

enum { p = (ptrdiff_t)&address_of_an_unknown_variable }; // boom,
ptrdiff_t is generally of type long.

When you specify a value for an enum constant, you must use a
compile-time constant expression. Addresses are not compile-time
constants.


An enum requires an integral constant expression and the address of a
variable with static storage duration is constant (6.6-9). But it seems
that the conversion to ptrdiff_t break the constness leading to an
invalid expression (i.e. either not constant, either not integral).
Note that I cannot use the preprocessor since my problem rises
after the cpp phase. This is why I don't know the variable
identifier when I need to take its address (but I know it when I
can define the enum).

"When you define the enum" must be "when you write the source code,"
which in turn must be "before the preprocessor runs," so I do not
understand why the preprocessor cannot do what you want. What,
exactly, are you trying to do?


A bit complex to explain here and showing a code sample would need to
introduce about a hundred of macros manipulating list of tokens and
complex code generation.

In the mean time I decided to completely redesign part of the code to
avoid this problem. But I had to use a union and I don't like to (less
elegant).

a+, ld.
Mar 17 '06 #4
Laurent Deniau wrote:

Eric Sosman wrote:

Laurent Deniau wrote On 03/17/06 12:25,: [...]
how to define a synonym of a constant address?

enum { p = (ptrdiff_t)&address_of_an_unknown_variable }; // boom,
ptrdiff_t is generally of type long.

When you specify a value for an enum constant, you must use a
compile-time constant expression. Addresses are not compile-time
constants.


An enum requires an integral constant expression and the address of a
variable with static storage duration is constant (6.6-9). But it seems
that the conversion to ptrdiff_t break the constness leading to an
invalid expression (i.e. either not constant, either not integral).


The address of a variable with static storage is a runtime constant.
An enum requires a compile-time constant.

[...]
--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Mar 18 '06 #5
Kenneth Brody wrote:
Laurent Deniau wrote:
Eric Sosman wrote:
Laurent Deniau wrote On 03/17/06 12:25,:
[...]
how to define a synonym of a constant address?

enum { p = (ptrdiff_t)&address_of_an_unknown_variable }; // boom,
ptrdiff_t is generally of type long.
When you specify a value for an enum constant, you must use a
compile-time constant expression. Addresses are not compile-time
constants.


An enum requires an integral constant expression and the address of a
variable with static storage duration is constant (6.6-9). But it seems
that the conversion to ptrdiff_t break the constness leading to an
invalid expression (i.e. either not constant, either not integral).

The address of a variable with static storage is a runtime constant.
An enum requires a compile-time constant.


I do not catch this point. The terms "runtime constant" or "compile-time
constant" are not part of the norm. Even if I am aware that the address
is computed during the link phase, that is before program runtime but at
a time where the enum does not exist anymore, from the point of view of
the norm I don't see anything which asserts that an address of a
variable with static storage duration is not constant. BTW a such
address is qualified as a "constant address" in the norm and it can be
use to initialize a constant pointer with static storage duration
(6.6-7). In other terms, if the conversion of the constant address into
an integral type would have been the identity, the compiler could have
been able to use the enum as an alias and replace its use by the
corresponding address in the TU. Unfortunately the conversion is not the
identity (my last remark).

a+, ld.
Mar 20 '06 #6
Laurent Deniau wrote:

Kenneth Brody wrote:
Laurent Deniau wrote:
Eric Sosman wrote:

Laurent Deniau wrote On 03/17/06 12:25,:
[...]
>how to define a synonym of a constant address?
>
>enum { p = (ptrdiff_t)&address_of_an_unknown_variable }; // boom,
>ptrdiff_t is generally of type long.
When you specify a value for an enum constant, you must use a
compile-time constant expression. Addresses are not compile-time
constants.

An enum requires an integral constant expression and the address of a
variable with static storage duration is constant (6.6-9). But it seems
that the conversion to ptrdiff_t break the constness leading to an
invalid expression (i.e. either not constant, either not integral).

The address of a variable with static storage is a runtime constant.
An enum requires a compile-time constant.


I do not catch this point. The terms "runtime constant" or "compile-time
constant" are not part of the norm. Even if I am aware that the address
is computed during the link phase, that is before program runtime but at
a time where the enum does not exist anymore, from the point of view of
the norm I don't see anything which asserts that an address of a
variable with static storage duration is not constant.


How about this:

extern int foo;
enum { p = (ptrdiff_t)&foo };
char array[p];
BTW a such
address is qualified as a "constant address" in the norm and it can be
use to initialize a constant pointer with static storage duration
(6.6-7). In other terms, if the conversion of the constant address into
an integral type would have been the identity, the compiler could have
been able to use the enum as an alias and replace its use by the
corresponding address in the TU. Unfortunately the conversion is not the
identity (my last remark).


Suppose that converting an address into an integer causes some sort of
conversion. (One such example would be 16-bit segmented architecture
where pointers are 32 bits, but ints are 16 bits.)

extern int foo, bar;
enum { myfoo = (ptrdiff_t)&myfoo,
mybar = (ptrdiff_t)&bar
} myfoobar;
myfoobar foobar;

...
switch(foobar)
{
case myfoo:
break;
case mybar:
break;
}

What happens in the case where &myfoo and &mybar, when converted to an
int, are identical? Given that this cannot be detected at compile time,
and given that you cannot have identical cases, how would you handle
this?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Mar 20 '06 #7
Kenneth Brody wrote:
How about this:

extern int foo;
enum { p = (ptrdiff_t)&foo };
char array[p];
This is the same point I have shown.
Suppose that converting an address into an integer causes some sort of
conversion. (One such example would be 16-bit segmented architecture
where pointers are 32 bits, but ints are 16 bits.)


Then you are in the case of my example where the conversion is not the
identity. My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at the
beginning of C.

Then:

extern int foo;
enum { p = (intptr_t)(void*)&foo };
static int *const p_foo = (void*)p;

could be equivalent to:

extern int foo;
static int *const p_foo = &foo;

with no loss of information. Note that it is pure speculation, since in
the meantime I changed my design to get rid of this problem.

a+, ld.
Mar 20 '06 #8
Laurent Deniau <la************@cern.ch> wrote in news:dvmscf$ria$1
@sunnews.cern.ch:
My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at the
beginning of C.


Huh? Care to explain what you mean by that?

Sinan

--
A. Sinan Unur <1u**@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
Mar 20 '06 #9
A. Sinan Unur opined:
Laurent Deniau <la************@cern.ch> wrote in news:dvmscf$ria$1
@sunnews.cern.ch:
My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at
the beginning of C.

I must quote the great McEnroe: You cannot be serious!

Huh? Care to explain what you mean by that?

Sinan


--
BR, Vladimir

There was a young lady from Prentice
Who had an affair with a dentist.
To make things easier
He used anesthesia,
And diddled her, `non compos mentis'.

Mar 20 '06 #10
A. Sinan Unur wrote:
Laurent Deniau <la************@cern.ch> wrote in news:dvmscf$ria$1
@sunnews.cern.ch:

My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at the
beginning of C.

Huh? Care to explain what you mean by that?


explain what? about enum or about int?

a+, ld.

Mar 21 '06 #11
Laurent Deniau <la************@cern.ch> wrote in
news:dv**********@sunnews.cern.ch:
A. Sinan Unur wrote:
Laurent Deniau <la************@cern.ch> wrote in news:dvmscf$ria$1
@sunnews.cern.ch:

My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at
the beginning of C.

Huh? Care to explain what you mean by that?


explain what? about enum or about int?


No, the part about either of them being "a word processor".

However, now that I look at this again, I think you meant "processor
word", but I just was not able to grok it the first time I saw your
message.

Sinan
--
A. Sinan Unur <1u**@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
Mar 21 '06 #12
A. Sinan Unur wrote:
Laurent Deniau <la************@cern.ch> wrote in
news:dv**********@sunnews.cern.ch:

A. Sinan Unur wrote:
Laurent Deniau <la************@cern.ch> wrote in news:dvmscf$ria$1
@sunnews.cern.ch:

My question was why an enum is still an int and not something
representing "a word processor" like the int was intended to be at
the beginning of C.
Huh? Care to explain what you mean by that?


explain what? about enum or about int?

No, the part about either of them being "a word processor".

However, now that I look at this again, I think you meant "processor
word", but I just was not able to grok it the first time I saw your
message.


yes sorry, I meant "representing a processor word".

a+, ld.
Mar 21 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by Glenn Venzke | last post: by
2 posts views Thread by Stephan Schulz | last post: by
18 posts views Thread by Nebula | last post: by
21 posts views Thread by Andreas Huber | last post: by
31 posts views Thread by Michael C | last post: by
18 posts views Thread by Visual Systems AB \(Martin Arvidsson\) | last post: by
3 posts views Thread by giant food | last post: by
6 posts views Thread by Michael Isaacs | last post: by
5 posts views Thread by Bill Cunningham | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Mortomer39 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.