Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Typedef question

Reply
Thread Tools

Typedef question

 
 
mdh
Guest
Posts: n/a
 
      09-02-2008
A quick ? question about Typedefs.
There is a very brief discussion about this in K&R ( p146). Googling
this group, there is a surprising dearth of questions about these.
From one of the threads, there is sound advice ( to me at any rate)
not to hide pointers behind typedefs.
So, may I ask the group when the use of typedefs really makes sense?

Sorry if this is somewhat general, but there are no exercises ( not
that I am asking for any!!) provided.
 
Reply With Quote
 
 
 
 
jameskuyper@verizon.net
Guest
Posts: n/a
 
      09-02-2008
mdh wrote:
> A quick ? question about Typedefs.
> There is a very brief discussion about this in K&R ( p146). Googling
> this group, there is a surprising dearth of questions about these.
> From one of the threads, there is sound advice ( to me at any rate)
> not to hide pointers behind typedefs.
> So, may I ask the group when the use of typedefs really makes sense?
>
> Sorry if this is somewhat general, but there are no exercises ( not
> that I am asking for any!!) provided.


Typedefs serve at least two main purposes. The most common one is to
allow you to write code that uses a particular type, when you
anticipate that the type it should use might be different in different
contexts. A simple example is size_t, which is a typedef set up by the
C standard library itself. It might be 'unsigned char' on one
implementation, and "unsigned long long" on another. However, you
don't have to make any changes to your code when moving it from one
implementation to the other, because the change occurs inside the C
standard headers that typedef size_t..

The second use I've seen is for simplifying type declarations. If you
make a lot of use of unsigned char, it's convenient to use

typedef unsigned char uchar;

Similarly, it's convenient to use

typedef struct { int i; double d; } intdouble;

rather than

struct intdouble { int i; double d;};

mainly because it allows you to refer to the type using "intdouble"
rather than "struct intdouble". This is especially attractive to
people who are used to C++, where the keyword struct would be needed
only in the definition of the type, and not when using it.

And, as you've already seen, typedef can be used to simplify code that
relies upon function pointers.
 
Reply With Quote
 
 
 
 
mdh
Guest
Posts: n/a
 
      09-02-2008
On Sep 2, 12:47*pm, Eric Sosman <(E-Mail Removed)> wrote:
> mdh wrote:
> > A quick ? question about Typedefs.
> >

> * * *One important use for typedef is to deal with the variability
> of C's native types from machine to machine.
> * * *Another important use is to improve readability by decomposing
> complicated declarations into manageable pieces.
>
> (E-Mail Removed)


thank you Eric for that explanation.
 
Reply With Quote
 
mdh
Guest
Posts: n/a
 
      09-02-2008
On Sep 2, 12:50*pm, (E-Mail Removed) wrote:
> mdh wrote:
> > A quick ? question about Typedefs.


>
> Typedefs serve at least two main purposes. The most common one is to
> allow you to write code that uses a particular type.


> The second use I've seen is for simplifying type declarations. If you
> make a lot of use of unsigned char, it's convenient to use
>
>


thank you James. Appreciated.
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      09-02-2008
On Sep 2, 10:50 pm, (E-Mail Removed) wrote:
> mdh wrote:
> > A quick ? question about Typedefs.
> > There is a very brief discussion about this in K&R ( p146). Googling
> > this group, there is a surprising dearth of questions about these.
> > From one of the threads, there is sound advice ( to me at any rate)
> > not to hide pointers behind typedefs.
> > So, may I ask the group when the use of typedefs really makes sense?

>
> > Sorry if this is somewhat general, but there are no exercises ( not
> > that I am asking for any!!) provided.

>
> Typedefs serve at least two main purposes. The most common one is to
> allow you to write code that uses a particular type, when you
> anticipate that the type it should use might be different in different
> contexts. A simple example is size_t, which is a typedef set up by the
> C standard library itself. It might be 'unsigned char' on one
> implementation, and "unsigned long long" on another. However, you
> don't have to make any changes to your code when moving it from one
> implementation to the other, because the change occurs inside the C
> standard headers that typedef size_t..
>
> The second use I've seen is for simplifying type declarations. If you
> make a lot of use of unsigned char, it's convenient to use
>
> typedef unsigned char uchar;


Ugh. I don't really like code that does that. Also code that has u8,
uchar8 etc.
IMHO typedef is not there to save you typing. You could edit your
editor so whenever you type `uchar ' it replaces it with unsigned
char.
 
Reply With Quote
 
dj3vande@csclub.uwaterloo.ca.invalid
Guest
Posts: n/a
 
      09-02-2008
In article <1220384800.358284@news1nwk>,
Eric Sosman <(E-Mail Removed)> wrote:

> Finally, the pointer thing. Even when a library traffics in
>pointers to private structs, the fact that they're pointers is usually
>something the caller must know, if for no other reason than to test
>a returned value against NULL. For this reason, I'd prefer to say
>that a function returns a `HashItem*' than a `HashItemPointer'; the
>latter just makes it harder to discern what you're dealing with.
>(Is this stance inconsistent with my preference for `HashItem' over
>`struct hashItem'? Probably, but as I said earlier I'm not going to
>war over it.)


I disagree that this is inconsistent; since pointerness is important
for the user-programmer to know about, revealing it in the interface
instead of hiding it behind a typedef is an easy way to save the
user-programmer the trouble of making a trip to the documentation to
discover it. Revealing structness in the same way doesn't give
information that's useful (at least, it doesn't if your type is
actually abstract; if you want to give direct information to (some of)
the struct members, then the user-programmer also needs to know that
it's a struct, and in that case hiding structness behind a typedef is
also a Bad Idea).


I dislike hiding both properties behind typedefs; but my dislike for
hiding structness is a purely aesthetic dislike, and my dislike for
hiding pointerness is based on strong opinions about The Way Things
Should Be and on experience with how useful it is to have the
information in front of me while I'm editing code.


dave

--
Dave Vandervies dj3vande at eskimo dot com
I am Aquarion, I am everywhere. There are only 120 real people on the
Internet, and I'm three of them.
--Aquarion in the scary devil monastery
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-02-2008
mdh <(E-Mail Removed)> writes:
> A quick ? question about Typedefs.
> There is a very brief discussion about this in K&R ( p146). Googling
> this group, there is a surprising dearth of questions about these.
> From one of the threads, there is sound advice ( to me at any rate)
> not to hide pointers behind typedefs.
> So, may I ask the group when the use of typedefs really makes sense?
>
> Sorry if this is somewhat general, but there are no exercises ( not
> that I am asking for any!!) provided.


A typedef creates an alias (a name consisting of a single identifer)
for an existing type.

Strictly speaking, typedefs are almost never necessary. (The one
exception, I think, involves the va_arg macro for variadic functions,
which requires a type name that can be used in a certain way.)

It's very common to create a typedef for a struct type. In my opinion
(which plenty of smart programmers don't share), this is poor style.
For example, given:

struct foo {
/* member declarations */
};

the type already has a perfectly good name, "struct foo". Why create
another one? The counterargument is that it's more convenient to have
a simple single-identifier name for the type.

The syntax for function types and pointer-to-function types is
sufficiently convoluted that it can be worthwhile to simplify it by
using typedefs. For example if you want a pointer to a function that
takes a double argument and returns a double result, you can write:

double (*ptr)(double);

or you can write:

typedef double math_func(double);
math_func *ptr;

Or, if you prefer, you can write:

typedef double (*math_func_ptr)(double);

Hiding pointerness behind a typedef is usually a bad idea, but in the
case of a pointer-to-function type it's more defensible.

A typedef is also appropriate when you want an abstract data type,
where code that uses the type shouldn't know anything about its
internals. The type FILE, declared in <stdio.h> is a good example.
(The use of all-caps isn't particularly consistent with modern style,
which uses all-caps for macros, but it's been around for a very long
time.)

And typedefs are often appropriate for numeric types. I *don't* mean
something like

typedef unsigned int uint;

which does nothing but save you a little typing. I'm referring to a
weaker form of data abstraction, where code that uses the typedef
knows that it's an integer type, and whether it's signed or unsigned,
but doesn't need to know *which* predefined type because it can vary
from one system to another.

To summarize:

Use a typedef when the internal characteristics of the type are
irrelevant to code that uses it (e.g., FILE).

Use a typedef when a named type can be implemented differently on
different systems (e.g., int32_t, size_t).

Use a typedef to give a name to something that can otherwise only be
referred to by some complicated syntax, particularly in the case of
function types and pointer-to-function types.

If you're using a typedef just to save a few keystrokes, don't bother.
Given "typedef unsigned int uint;", uint can never be anything other
than unsigned int; just use its real name, "unsigned int". And if
uint *can* be something other than unsigned int, "uint" is a lousy
name.

Don't bother with typedefs for struct types unless you're doing the
kind of data abstraction I discussed above -- but reasonable people
differ on this.

And I can think of at least one exception to the above. I don't mind

typedef unsigned char byte;

"byte" can never be anything other than unsigned char, but assigning
the name "byte" can make the usage clearer (i.e., this is raw data,
not necessarily characters).

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-03-2008
(E-Mail Removed) writes:
[...]
> The second use I've seen is for simplifying type declarations. If you
> make a lot of use of unsigned char, it's convenient to use
>
> typedef unsigned char uchar;

[...]

IMNSHO it's not convenient enough to justify using a typedef rather
than just typing "unsigned char". For one thing, if I'm reading code
that uses "uchar" I'll always have a nagging suspicion that somebody
has decided it would be a cute idea to define it as something other
than unsigned char (say, unsigned short or wchar_t).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Thad Smith
Guest
Posts: n/a
 
      09-03-2008
mdh wrote:

> So, may I ask the group when the use of typedefs really makes sense?


Yes, you may.

In addition to the uses already described, I use typedefs for
documentation. For example, I may define a specific type, used in several
places, that is implemented as an unsigned int, but carries specific
attributes. For example,

typedef unsigned int tTimeout; /* timeout interval in ms, 0=none */

When I declare a variable of type tTimeout, I don't need to repeat the
measurement units and special meaning of 0, since it is inherited from the
typedef.

--
Thad
 
Reply With Quote
 
Mark L Pappin
Guest
Posts: n/a
 
      09-03-2008
Richard Heathfield <(E-Mail Removed)> writes:

> Keith Thompson said:
>
> <snip>
>
>> It's very common to create a typedef for a struct type. In my opinion
>> (which plenty of smart programmers don't share), this is poor style.
>> For example, given:
>>
>> struct foo {
>> /* member declarations */
>> };
>>
>> the type already has a perfectly good name, "struct foo".

>
> That's *two* names, one of which seems rather pointless.


*one* name, with two parts. Both parts are needed to unambiguously
refer to the type in question, lest you get the wrong struct or foo.

I would expect you of all people in this place to understand the
difference, Richard.

> Yes, opinions certainly do vary on this!


Both approaches have merit.

mlp
 
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
CRTP-problem: How can the base class typedef a derived class' typedef? oor C++ 0 05-20-2008 12:39 PM
typedef question Alex C++ 6 12-02-2005 04:37 PM
typedef question James Brown C Programming 3 11-16-2005 09:21 PM
one more template question and some typedef Tony Johansson C++ 7 08-16-2005 07:55 PM
A question about typedef and classes and templates.. JustSomeGuy C++ 1 09-20-2003 04:33 AM



Advertisments