On Wed, 13 Jul 2011, Yehuda Sadeh Weinraub wrote:
> On Wed, Jul 13, 2011 at 11:08 AM, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote:
> > On Wed, Jul 13, 2011 at 11:04 AM, Yehuda Sadeh Weinraub
> > <yehudasa@xxxxxxxxx> wrote:
> >> On Wed, Jul 13, 2011 at 10:59 AM, Samuel Just <samuelj@xxxxxxxxxxxxxxx> wrote:
> >>> On 07/13/2011 10:52 AM, Yehuda Sadeh Weinraub wrote:
> >>>>>
> >>>>> * Naming> Type Names:
> >>>>>
> >>>>> Google uses CamelCaps for all type names. We use two naming schemes:
> >>>>>
> >>>>> - for structs (simple data containers), lower case with _t suffix:
> >>>>> struct my_type_t {
> >>>>> int a, b;
> >>>>> my_type_t() : a(0), b(0) {}
> >>>>> };
> >>>>
> >>>> I'd rather have the struct naming without the _t suffix (as with the C
> >>>> code), and typedef to add _t, e.g.:
> >>>>
> >>>> typedef struct my_type {
> >>>> ...
> >>>> } my_type_t;
> >>>>
> >>> What is the advantage of the typedef?
> >>
> >> Being consistent. That's what we do in C. The _t suffix denotes a
> >> typedef, so it should be defined as one. We also mix C and C++ from
> >> time to time (e.g., we have code that is common to both userspace side
> >> and kernel side and/or links with other projects like qemu), so
> >> keeping the same notation is crucial.
> >>
> >
> > Actually, using typedef that way is *inconsistent*, since we claim to
> > follow the kernel coding style document. And this is what it has to
> > say about that:
> >
> >> Please don't use things like "vps_t".
> >>
> >> It's a _mistake_ to use typedef for structures and pointers. When you see a
> >>
> >> vps_t a;
> >>
> >> in the source, what does it mean?
> >>
> >> In contrast, if it says
> >>
> >> struct virtual_container *a;
> >>
> >> you can actually tell what "a" is.
>
> Whether to typedef or not is a different issue. If you want a _t
> suffix, use typedef.
Yeah, I'm not suggesting a typedef. It's only useful in C if you want to
exclude the 'struct' prefix which isn't needed in C++ anyway.
The key distinction I want to make is between things like struct inode_t,
which is essentially a glorified struct with initializers/constructor, is
encodable, and has a few helper methods, versus something like SimpleLock,
which is not copyable, not encodable, has pointers to parent objects,
exists on specific lists, etc. Currently the former "struct" type is
named_like_this_t and the latter "class" is NamedLikeThis.
In C, the no typedef rule makes a lot of sense, since you know it is a
struct. In C++, it doesn't matter if it's a struct becaue the
initialization and such (which you tend to screw up in C) is hidden from
you anyway.
The nice thing about _t and CamelCaps both is that they don't collide with
variable names. My concern is that
inode *in;
isn't as clear as
inode_t *in; // clearly a type
Inode *in; // clearly a type
sage
