Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Interesting features of #define and typedef, correct me if I am wrong

Reply
Thread Tools

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

 
 
fdmfdmfdm@gmail.com
Guest
Posts: n/a
 
      02-01-2007
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?

 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      02-01-2007
<(E-Mail Removed)> wrote in message
> 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.


 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      02-01-2007
Malcolm McLean wrote:
> <(E-Mail Removed)> wrote in message
>
>>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.
>

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

--
Ian Collins.
 
Reply With Quote
 
Lane Straatman
Guest
Posts: n/a
 
      02-01-2007

"Ian Collins" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Malcolm McLean wrote:
>> <(E-Mail Removed)> wrote in message
>>

[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


 
Reply With Quote
 
Christopher Layne
Guest
Posts: n/a
 
      02-02-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> ===================================
> #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.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      02-02-2007
(E-Mail 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Nishu
Guest
Posts: n/a
 
      02-02-2007
On Feb 2, 11:36 am, Richard Heathfield <(E-Mail Removed)> wrote:

<snip>
> > ===================================
> > #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.
>


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

Thanks,
Nishu

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      02-02-2007
Nishu said:

<snip>

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-02-2007
"Nishu" <(E-Mail Removed)> writes:
[...]
> 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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Nishu
Guest
Posts: n/a
 
      02-02-2007
On Feb 2, 12:58 pm, Keith Thompson <(E-Mail Removed)> wrote:
> "Nishu" <(E-Mail Removed)> writes:
>
> [...]
>
> > 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are c++ features a subset of java features? BillJosephson C++ 148 01-27-2007 11:40 AM
Correct White Balance Doesn't Mean Correct Color?? jim evans Digital Photography 28 12-27-2005 05:10 AM
Two favorite features of C++, and over-rated, and misued features Jonathan Mcdougall C++ 2 11-03-2005 06:22 PM
correct or not correct? Dan HTML 7 10-02-2003 10:16 PM
To correct my program. please, check to find errors and correct me. joon Java 1 07-08-2003 06:13 AM



Advertisments