Re: [RFC] struct *_struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Witten <mfwitten@xxxxxxxxx> writes:
> On Wed, Aug 4, 2010 at 14:24, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> I hate... "typedef foo struct foo"
>
> How come?

There is a practical issue in that "struct foo *" can be used with just
a forward declaration (or no declaration at all), whereas "foo *"
requires the declaration of foo be visible.  This is especially handy
given C's use of #include, because in cases where there are circular
type references, it can be very annoying to get things #included in the
right order; being able to use a forward declaration instead of #include
makes it easy to break such loops.  One can still use "struct foo *"
even if there are typedefs, of course, but that breaks the illusion that
"foo" is an abstract type, and I gather that illusion is one reason
people like the typedefs in the first place.

But I think mainly it's an issue of style/culture:

Some codebases use "typedef style" (obviously those in C++, since the
typedefs are automatically), and in those codebases programmers will
naturally choose typenames that are more distinct (e.g., the common
convention of using StudlyCaps for types).  Some codebases use "struct
style" (in C programs I think this is more common, as C-programming
culture tends to value explicitness and simplicity).

One should use follow whatever style is common in the codebase one is
working on.  If git uses "struct foo" generally, new code should use
"struct bar".

-miles

-- 
Arrest, v. Formally to detain one accused of unusualness.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]