«

Tom Plunket <> writes:
> Chris Torek wrote:
>>For those who insist on treating C as if it were C++...
>
> Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
> put it in the standard do you figure?

C has no concept of "sin" other than the trigonometric function. }

The idea that using typedefs for structure types is poor style is
actually rather controversial. Chris Torek and I happen to agree on
this point, but plenty of smart people don't.

An argument in favor of using a typedef is that it provides a one-word
name for a type. In my opinion, that's not a strong enough reason to
use it.

But typedefs are useful in other contexts. I ilke them for declaring
complex pointer-to-function types, and the standard library defines
typedefs for a number of integer type (size_t, int32_t, etc.).

> Anyway, thanks for your comments; it's helpful to find the useful
> information that exists therein.
>
> As it is, I'm faced with a codebase that has many features which are
> undesirable. The sad catch-22 is that I don't know what many of the
> problems are 'til I ask about them, and then get these little snipes
> along with the response. Hey, yeah, C99 allows the '//' comment. Oh
> my, intelligent adults will be unable to figure out how to deal with
> multiline comments! The end is nigh! Terr'ists surround us! ...that
> all besides the fact that when I was a wee lad the C compiler I used
> supported C++-style single-sine comments, and one tends to forget what
> features are in which standard when one uses more than one language.

Yes, we do tend to snipe. We deal with a *lot* of inexperienced C
programmers (some of whom have good questions but may not know the
best way to ask them) and, unfortunately, with a fair number of
deliberate trolls. At times our patience may wear a bit thin. We
are, of course, only human, and we make mistakes (I made a doozy here
just the other day). Ignore the snipes and you'll learn a lot here.

--
Keith Thompson (The_Other_Keith) kst- <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.

Keith Thompson wrote:

>> Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
>> put it in the standard do you figure?
>
>C has no concept of "sin" other than the trigonometric function. }

Ah very good.

>The idea that using typedefs for structure types is poor style is
>actually rather controversial. Chris Torek and I happen to agree on
>this point, but plenty of smart people don't.

Ok then.

It's been years since I "learned" C, but at the time the sage wisdom
who was providing me with guidance said I should /always/ typedef
structures, because a structure definition all by itself would yield
an unnamed instance of that structure right at that location. E.g.

struct something
{
int member;
};

This would deposit an unnamed "struct something" right there in the
translation unit (if that's the proper C vocabulary, anyway) where the
structure was defined. In these days of GHz processors an GB of RAM
that "problem" would certainly be less of an issue, and dead-stripping
linkers would also take care of it for you, but I don't feel too far
out on a limb by thinking that The Almighty Standard says nothing of
giga-anything nor of linking.

>Yes, we do tend to snipe. We deal with a *lot* of inexperienced C
>programmers (some of whom have good questions but may not know the
>best way to ask them) and, unfortunately, with a fair number of
>deliberate trolls.

Kill filters set on "save my sanity". Oof, they're not in The
Standard, either.

> Ignore the snipes and you'll learn a lot here.

Heh, with any luck we'll have this project rolled over to C++ in no
time at all. The gun's a lot more complicated but at least I
understand how it works.

thx,
-tom!

Tom Plunket said:

> Chris Torek wrote:
>
>>For those who insist on treating C as if it were C++...
>
> Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
> put it in the standard do you figure?

It's not a sin at all. It's a blessing from dmr himself, and we should be
grateful for it, and use it when it's appropriate to do so. Incidentally,
as someone else has already pointed out, the real sin is in the math
library. As it says in the Bible somewhere, don't cast stone[0] if you've
included <math.h>.

There are some smart people who think using typedef is a bad idea. I'm not
among them. Does that mean I'm not smart? Well, maybe it does. But I think
there's a lot of sense behind having a one-word name for a type. But I
would not go so far as to hide a pointer in a typedef - not even for
function pointers.

> As it is, I'm faced with a codebase that has many features which are
> undesirable. The sad catch-22 is that I don't know what many of the
> problems are 'til I ask about them, and then get these little snipes
> along with the response.

You're allowed to treat those with a pinch of salt if they're undeserved.

> Hey, yeah, C99 allows the '//' comment.

That's nice. When C99 becomes as portable as C90 is now, it may even become
relevant.

> Oh
> my, intelligent adults will be unable to figure out how to deal with
> multiline comments! The end is nigh! Terr'ists surround us! ...that
> all besides the fact that when I was a wee lad the C compiler I used
> supported C++-style single-sine comments,

Two coughs here. Firstly, single-sine? I thought we'd agreed it was sin!

Secondly, they are actually BCPL-style comments, and dmr took the
(presumably) deliberate (and, in my opinion, wise) decision to *omit* them
from C. It is true that bs chose to include them into C++, but he did not
invent them.

> and one tends to forget what
> features are in which standard when one uses more than one language.

Certainly true, especially when the syntaxes (syntaces? syntaxii?) are
ostensibly similar in so many ways.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Tom Plunket <> writes:
[...]
> It's been years since I "learned" C, but at the time the sage wisdom
> who was providing me with guidance said I should /always/ typedef
> structures, because a structure definition all by itself would yield
> an unnamed instance of that structure right at that location. E.g.
>
> struct something
> {
> int member;
> };
>
> This would deposit an unnamed "struct something" right there in the
> translation unit (if that's the proper C vocabulary, anyway) where the
> structure was defined. In these days of GHz processors an GB of RAM
> that "problem" would certainly be less of an issue, and dead-stripping
> linkers would also take care of it for you, but I don't feel too far
> out on a limb by thinking that The Almighty Standard says nothing of
> giga-anything nor of linking.

Hmm, I've never heard that argument. A struct declaration like the
one above does not create an anonymous object. (Even if it did, since
there would be no way to refer to it, any compiler worth its salt
would optimize it away.)

Logically, since this:

struct something {
int member;
} x, y;

creates two objects, and this:

struct something {
int member;
} x;

creates one object, then this:

struct something {
int member;
};

should create none.

--
Keith Thompson (The_Other_Keith) kst- <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.

Keith Thompson posted:


> Logically, since this:
>
> struct something {
> int member;
> } x, y;
>
> creates two objects, and this:
>
> struct something {
> int member;
> } x;
>
> creates one object, then this:
>
> struct something {
> int member;
> };
>
> should create none.


In the spirit of keeping things mathematical, maybe "should create zero
objects" would be a better way of putting it? ; )


--

Frederick Gotham

Tom Plunket posted:


> struct something
> {
> int member;
> };
>
> This would deposit an unnamed "struct something" right there in the
> translation unit (if that's the proper C vocabulary, anyway) where the
> structure was defined.


Common sense tells me that that would be a whoefully redundant thing to do.

Even in C++ -- where the definition of an object can result in the
execution of code -- it would still be ridiculous (C++ is full of all sorts
of optimizations like "Named Return Value Optimization").


--

Frederick Gotham

Frederick Gotham <> writes:
> Keith Thompson posted:
>> Logically, since this:
>>
>> struct something {
>> int member;
>> } x, y;
>>
>> creates two objects, and this:
>>
>> struct something {
>> int member;
>> } x;
>>
>> creates one object, then this:
>>
>> struct something {
>> int member;
>> };
>>
>> should create none.
>
> In the spirit of keeping things mathematical, maybe "should create zero
> objects" would be a better way of putting it? ; )

In the spirit of reading and writing plain English, I thought (and
still think) that the word "none" is perfectly clear.

--
Keith Thompson (The_Other_Keith) kst- <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.

On Mon, 26 Jun 2006 15:01:00 -0700, Tom Plunket <>
wrote:

<snip>
> It's been years since I "learned" C, but at the time the sage wisdom
> who was providing me with guidance said I should /always/ typedef
> structures, because a structure definition all by itself would yield
> an unnamed instance of that structure right at that location. E.g.
>
> struct something
> {
> int member;
> };
>
Does not, and never did, as already said.

Are you sure you, or your guide, didn't misunderstand or misremember
the issue of including or omitting a struct _tag_?

struct { elements } zorg;
creates an 'anonymous' struct type, which you cannot refer to later --
i.e. you cannot create another variable, or a pointer to one, or a
function argument, etc., which the compiler will recognize as the same
type. (Unlike some other non-C languages, which do use so called
'structural' or 'deep' type compatibility.)

struct good { elements } lelu;
creates a variable _and_ a tag (type) which you can use later.
struct good { elements };
creates _only_ the tag (type). Which you can use later,
and that is the only way to use it, so if you don't, it's useless

<OT> In C++, the tag name(s) in the latter form are available as
typenames by themselves, in addition to 'struct good' as in C (which
is still permitted). People often say loosely that C++ automatically
does typedef for you, but this isn't strictly right; even in C++ you
can still declare both an ordinary-identifier foo and a tag foo in the
same scope, but it is very bad style, even worse than it is in C.

- David.Thompson1 at worldnet.att.net

Keith Thompson wrote:
> Tom Plunket <> writes:
> > Chris Torek wrote:
> >>For those who insist on treating C as if it were C++...
> >
> > Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
> > put it in the standard do you figure?
>
> C has no concept of "sin" other than the trigonometric function. }
>
> The idea that using typedefs for structure types is poor style is
> actually rather controversial. Chris Torek and I happen to agree on
> this point, but plenty of smart people don't.
>
> An argument in favor of using a typedef is that it provides a one-word
> name for a type. In my opinion, that's not a strong enough reason to
> use it.

Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.

If client code should view the type as opaque, then
using typedef for a struct type makes sense.

If client code should view a struct transparently,
then no typedef - just use struct.

In my programming, I tend to use abstraction rather
a lot, so usually types are typedef'ed. But I
understand both modes, and use either, as appropriate.

There is one typedef idiom that bears mentioning:

typedef struct { ... } *Foo;

This idiom is useful when the underlying structs
should always be malloc'ed, never static or auto.
Because of how the type is declared, no code will
have these structs other than {m,c,re}alloc()'ed
ones.

writes:
> Keith Thompson wrote:
>> Tom Plunket <> writes:
>> > Chris Torek wrote:
>> >>For those who insist on treating C as if it were C++...
>> >
>> > Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
>> > put it in the standard do you figure?
>>
>> C has no concept of "sin" other than the trigonometric function. }
>>
>> The idea that using typedefs for structure types is poor style is
>> actually rather controversial. Chris Torek and I happen to agree on
>> this point, but plenty of smart people don't.
>>
>> An argument in favor of using a typedef is that it provides a one-word
>> name for a type. In my opinion, that's not a strong enough reason to
>> use it.
>
> Usually the best argument in favor of using a typedef
> is that the name defined reflects how you want client
> code to view the type.
>
> If client code should view the type as opaque, then
> using typedef for a struct type makes sense.
>
> If client code should view a struct transparently,
> then no typedef - just use struct.
>
> In my programming, I tend to use abstraction rather
> a lot, so usually types are typedef'ed. But I
> understand both modes, and use either, as appropriate.
>
> There is one typedef idiom that bears mentioning:
>
> typedef struct { ... } *Foo;
>
> This idiom is useful when the underlying structs
> should always be malloc'ed, never static or auto.
> Because of how the type is declared, no code will
> have these structs other than {m,c,re}alloc()'ed
> ones.

In that case, it would probably make sense to hide the *alloc() and
free() calls behind some type-specific functions; the *alloc()
wrappers could also do any necessary initialization of the struct
members. This is basically what fopen() and fclose() do, except that
the pointer isn't hidden behind a typedef; the members of the
structure are effectively hidden not by the fact that there's no name
for the structure type (there is, FILE), but by the fact that the
details are undocumented, and code that depends on them will break
when ported.

--
Keith Thompson (The_Other_Keith) kst- <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.