Interesting features of #define and typedef, correct me if I am wrong

[fdmfdmfdm]

Look at these two codes:

===================================
#define int_ptr int*
int_ptr a, b;
===================================

and

===================================
typedef int* int_ptr
int_ptr a, b;
===================================

In first example, only a is a pointer-to-an-integer but b is an
integer.

At second example, both of a, b are pointer-to-an-integer.

Do you guys concur with me?

 

[Malcolm McLean]

Look at these two codes:

===================================
#define int_ptr int*
int_ptr a, b;
===================================

and

===================================
typedef int* int_ptr
int_ptr a, b;
===================================

In first example, only a is a pointer-to-an-integer but b is an
integer.

At second example, both of a, b are pointer-to-an-integer.

Do you guys concur with me?

That's one of the reasons you need typedef. The syntax for declaring
pointers is a bit unusual, though it makes sense in a formal grammary sort
of way.

 

[Ian Collins]

That's one of the reasons you need typedef. The syntax for declaring
pointers is a bit unusual, though it makes sense in a formal grammary sort
of way.

It's also a good reason for not declaring more than one variable per line.

 

[Lane Straatman]

[OP]

That's one of the reasons you need typedef. The syntax for declaring
pointers is a bit unusual, though it makes sense in a formal grammary
sort
of way.

It's also a good reason for not declaring more than one variable per line.

This post is typical of a variety that I don't really understand. It uses
the idioms of C to do things that are ill-advised. Why? Because it's
unclear and unnecessary. With preprocessor stuff and type definitions, the
world is a better place when whitespace and carriage return delimit the
statements liberally. What makes a #define statement interesting is the
content of what is being defined, not the statement itself. LS

 

[Christopher Layne]

===================================
#define int_ptr int*
int_ptr a, b;
===================================

and

===================================
typedef int* int_ptr
int_ptr a, b;
===================================

In first example, only a is a pointer-to-an-integer but b is an
integer.

At second example, both of a, b are pointer-to-an-integer.

The base type is int. The '*' denotes the identifier as being a pointer to
that base type.

You're operating from the paradigm that the base type is pointer-to-int, which
it isn't - it's int.

 

[Richard Heathfield]

(e-mail address removed) said:

Look at these two codes:

===================================
#define int_ptr int*
int_ptr a, b;
===================================

and

===================================
typedef int* int_ptr
int_ptr a, b;
===================================

In first example, only a is a pointer-to-an-integer but b is an
integer.

At second example, both of a, b are pointer-to-an-integer.

Do you guys concur with me?

I don't understand why you think it's interesting.

 

[Nishu]

I don't understand why you think it's interesting.

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

Thanks,
Nishu

 

[Richard Heathfield]

Nishu said:

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

It depends on what you mean by code size. You might conceivably mean the
source code, in which case of course they both increase it, just as any
language construct does, including whitespace.

But if you mean the object code, then no, it isn't true. For one thing,
typedefs needn't increase code size. For another, #defines definitely can.
Thirdly, #defines are not the preprocessor. They are merely expanded by the
preprocessor. "Expanded" should give you an extra clue here.

 

[Keith Thompson]

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

No. A typedef merely creates an alias for an existing type. It's a
notational convenience. I can't think of any reason why it would
increase code size. If you can explain what you mean (increase code
size compared to what?), perhaps we can explain further.

 

[Nishu]

[...]

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

No. A typedef merely creates an alias for an existing type. It's a
notational convenience. I can't think of any reason why it would
increase code size. If you can explain what you mean (increase code
size compared to what?), perhaps we can explain further.

By increase in code size, I meant increase in object code size (or the
library size which includes least symbols(in release mode)) by using
typedef instead of preprocessor.

I've a notion that Preprocessors were simply replaced by Preprocessor
before compiler/assembler generates the object code but for typedef
there might be some implicit conversions since it is not a
preprocessor.

Thanks,
Nishu

 

[jacob navia]

Nishu a écrit :

[...]

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

No. A typedef merely creates an alias for an existing type. It's a
notational convenience. I can't think of any reason why it would
increase code size. If you can explain what you mean (increase code
size compared to what?), perhaps we can explain further.

By increase in code size, I meant increase in object code size (or the
library size which includes least symbols(in release mode)) by using
typedef instead of preprocessor.

I've a notion that Preprocessors were simply replaced by Preprocessor
before compiler/assembler generates the object code but for typedef
there might be some implicit conversions since it is not a
preprocessor.

Thanks,
Nishu

You are wrong. The object code size will be the same, since the assembly
instructions for using an int pointer or a typedefed int pointer will be
exactly the same.

Of course, if your compiler generates DEBUG INFORMATION then it will
generate a record for the typedef. But many compilers (lcc-win32 for
instance) generate ALSO records for the #defines, noting if it is a
macro or just a replacement, etc. This will be highly specific to the
format of the debug information but I would guess it will be almost the
same.

 

[Malcolm McLean]

By increase in code size, I meant increase in object code size (or the
library size which includes least symbols(in release mode)) by using
typedef instead of preprocessor.

I've a notion that Preprocessors were simply replaced by Preprocessor
before compiler/assembler generates the object code but for typedef
there might be some implicit conversions since it is not a
preprocessor.

A compiler can do what it wants.
So it is conceivable that it might add an ASCII string representing the
typedef to some intermediate file, even the final executable. However
normally typedef would be resolved to the basic type by the front end, and
the object have the plain signature.

 

[Lane Straatman]

[...]

Is it true that typedef increases code size but #define does_NOT_,
since latter being the preprocessor.

No. A typedef merely creates an alias for an existing type. It's a
notational convenience. I can't think of any reason why it would
increase code size. If you can explain what you mean (increase code
size compared to what?), perhaps we can explain further.

By increase in code size, I meant increase in object code size (or the
library size which includes least symbols(in release mode)) by using
typedef instead of preprocessor.

I've a notion that Preprocessors were simply replaced by Preprocessor
before compiler/assembler generates the object code but for typedef
there might be some implicit conversions since it is not a
preprocessor.

#define verbose damnit
I think it makes next to no sense to talk about code size with either a
defines or a typedef. You take all the room you need. LS

 

[Dietmar Schindler]

I think it makes next to no sense to talk about code size with either a
defines or a typedef. You take all the room you need. LS

Yes, and there is no reason why increased room would be needed either
way.