Re: Typedef structs

From: Keith Thompson (kst-u_at_mib.org)
Date: 08/31/04


Date: Tue, 31 Aug 2004 09:32:10 GMT

Tim Rentsch <txr@alumnus.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
> > The counterargument is that it hides (or attempts to hide) information
> > that shouldn't be hidden.
> ^^^^^^^^^
> What reasons would you offer that it shouldn't be hidden? In a separate
> article I responded to another poster's query and listed some advantages
> of the separate type name approach. Could one of the just-use-structs
> advocates respond and list some principal advantages of not using
> a separate type name?

I'm probably not one of the "just-use-structs advocates", but I'll
respond anyway.

I certainly have no objection to abstract types, and they should
probably be used more often than they are, but not all types are
abstract.

I gave several examples in my previous post. To repeat one of them,
the type "struct tm", declared in <time.h>, is visibly a struct.
Declaring a typedef, say "typedef struct tm { ... } tm;", and
declaring an object as
    tm obj;
rather than as
    struct tm obj;
doesn't really hide anything when you're referring to "obj.tm_sec"
anyway.

If struct tm were an abstract data type, with no defined members and a
purely functional interface, the typedef would make perfect sense.

Personally, I see the debate as something similar to the controversies
over brace style. Most people have their own preferences, and many
people feel quite strongly about them (perhaps with good reason), but
we all had better be able to cope with code written in styles other
than the one we like.

[...]

> > (Personally, I'm not as opposed to gratuitous typedefs for structs as
> > some people are, but I understand the arguments.)
>
> Keith, I'm disappointed. This kind of rhetoric - a content-free
> statement giving a "non-argument" argument, including the emotional
> hook word "gratuitous" - should be below you.

Huh?

The statement in parentheses wasn't meant to be an argument, just a
disclaimer. Feel free to read "gratuitous" as "not strictly
necessary" if it will make you happy. (I don't see "gratuitous" as a
purely pejorative term.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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.


Relevant Pages

  • Re: Abnormal Normalization?
    ... see a reason to have a separate "person" table. ... do that myself - for several reasons. ... admit the idea of an employee also being a contact (which i've always used ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Extras on TV Show Complete Series sets
    ... especially when it's something as important as the sequel movies. ... Wild, Wild, West - ditto ... all of the separate season sets. ... They've pissed off enough people for enough different reasons ...
    (rec.arts.tv)
  • Re: Moving /home
    ... supposed to be related to the reason /root and /home are separate on the same ... most other *NIXes), physical drives are irrelevant, security is controlled ... There are good reasons to separate /home from the rest of the filesystem, ... a RAID array, drives can easily be added to the array to transparently ...
    (comp.os.linux.setup)
  • Re: [PATCH 3/3] add open iscsi netlink interface to iscsi transport class
    ... can you please insert the patches inline? ... +struct mempool_zone { ... please use two separate helpers for transport/host instead of the H_TYPE ...
    (Linux-Kernel)
  • Re: modernization of FORTH, Age Results
    ... not separate arguments from local values. ... Why is it necessary for the language to make such ... Two reasons: ...
    (comp.lang.forth)