typedef usage

[Mark]

Hello,

I was reading a coding style adopted in FreeBSD (and I believe in other
*BSD too) and here is what is said about using of 'typedefs':

"Avoid using typedefs for structure types.
....
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses
it, or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef."

What is meant by stand-alone header files? I dont' quite understand the
hassle with including headers? We can declare incomplete type in a
header "a.h", and define the type in a source file "a.c". Then only
#include "a.h" and make use of the new defined type.

Or, what's more likely, I do not entirely understand this coding style
definitions.

 

[David RF]

Hello,

I was reading a coding style adopted in FreeBSD

Adopted in FreeBSD kernel source ...
and also in Linux kernel source:

http://www.linuxjournal.com/article/5780

typedef Is Evil

typedef should not be used in naming any of your structures. Most main
kernel structures have no typedef. Though this would shorten their
usage, it obscures code. For example, the core kernel structures
struct inode, struct dentry, struct file, struct buffer_head, struct
user and struct task_struct have no typedef.

Using a typedef only hides the real type of a variable. There are
records of some kernel code using typedefs nested up to four layers
deep, preventing the programmer from easily telling what type of
variable they are actually using. If the programmer does not realize
the size of the structure it can cause very large structures to be
accidentally declared on the stack or to be returned from functions.

typedef also can be used as a crutch to keep from typing long
structure definitions. If this is the case, the structure names should
be made shorter, according to the above-listed naming rules.

Never define a typedef to signify a pointer to a structure, as in the
following example:

typedef struct foo {
int bar;
int baz;
} foo_t, *pfoo_t;

This hides the true type of the variable and uses the name of the
variable type to define what it is (see the previous comment about
Hungarian notation).

Some examples of where typedefs are used badly are in the include/raid/
md*.h files, where every structure has a typedef assigned to it, and
in the drivers/acpi/include/*.h files, where a lot of the structures
do not even have a name assigned to them, only a typedef.

 

[Marco]

Hello,

I was reading a coding style adopted in FreeBSD (and I believe in other
 *BSD too) and here is what is said about using of 'typedefs':

"Avoid using typedefs for structure types.
...
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses
it, or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef."

What is meant by stand-alone header files?

I assume they mean a .h file that doesn't correspond to a .c file.
In application code you usually see:

mymodule.h - module spec interface
mymodule.c - module implementation

For these certainly typedef is quite useful as you mentioned

but sometimes you need types that are not associated with a specific
module so these end up something like:

somerelatedtypes.h

I'm not sure of the specific "typedef is evil for stand-alone header
files" maybe someone can give a specific case.

 

[BGB / cr88192]

Hello,

I was reading a coding style adopted in FreeBSD (and I believe in other
*BSD too) and here is what is said about using of 'typedefs':

"Avoid using typedefs for structure types.
...
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses
it, or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef."

What is meant by stand-alone header files? I dont' quite understand the
hassle with including headers? We can declare incomplete type in a
header "a.h", and define the type in a source file "a.c". Then only
#include "a.h" and make use of the new defined type.

Or, what's more likely, I do not entirely understand this coding style
definitions.

I don't use this style personally (AKA: I use lots of typedefs).

however, I think it has a lot to do with how one organizes their headers.

for example, typedefs are likely to be a much bigger issue with
distributed/piecewise header usage (of the sort often found in many
GNU-style projects).

so, in this style, one typically includes lots of little tiny headers and
they typically have a "web-like" relationship pattern, and if one is not
careful, the relations between them can become tangled and complex.


one strategy I had found in this case, when dealing with typedefs, is to
wrap the relevant typedefs in macros, and allow some amount of
redundancy/duplication, mostly so that rather than conflict, a redundant
definition ifdef's itself out of existence.

example:
#ifndef BYTE_T
#define BYTE_T
typedef unsigned char byte;
#endif



however, if ones' strategy is more to organize headers into a big set of
tree-like relationships, and typically only ever include 1 header per
source-file (usually a single header forming the "authority" for the entire
visible scope of said library), then managing typedef issues is a much
smaller issue.

the major cost though, is that in many cases this single header may end up
including huge amounts of stuff (maybe 300kB, maybe 3MB...), which does not
help much with compile times, among other issues...


in part, this issue is "fixable" (mostly it would be to clean up libraries
such that the "inside" and "outside" portions are more clearly defined, and
as such, including a header could omit huge amounts of stuff only
particularly relevant within the individual libraries...)..

 

[Joachim Schmitz]

BGB / cr88192 wrote:
snip

I don't use this style personally (AKA: I use lots of typedefs).

ITYM (I Think You Ment) IOW (In Other Words) rather than AKA (Also Known As)

PCMCIA (People Can't Memorize Computer Industries Acronyms)

Bye, Jojo

 

[BGB / cr88192]

BGB / cr88192 wrote:
snip

ITYM (I Think You Ment) IOW (In Other Words) rather than AKA (Also Known
As)

PCMCIA (People Can't Memorize Computer Industries Acronyms)

yeah, IOW would have been maybe better...
AKA works I think, since it has the same basic meaning AFAICT.


or such...

 

[James Kuyper]

yeah, IOW would have been maybe better...
AKA works I think, since it has the same basic meaning AFAICT.

No, it does not. AKA introduces an alternative name for something.
AFAICT indicates a certain low amount of uncertainty about the accuracy
of the following statement. Neither abbreviation fits the above context.

 

[Eric Sosman]

[...]
No, it does not. AKA introduces an alternative name for something.

So "AKA" means "typedef?"

 

[Flash Gordon]

[...]
No, it does not. AKA introduces an alternative name for something.

So "AKA" means "typedef?"

No, because it can be used for more than just typedefs. For example, I
am AKA Mark. However, a typedef is a way of creting one of the many
forms of AKA.

 

[BGB / cr88192]

No, it does not. AKA introduces an alternative name for something. AFAICT
indicates a certain low amount of uncertainty about the accuracy of the
following statement. Neither abbreviation fits the above context.

AKA was being compared to IOW.

AFAICT was just being used as a word in this context (I would have included
"as AFAIK" if I had meant as you interpreted it).


<A> (AKA <B>)
<A> (IOW <B>)

both would seem to have approximately the same semantics, since both tend to
mean A is approximately B, or, alternatively:
if A then B


or such...

 

[James Kuyper]

AKA was being compared to IOW.

AFAICT was just being used as a word in this context (I would have included
"as AFAIK" if I had meant as you interpreted it).

I'm sorry - my brain automatically filled in the "as" that, as you
correctly point out, was not actually present.

AKA introduces an alternate name for something (usually, someone). IOW
introduces an alternate way of saying something. They're closely related
concepts, but not identical. In the context above, IOW fits, AKA doesn't.

 

[BGB / cr88192]

I'm sorry - my brain automatically filled in the "as" that, as you
correctly point out, was not actually present.

yes, ok.

I usually include words like this, or omit them, as needed, since after all,
it is these little works, like 'as', 'but', 'for', ... which usually hold
all these phrases together and help everything make sense...

except 'the' though, which to me usually does not seem to hold much meaning,
and I guess I tend to leave it out a lot when speaking (among other things).

nevermind that I am a native speaker, yet in the past it has been commented
that I speak about like I were using 'basic english' or 'singlish' or
similar. I lack any good reason why this would be the case, but oh well...

I guess it is mostly as, in speaking, I often tend to leave out things like
articles, pronouns, ... and others have noticed this in the past.

AKA introduces an alternate name for something (usually, someone). IOW
introduces an alternate way of saying something. They're closely related
concepts, but not identical. In the context above, IOW fits, AKA doesn't.

well, I personally am not entirely solid on these sorts of semantic
differences.

granted, I am generally aware of the more structural aspects of grammer
(even if I am usually rather lazy about it), and I am aware that if
fully-expanded, these acronyms would not be identical WRT grammar, but it is
not clear when they are acronyms, since in my mind this essentially makes
them a single word, and so presumably would fit into one of the common word
categories (preposition, noun, verb, ...).

however, these ones are often used in cases which do not match prior
existing word categories (grammatic function would seem similar to the
phrases which are usually compacted, implying something is "unusual" with
the way these phrases handle grammar).

so, I don't know here...