Re: Proposal: Naming conventions
On Fri, 11 Jan 2002, Jonathan Leffler wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> >[...] I'd like to propose a convention [...] By example:
> >
> >struct somename_t { ... };
> >typedef struct somename_t { ... }* Somename;
> >
> >The non-typedef'd name of a struct type ends in _t.
>
> Is this a good idea? The _t suffix is reserved by POSIX for use by the
> implementation (POSIX 1003.1-1996, Section 2.7.2, table 2-2, p43: "any
> POSIX.1 header included - key 1 - reserved suffix '_t'", and key 1 is
> "Prefixes and suffixes of symbols that shall not be declared or #defined
> by the application").
We *could* put 't' beforehand: t_Foobar
I am working on another project in which we do that and it works out
nicely.
> Personally, I use: typedef struct Abcdef { ... } Abcdef; That is, the
> structure tag and the typedef name are the same.
Even better if you do this:
typedef struct Foo Foo;
struct Foo {
...
};
Then you can put 'Foo's inside of your struct and not have to put 'struct'
in front of them. :-)
> Is there any reason to keep structure tag names different from the
> typedef name? What is the benefit?
I don't think there is any. Every C compiler I've ever used lets you have
the names be the same.
> In practice, IMO, once the typedef is in place, the 'struct Tag'
> notation shouldn't be used thereafter; the only benefit to it is that
> you can write 'struct Tag *' where there is no previous declaration for
> 'struct Tag', which is at least nominally dubious coding practice -
> though it matches C++ forward declarations, so it is bearable.
I think if you need to use a struct before it is defined, then pre-declare
it, otherwise some compilers will give warnings.
- D
<[EMAIL PROTECTED]>
Re: Proposal: Naming conventions
On Fri, Jan 11, 2002 at 11:45:03AM -0800, Jonathan Leffler wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> >[...] I'd like to propose a convention [...] By example:
> >
> >struct somename_t { ... };
> >typedef struct somename_t { ... }* Somename;
> >
> >The non-typedef'd name of a struct type ends in _t.
>
> Is this a good idea? The _t suffix is reserved by POSIX for use by the
> implementation (POSIX 1003.1-1996, Section 2.7.2, table 2-2, p43: "any
> POSIX.1 header included - key 1 - reserved suffix '_t'", and key 1 is
> "Prefixes and suffixes of symbols that shall not be declared or #defined
> by the application").
>
> I know it has bitten Informix a couple of times (loc_t, dec_t). In
> practice, most of the time, you will get away with it, but is 'most of
> the time' adequately portable for Parrot? If you also apply a
> Parrot-specific prefix, then you can decide that trumps the banned
> suffix, but that is nasty.
>
> Personally, I use: typedef struct Abcdef { ... } Abcdef; That is, the
> structure tag and the typedef name are the same -- I'm not pontificating
> on letter case but I do use leading capitals on type names in general.
>
> Is there any reason to keep structure tag names different from the
> typedef name? What is the benefit? In practice, IMO, once the typedef
The reason I use a different name is because for ADTs I like to
typedef a pointer to a struct, and I definitely don't want 'struct
Stack' to be different from 'Stack'. But you're right, if we don't
typedef pointers as appears to be the prevailing opinion, there's no
reason to use a different name.
> is in place, the 'struct Tag' notation shouldn't be used thereafter; the
> only benefit to it is that you can write 'struct Tag *' where there is
> no previous declaration for 'struct Tag', which is at least nominally
> dubious coding practice - though it matches C++ forward declarations, so
> it is bearable.
I tend to use 'struct foo;' forward declaration quite a bit in C code
header files. It's good for disentangling a lot of fake
interdependencies among .h files.
Re: Proposal: Naming conventions
On Thu, 10 Jan 2002, Steve Fink wrote:
>[...] I'd like to propose a convention [...] By example:
>
>struct somename_t { ... };
>typedef struct somename_t { ... }* Somename;
>
>The non-typedef'd name of a struct type ends in _t.
Is this a good idea? The _t suffix is reserved by POSIX for use by the
implementation (POSIX 1003.1-1996, Section 2.7.2, table 2-2, p43: "any
POSIX.1 header included - key 1 - reserved suffix '_t'", and key 1 is
"Prefixes and suffixes of symbols that shall not be declared or #defined
by the application").
I know it has bitten Informix a couple of times (loc_t, dec_t). In
practice, most of the time, you will get away with it, but is 'most of
the time' adequately portable for Parrot? If you also apply a
Parrot-specific prefix, then you can decide that trumps the banned
suffix, but that is nasty.
Personally, I use: typedef struct Abcdef { ... } Abcdef; That is, the
structure tag and the typedef name are the same -- I'm not pontificating
on letter case but I do use leading capitals on type names in general.
Is there any reason to keep structure tag names different from the
typedef name? What is the benefit? In practice, IMO, once the typedef
is in place, the 'struct Tag' notation shouldn't be used thereafter; the
only benefit to it is that you can write 'struct Tag *' where there is
no previous declaration for 'struct Tag', which is at least nominally
dubious coding practice - though it matches C++ forward declarations, so
it is bearable.
>[...]
--
Jonathan Leffler #include
STSM, IBM Data Management Solutions. Phone: +1 650-926-6921
Email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Guardian of DBD::Informix v1.00.PC1 -- http://dbi.perl.org
"I don't suffer from insanity; I enjoy every minute of it!"
Re: Proposal: Naming conventions
At 11:34 PM 1/10/2002 +, Tom Hughes wrote: >In message <20020110201559$[EMAIL PROTECTED]> > "Melvin Smith" <[EMAIL PROTECTED]> wrote: > >Well sizeof(Foo) and sizeof(*foo) are not actually the same thing >at all there because Foo is presumably a typedef for a pointer type >so sizeof(Foo) will be the size of a pointer and sizeof(*foo) will >be the size of the thing it points to. Right, I misread the code snippet in my infinite confusion. >In general it is safer to sizeof() on the variable you are working >with than on it's type, as that way the sizeof() will still work if >somebody changes the type of the variable. Well even after misreading the snippet the point I was getting at was emulating virtual pointers in C++ where the allocator might create an object regardless of what type of pointer it was using or assigning to. For example in the case where an allocator had in it a switch statement of subclasses. In the end this is more the exception than the rule and I see I was just on a tangent. :) >The type of *foo is whatever Foo as been typedefed as a pointer >to, and FooBar is a red herring. Grin, I'll read more carefully before arguing next time. ;) -Melvin
Re: Proposal: Naming conventions
In message <20020110201559$[EMAIL PROTECTED]> "Melvin Smith" <[EMAIL PROTECTED]> wrote: > > Foo foo = (Foo) malloc(sizeof(*foo)); > >? Does ANSI allow using sizeof on a variable declared on the > > same line? > > Wouldn't sizeof(Foo) be safer here? At the logical time of the > call *foo points to undefined. Technically its not a deref but > still looks scary. In C++ it might be confusing if you were to > cast it as: Well sizeof(Foo) and sizeof(*foo) are not actually the same thing at all there because Foo is presumably a typedef for a pointer type so sizeof(Foo) will be the size of a pointer and sizeof(*foo) will be the size of the thing it points to. You're quite right that it isn't technically a deref, as sizeof() is only interested in the static type of the object and is evaluated at compile time (if we ignore VLA's in C99 that is). In general it is safer to sizeof() on the variable you are working with than on it's type, as that way the sizeof() will still work if somebody changes the type of the variable. > // If it were really C++ we would probably be using new() > Foo foo = (FooBar) malloc(sizeof(*foo)); > > What type is *foo then? Should be Foo, but what if FooBar > was of different size, it might not be an obvious bug to someone > that just came along and tweaked your code. The type of *foo is whatever Foo as been typedefed as a pointer to, and FooBar is a red herring. > >If people have visceral objections to typedef'ing pointers, I'm > >fine with dropping that part of the proposal. I'd just like to see > > I've always been uncomfortable with that practice, its one part of > the whole Win32 world I hate. If you stick with the practice then > you either end up making a new typedef for every level of indirection > or you drop to using * (some typedef), etc. Now if it were C++ and we > were using a smart pointer class I don't mind the practice. I will agreee that hiding pointers inside typedefs is not a very good idea, if only because it makes it impossible to const qualify the pointer without creating a second parallel typedef. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Proposal: Naming conventions
On Thu, Jan 10, 2002 at 03:18:33PM -0500, Melvin Smith wrote: > Eep, to answer the original subject of your mail, I think its a good idea > to start with the _t typedef standard. except that POSIX (IIRC, but it's either them or ANSI) reserves all names ending in _t for themselves. So any other name except _t would avoid non conformance. (do we want to avoid non conformance that much?) Nicholas Clark -- ENOJOB http://www.ccl4.org/~nick/CV.html
Re: Proposal: Naming conventions
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote: > On Thu, 10 Jan 2002, Steve Fink wrote: > > > The naming of things is getting a bit messy. I'd like to propose a > > convention that I use in my work. It's compatible with the last draft > > of PDD 7 that I could find: > > http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html > > I agree, we should definitly be sticking to a standard. I think, though, > that putting the * in the typedefs for structs might be a little > confusing; at least, on all the systems I've worked on that do this, I've > been confused. But that might just be me. :-) Well, I'm not doing it to avoid typing the '*'. I'm doing it to mark the type as referring to an abstract data type called a 'Stack', gosh darn it, and if I pass a Stack into a subroutine then I don't want the receiver to get a member-wise copy of my Stack's guts -- that wouldn't be *my* Stack. It would be a new gibbering beast that happened to share pointers and other internal organs with my Stack in ways that would doom them both to half-lives of pain, discomfort, and arguments over whose turn it was to use the liver that night and who got stuck with the spleen. Or at least that's the way I think of it. Gotta go now.
Re: Proposal: Naming conventions
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote: > After looking through PDD 7, I wonder: were we planning on doing any of > this stuff? If so, maybe we should step back for a moment and do it. :-) > If developers are expected to follow these guidelines (not that I've done > any developing, but hey), then everyone should take the time to read this > file (and probably the other PDDs), and maybe think about fixing up either > the code to follow the PDD, or the PDD to follow the code. A first step might be posting PDD 7, or the last known version if David Mitchell can't be found, on dev.perl.org.
Re: Proposal: Naming conventions
On Thu, 10 Jan 2002, Steve Fink wrote: > The naming of things is getting a bit messy. I'd like to propose a > convention that I use in my work. It's compatible with the last draft > of PDD 7 that I could find: > http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html I agree, we should definitly be sticking to a standard. I think, though, that putting the * in the typedefs for structs might be a little confusing; at least, on all the systems I've worked on that do this, I've been confused. But that might just be me. :-) My question is (again, I suppose): What about INTVAL, NUMVAL, STRING, and friends? I have the distinct impression that they were uppercased somewhat in veneration of our old perl5 frieds IV, SV, PV, NV, etc. I think they should adhere to the same standard as everything else... whatever that may be. After looking through PDD 7, I wonder: were we planning on doing any of this stuff? If so, maybe we should step back for a moment and do it. :-) If developers are expected to follow these guidelines (not that I've done any developing, but hey), then everyone should take the time to read this file (and probably the other PDDs), and maybe think about fixing up either the code to follow the PDD, or the PDD to follow the code. - D <[EMAIL PROTECTED]>
Re: Proposal: Naming conventions
Eep, to answer the original subject of your mail, I think its a good idea to start with the _t typedef standard. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: Proposal: Naming conventions
> Foo foo = (Foo) malloc(sizeof(*foo)); >? Does ANSI allow using sizeof on a variable declared on the > same line? Wouldn't sizeof(Foo) be safer here? At the logical time of the call *foo points to undefined. Technically its not a deref but still looks scary. In C++ it might be confusing if you were to cast it as: // If it were really C++ we would probably be using new() Foo foo = (FooBar) malloc(sizeof(*foo)); What type is *foo then? Should be Foo, but what if FooBar was of different size, it might not be an obvious bug to someone that just came along and tweaked your code. Not sure if I made any point here but it seemed interesting. :) >and in the gazillion places where 'struct Parrot_Interp *' >is used, we'd use 'Parrot_Interp' instead. Imagine, we'll save >8 bytes * 1 gazillion occurrences! More function declarations >will fit on a line! World peace will ensue and the moon will >become habitable again! Agreed, in my code I defined a macro theINTERP for that whole aggravation which sort of hides the type in the macro but as we only have 1 interp type... >If people have visceral objections to typedef'ing pointers, I'm >fine with dropping that part of the proposal. I'd just like to see I've always been uncomfortable with that practice, its one part of the whole Win32 world I hate. If you stick with the practice then you either end up making a new typedef for every level of indirection or you drop to using * (some typedef), etc. Now if it were C++ and we were using a smart pointer class I don't mind the practice. Anyway I'm one opinion in a haystack. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
