#define constants

I

Ioannis Vranos

I think I read somewhere that #define constants in the style


#define SOMETHING 6


are evaluated to long or unsigned long, depending on the situation and
not int.
 
I

Ioannis Vranos

Ioannis said:
I think I read somewhere that #define constants in the style


#define SOMETHING 6


are evaluated to long or unsigned long, depending on the situation and
not int.


.... Is that true?
 
V

Victor Bazarov

Ioannis said:
... Is that true?

I don't know whether it's true that you read that nonsense somewhere
or whether you dreamed it. I know that an integral literal has the
type 'int' if it fits in it, and if it doesn't, it has type long int,
unless overridden by a suffix (absent in your example). This all is
defined in [lex.icon]/2.

V
 
I

Ioannis Vranos

Victor said:
Ioannis said:
... Is that true?

I don't know whether it's true that you read that nonsense somewhere
or whether you dreamed it. I know that an integral literal has the
type 'int' if it fits in it, and if it doesn't, it has type long int,
unless overridden by a suffix (absent in your example). This all is
defined in [lex.icon]/2.


My mistake. It is about the "identifier" of the macro expressions

defined identifier

and

defined ( identifier)


Errata for K&R2 page 232 (from
http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\


232(§A12.5): The result of the defined operator is not replaced
literally by 0L or 1L, nor are undefined names literally by 0L, but just
by plain 0 or 1. However, the constant expression is nevertheless
evaluated as if these and other constants appearing have long or
unsigned long type.
 
I

Ioannis Vranos

Ioannis said:
Victor said:
Ioannis said:
Ioannis Vranos wrote:
I think I read somewhere that #define constants in the style


#define SOMETHING 6


are evaluated to long or unsigned long, depending on the situation
and not int.
... Is that true?
I don't know whether it's true that you read that nonsense somewhere
or whether you dreamed it. I know that an integral literal has the
type 'int' if it fits in it, and if it doesn't, it has type long int,
unless overridden by a suffix (absent in your example). This all is
defined in [lex.icon]/2.


My mistake. It is about the "identifier" of the macro expressions

defined identifier

and

defined ( identifier)


Errata for K&R2 page 232 (from
http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\


232(§A12.5): The result of the defined operator is not replaced
literally by 0L or 1L, nor are undefined names literally by 0L, but just
by plain 0 or 1. However, the constant expression is nevertheless
evaluated as if these and other constants appearing have long or
unsigned long type.


The fact that the "identifier" in a "defined" preprocessor statement is
evaluated as long or unsigned long, doesn't it imply that this
identifier which was defined with #define" preprocessor statement is
evaluated as long or unsigned long everywhere?
 
I

Ioannis Vranos

Ioannis said:
Ioannis said:
Victor said:
Ioannis Vranos wrote:
Ioannis Vranos wrote:
I think I read somewhere that #define constants in the style


#define SOMETHING 6


are evaluated to long or unsigned long, depending on the situation
and not int.
... Is that true?
I don't know whether it's true that you read that nonsense somewhere
or whether you dreamed it. I know that an integral literal has the
type 'int' if it fits in it, and if it doesn't, it has type long int,
unless overridden by a suffix (absent in your example). This all is
defined in [lex.icon]/2.

My mistake. It is about the "identifier" of the macro expressions

defined identifier

and

defined ( identifier)


Errata for K&R2 page 232 (from
http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\


232(§A12.5): The result of the defined operator is not replaced
literally by 0L or 1L, nor are undefined names literally by 0L, but just
by plain 0 or 1. However, the constant expression is nevertheless
evaluated as if these and other constants appearing have long or
unsigned long type.


The fact that the "identifier" in a "defined" preprocessor statement is
evaluated as long or unsigned long, doesn't it imply that this
identifier which was defined with #define" preprocessor statement is
evaluated as long or unsigned long everywhere?


My mistake again, the _result_ of the defined operator is replaced by 0
or 1 which are evaluated as 0L and 1L. Strange stuff.
 
I

Ioannis Vranos

OK, lets get it from the start again:


Errata for K&R2 page 232 (from
http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html):\


232(§A12.5): The result of the defined operator is not replaced
literally by 0L or 1L, nor are undefined names literally by 0L, but just
by plain 0 or 1. However, the constant expression is nevertheless
evaluated as if these and *other constants* appearing have long or
unsigned long type.


When it mentions "these and other constants", what are the other
constants implied?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top