Am I being too C++ like?

[Kaz Kylheku]

If "struct" is long and ugly, how about "typedef"?

The typedef is in one place; the "struct foo" is repeated in all declarations
involving that type.

 

[Ike Naar]

The typedef is in one place; the "struct foo" is repeated in all declarations
involving that type.

Exactly. And if "all" is a small number, using a typedef to avoid
clutter can be counterprodutive.

 

[Ian Collins]

Exactly. And if "all" is a small number, using a typedef to avoid
clutter can be counterprodutive.

Where small = 1 and one sixth?

 

[Guest]

If "struct" is long and ugly, how about "typedef"?

typedef only appears once. Without the typedef struct appears many times.

What's more, in C++ you don't have to scatter "typedef" keywords about
the place either ;-)

you've not used the STL then?

 

[Guest]

(e-mail address removed) writes:

[responding selectively, mostly without the usual 'snip' indicators]

that's fine, I probably over-use 'em- occaisional encounter with people who scream "unmarked snip!!!!" everytime it happens.

but that's not the only reason that people typedef structs. I do it
becasue I think the syntax is poor. I hide other hard-to-read
declaration syntax behind typedefs for the same reason. I don't do it
because I got confused about opaque types.

So I don't think they have "learned the wrong lesson"

The lesson I was talking about is "don't use typedefs". I
think you and I are in agreement that this is not the
right lesson.
ok

[confusion about naming between tags and typedef names]

To my way of thinking the main reason to use typedef names
is to encourage use of information hiding and viewing of
various entities as abstract data types.
[...]

I agree that that's the main *appropriate* reason to use typedefs for
structs. Unfortunately, it's not the main reason programmers actually
use them.

But that's a reason to talk about information hiding, ADT's, and
opaque types /more/, not to insist more strenuously that typedefs
shouldn't be used. If you show examples of where it's good to
typedef a struct, that will both strengthen an understanding of
information hiding and ADT's, etc, and also make comments about
when /not/ to use typedefs more effective.

always supposing the heavy typedefers actually /are/ confused

I think you and I are pretty close on this issue actually, but
let me restate my comment from another perspective. What are
some examples where using typedef's makes sense,

Do Use Typedef:
enums (same argument as struct), unions maybe (I never use 'em), function pointers (really gnarly syntax) [1], opaque types (I don't bother - C's FILE* looks opaque enough to me), domain specific types [2].

Don't Use Typedef:-
pointers, arrays, I think U16, U32 and Microsoft's pile of wierd types are over used [3]

[1] I used to use
typedef int (*FuncPtr) (double);
FuncPtr fp = someFunc;
Now I use
typedef int (Func) (double);
Func* fp = someFunc;
So the pointeriness is more explicit

[2] CallIdent, Byte, Octet, Latitude

[3] U64 might be justified as the actual type used still varies quite a bit and I don't, yet, use 64-bit quantities very much








and some other

examples where using typedef's does not make sense? I believe
giving both kinds of examples will produce a better result.

(e-mail address removed) writes:

[responding selectively, mostly without the usual 'snip' indicators]

but that's not the only reason that people typedef structs. I do it
becasue I think the syntax is poor. I hide other hard-to-read
declaration syntax behind typedefs for the same reason. I don't do it
because I got confused about opaque types.

So I don't think they have "learned the wrong lesson"

The lesson I was talking about is "don't use typedefs". I
think you and I are in agreement that this is not the
right lesson.

[confusion about naming between tags and typedef names]

To my way of thinking the main reason to use typedef names
is to encourage use of information hiding and viewing of
various entities as abstract data types.
[...]

I agree that that's the main *appropriate* reason to use typedefs for
structs. Unfortunately, it's not the main reason programmers actually
use them.

But that's a reason to talk about information hiding, ADT's, and
opaque types /more/, not to insist more strenuously that typedefs
shouldn't be used. If you show examples of where it's good to
typedef a struct, that will both strengthen an understanding of
information hiding and ADT's, etc, and also make comments about
when /not/ to use typedefs more effective.

always supposing the heavy typedefers actually /are/ confused

I think you and I are pretty close on this issue actually, but
let me restate my comment from another perspective. What are
some examples where using typedef's makes sense, and some other
examples where using typedef's does not make sense? I believe
giving both kinds of examples will produce a better result.

(e-mail address removed) writes:

[responding selectively, mostly without the usual 'snip' indicators]

but that's not the only reason that people typedef structs. I do it
becasue I think the syntax is poor. I hide other hard-to-read
declaration syntax behind typedefs for the same reason. I don't do it
because I got confused about opaque types.

So I don't think they have "learned the wrong lesson"

The lesson I was talking about is "don't use typedefs". I
think you and I are in agreement that this is not the
right lesson.

[confusion about naming between tags and typedef names]

To my way of thinking the main reason to use typedef names
is to encourage use of information hiding and viewing of
various entities as abstract data types.
[...]

I agree that that's the main *appropriate* reason to use typedefs for
structs. Unfortunately, it's not the main reason programmers actually
use them.

But that's a reason to talk about information hiding, ADT's, and
opaque types /more/, not to insist more strenuously that typedefs
shouldn't be used. If you show examples of where it's good to
typedef a struct, that will both strengthen an understanding of
information hiding and ADT's, etc, and also make comments about
when /not/ to use typedefs more effective.

always supposing the heavy typedefers actually /are/ confused

I think you and I are pretty close on this issue actually, but
let me restate my comment from another perspective. What are
some examples where using typedef's makes sense, and some other
examples where using typedef's does not make sense? I believe
giving both kinds of examples will produce a better result.