Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15924 > unrolled thread

Am I being too C++ like?

Back to article view | Back to comp.lang.c

Contents

  Am I being too C++ like? nroberts <roberts.noah@gmail.com> - 2012-01-18 13:53 -0800
    Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-18 18:50 -0500
      Re: Am I being too C++ like? Nobody <nobody@nowhere.com> - 2012-01-19 04:13 +0000
      Re: Am I being too C++ like? ImpalerCore <jadill33@gmail.com> - 2012-01-19 09:09 -0800
    Re: Am I being too C++ like? Philip Lantz <prl@canterey.us> - 2012-01-18 21:42 -0800
    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-19 12:30 +0000
      Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-19 15:17 +0000
        Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-19 18:44 -0800
          Re: Am I being too C++ like? "BartC" <bc@freeuk.com> - 2012-01-20 13:44 +0000
            Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 09:08 -0500
              Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 07:58 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 11:25 -0800
              Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 20:17 +0000
                Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 09:23 +1300
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-20 22:00 +0000
                  Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-01-20 16:28 -0600
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 11:43 +1300
                    Re: Am I being too C++ like? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-20 18:02 -0500
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 16:12 -0800
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 00:13 +0000
                        Re: Am I being too C++ like? William Ahern <william@wilbur.25thandClement.com> - 2012-01-20 17:37 -0800
                          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-20 22:25 -0800
                            Re: Am I being too C++ like? gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-21 16:07 +0000
                              Re: Am I being too C++ like? Bill Reid <hormelfree@gmail.com> - 2012-01-23 17:26 -0800
                          Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-01-21 18:00 +0000
                            Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-21 21:25 +0000
                              Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-11 23:46 +0200
                                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 22:56 +0000
                                  Re: Am I being too C++ like? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:34 +0200
                            Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-21 22:42 +0100
                            Re: Am I being too C++ like? James Kuyper <jameskuyper@verizon.net> - 2012-01-21 21:22 -0500
                              Re: Am I being too C++ like? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-22 14:56 +0100
                        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:29 +1300
                    Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-21 11:36 +0000
                Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-22 12:13 +0000
                  Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-22 12:39 +0000
                    Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:45 +0000
                      Re: Am I being too C++ like? Kleuske <kleuske@nowhere.net> - 2012-01-24 16:54 +0000
              Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 04:43 -0800
                Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-22 15:29 +0000
            Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-21 11:58 +0000
            Re: Am I being too C++ like? Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
    Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-19 04:23 -0800
      Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:39 +0000
      Re: Am I being too C++ like? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-22 05:14 -0800
        Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-23 23:42 +0000
    Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-01-19 14:51 +0000
    Re: Am I being too C++ like? jgk@panix.com (Joe keane) - 2012-01-19 23:04 +0000
    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-20 16:03 +1300
      Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-20 06:01 -0800
        Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-21 08:03 +1300
          Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-21 12:31 -0800
            Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:18 +1300
    Re: Am I being too C++ like? cri@tiac.net (Richard Harter) - 2012-01-20 05:22 +0000
    Re: Am I being too C++ like? Marco <prenom_nomus@yahoo.com> - 2012-01-21 07:29 -0800
      Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-24 12:13 +0000
        Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 14:32 -0800
          Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 15:32 -0800
            Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 19:46 -0800
            Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-01-31 23:54 -0500
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-01-31 22:24 -0800
            Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:28 -0800
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:23 -0800
                Re: Am I being too C++ like? Stephen Sprunk <stephen@sprunk.org> - 2012-02-01 15:01 -0600
                  Re: Am I being too C++ like? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-01 14:09 -0800
                    Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 14:44 -0800
                  Re: Am I being too C++ like? Shao Miller <sha0.miller@gmail.com> - 2012-02-01 17:36 -0500
                Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 12:45 -0800
                  Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-08 21:41 +0000
                    Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-09 17:42 +1300
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-09 08:12 +0000
                        Re: Am I being too C++ like? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-09 12:01 +0000
                  Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-03-08 14:19 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:32 -0800
                  Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-09 04:18 -0800
                    Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-09 13:04 +0000
                      Re: Am I being too C++ like? Kaz Kylheku <kaz@kylheku.com> - 2012-03-10 01:02 +0000
                        Re: Am I being too C++ like? Ike Naar <ike@iceland.freeshell.org> - 2012-03-10 07:59 +0000
                          Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 21:17 +1300
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:39 -0800
                    Re: Am I being too C++ like? Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:51 -0800
                      Re: Am I being too C++ like? nick_keighley_nospam@hotmail.com - 2012-03-10 02:54 -0800
              Re: Am I being too C++ like? Ian Collins <ian-news@hotmail.com> - 2012-03-10 12:27 +1300
            Re: Am I being too C++ like? Rui Maciel <rui.maciel@gmail.com> - 2012-02-01 07:41 +0000
              Re: Am I being too C++ like? Keith Thompson <kst-u@mib.org> - 2012-02-01 11:24 -0800
          Re: Am I being too C++ like? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-01 21:55 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#16569

Shao Miller <sha0.miller@gmail.com> writes:
> On 1/31/2012 18:32, Keith Thompson wrote:
>> A typedef for a struct type creates a new name (such as "foo") for a
>> type that already has a perfectly valid name (such as "struct foo").
>> The "struct foo" name still has to be used inside the struct
>> definition if the type declares a pointer to the same type (unless
>> you use a forward declaration).  Using distinct identifiers for the
>> tag and the typedef name, which is very common, can lead to
>> confusion.
[I've corrected the wording in the above paragraph]
>> Using a typedef for a struct type has few benefits.  The drawbacks are
>> not terribly serious if you do it right, but in my opinion the benefits
>> are minor enough that it's not worth doing.
>>
>> Of course if you think that having a one-word name for a type is a
>> significant benefit, then you're going to disagree with this argument.
>>
>
> If I have 'struct cat' and want an instance, or even a pointer to such, 
> I might like to name the instance (or pointer) 'cat'.
>
>    struct cat * cat;

That's perfectly legal, since the two "cat"s are in different
namespaces.

But it's a bad idea; surely if the type is "cat" or "struct cat", the
name of a single instance of the type should have a more specific name.
If nothing else, you could call it "the_cat".

> But that's no good, so maybe I'd do:
>
>    struct s_cat * cat;
>
> That seems better, but if I have the 's_' there to indicate a 'struct' 
> type, I might as well 'typedef' it:
>
>    typedef struct s_cat s_cat; /* or maybe */
>    typedef struct s_cat S_CAT;
>    S_CAT * cat;

That all seems unnecessary.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16573

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Sat, 2012-01-21, Marco wrote:
>>> ...
>>>> keep using typedef ignore the naysayers
>>>
>>> If you really care, you should really provide some arguments,
>>> like us "naysayers" did ...
>>
>> You mean arguments like "I don't like using typedefs"?  I didn't
>> see any comments in this thread that amounted to anything more
>> than a statement of personal preference or opinion, from those
>> opposing the use of typedefs.  OTOH, there were several comments
>> from people in favor of typedefs that gave reasons to prefer
>> typedefs (in some cases) that are at least somewhat objective,
>> rather than just stating a preference.
>
> A typedef for a struct type creates a new name (such as "foo") for a
> type that already has a perfectly valid name (such as "struct foo").

Not necessarily;  as long as struct type is not self-referential,
it can be typedef'ed without using a tag.

> The "struct foo" name still has to be used inside the struct definition
> if the type declares a pointer to the same type (unless you use a
> forward declaration).

The cost of doing either of those is small.  Besides, the most
important use case for typedef'ing a struct is to make a
(mostly) opaque type, in which case the header file will
forward-declare the struct type (without defining its contents)
along with the typedef, so the incremental cost of doing
a forward declaration is zero.

> Using distinct identifiers for the tag and the typedef name are
> different identifers, which is very common, can lead to confusion.

I can't really parse your sentence, but in any case it seems
mostly orthogonal to the question about whether it's a good
idea to use a typedef.  Even though tags and typedef names
are in different name spaces, there can be confusion between
them, and they should be chosen with that possibility kept in
mind.  It's easy to avoid confusion just by following some
sort of naming convention, such as (for example) appending
an '_s' to any struct tag that has an associated typedef.
(Or whatever other convention is suitable for the context,
that was meant just as an example.)


> Using a typedef for a struct type has few benefits.  The
> drawbacks are not terribly serious if you do it right, but
> in my opinion the benefits are minor enough that it's not
> worth doing.

You haven't listed any of what you think are benefits.
I'm curious to know what those might be.


> Of course if you think that having a one-word name for a type
> is a significant benefit, then you're going to disagree with
> this argument.

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.  In most cases, as
far as client code codes, the less one knows about a data
type the better;  similarly, the more a type is treated as
an abstract data type, the better.  The main cost of using
raw struct types is not in the typing but in the thinking:
for most code, not only do I not want to know what sort of
thing is being handled, I want NOT to know, because knowing
clutters ones thinking.  Using a typedef name doesn't
prevent me from knowing (since after all I can go look at
the typedef in whatever header file defines it), but it
makes it easy not to know if one is so inclined.  (And
those not so inclined can always just go look...)

[toc] | [prev] | [next] | [standalone]

#16604

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>
>>>> On Sat, 2012-01-21, Marco wrote:
>>>> ...
>>>>> keep using typedef ignore the naysayers
>>>>
>>>> If you really care, you should really provide some arguments,
>>>> like us "naysayers" did ...
>>>
>>> You mean arguments like "I don't like using typedefs"?  I didn't
>>> see any comments in this thread that amounted to anything more
>>> than a statement of personal preference or opinion, from those
>>> opposing the use of typedefs.  OTOH, there were several comments
>>> from people in favor of typedefs that gave reasons to prefer
>>> typedefs (in some cases) that are at least somewhat objective,
>>> rather than just stating a preference.
>>
>> A typedef for a struct type creates a new name (such as "foo") for a
>> type that already has a perfectly valid name (such as "struct foo").
>
> Not necessarily;  as long as struct type is not self-referential,
> it can be typedef'ed without using a tag.

True.  But that creates an artificial distinction between
self-referential and non-self-referential structs.  My point is
that if you have a tag, you don't need a typedef.

>> The "struct foo" name still has to be used inside the struct definition
>> if the type declares a pointer to the same type (unless you use a
>> forward declaration).
>
> The cost of doing either of those is small.  Besides, the most
> important use case for typedef'ing a struct is to make a
> (mostly) opaque type, in which case the header file will
> forward-declare the struct type (without defining its contents)
> along with the typedef, so the incremental cost of doing
> a forward declaration is zero.

Yes, if you want an opaque type, a typedef is perfectly appropriate; I
should have mentioned that.  By "opaque" in this case, I mean that the
code that uses the type doesn't need to know or care that the type is a
struct.

I haven't seen a whole lot of code like that.  It's more common, at
least in code I've seen, to declare a typedef for a struct type and then
write code that freely refers to its members.

>> Using distinct identifiers for the tag and the typedef name are
>> different identifers, which is very common, can lead to confusion.
>
> I can't really parse your sentence,

Bad editing on my part; delete "are different identifiers".

>                                     but in any case it seems
> mostly orthogonal to the question about whether it's a good
> idea to use a typedef.  Even though tags and typedef names
> are in different name spaces, there can be confusion between
> them, and they should be chosen with that possibility kept in
> mind.  It's easy to avoid confusion just by following some
> sort of naming convention, such as (for example) appending
> an '_s' to any struct tag that has an associated typedef.
> (Or whatever other convention is suitable for the context,
> that was meant just as an example.)

Too may programmers *don't* follow any particular convention.
I see plenty of code like:

    typedef struct foo {
        /* ... */
    } bar;

where the names "foo" and "bar" don't have any particular relationship.

Strictly following some naming convention (like "typedef struct foo_s {
... } foo") is better, but that's still two different identifiers to
keep track of.  Using the same identifier for both is even better.
>
>> Using a typedef for a struct type has few benefits.  The
>> drawbacks are not terribly serious if you do it right, but
>> in my opinion the benefits are minor enough that it's not
>> worth doing.
>
> You haven't listed any of what you think are benefits.
> I'm curious to know what those might be.

I mentioned it later: it gives the type a name that's a single
identifier, and saves a little typing.
>
>> Of course if you think that having a one-word name for a type
>> is a significant benefit, then you're going to disagree with
>> this argument.
>
> 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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16617

On 01-Feb-12 13:23, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> The cost of doing either of those is small.  Besides, the most
>> important use case for typedef'ing a struct is to make a
>> (mostly) opaque type, in which case the header file will
>> forward-declare the struct type (without defining its contents)
>> along with the typedef, so the incremental cost of doing
>> a forward declaration is zero.
> 
> Yes, if you want an opaque type, a typedef is perfectly appropriate; I
> should have mentioned that.  By "opaque" in this case, I mean that the
> code that uses the type doesn't need to know or care that the type is a
> struct.
> 
> I haven't seen a whole lot of code like that.

What about FILE?  Is there any implementation where that "opaque" type
_isn't_ actually a struct?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#16620

On Feb 1, 9:01 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>
> What about FILE?  Is there any implementation where that "opaque" type
> _isn't_ actually a struct?
>
Originally integers were used as file ids. This is still the system
with Fortran. Hence stdin, stdout and stderr could be simple defines.

[toc] | [prev] | [next] | [standalone]

#16622

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Feb 1, 9:01 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>> What about FILE?  Is there any implementation where that "opaque" type
>> _isn't_ actually a struct?
>>
> Originally integers were used as file ids. This is still the system
> with Fortran. Hence stdin, stdout and stderr could be simple defines.

POSIX still uses small int values as file descriptors.  Typically the
stdio mechanism is built on top of that.  For example, open() returns an
int file descriptor, whereas fopen() returns a FILE*.

The requirement in the standard is:

    FILE ... is an object type capable of recording all the information
    needed to control a stream, including its file position indicator, a
    pointer to its associated buffer (if any), an *error indicator* that
    records whether a read/write error has occurred, and an *end-of-file
    indicator* that records whether the end of the file has been reached

Assuming that the object type doesn't have to *directly* record all
this information, then FILE could easily be a typedef for int, with
the value used to index an array containing the actual information
(or some other scheme).

Certainly an implementation *could* make FILE something other than
a struct.  The question is whether any actually do so.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16621

On 2/1/2012 16:01, Stephen Sprunk wrote:
> On 01-Feb-12 13:23, Keith Thompson wrote:
>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>> The cost of doing either of those is small.  Besides, the most
>>> important use case for typedef'ing a struct is to make a
>>> (mostly) opaque type, in which case the header file will
>>> forward-declare the struct type (without defining its contents)
>>> along with the typedef, so the incremental cost of doing
>>> a forward declaration is zero.
>>
>> Yes, if you want an opaque type, a typedef is perfectly appropriate; I
>> should have mentioned that.  By "opaque" in this case, I mean that the
>> code that uses the type doesn't need to know or care that the type is a
>> struct.
>>
>> I haven't seen a whole lot of code like that.
>
> What about FILE?  Is there any implementation where that "opaque" type
> _isn't_ actually a struct?
>

It can be an integer to index into a fixed-size array of structs, where 
there is a maximum number of open files.  I've seen this in the 
boot-loader for a particular OS, I believe.

-- 
"The stationery store has moved.  Aaargh!"

[toc] | [prev] | [next] | [standalone]

#18348

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>>
>>>>> On Sat, 2012-01-21, Marco wrote:
>>>>> ...
>>>>>> keep using typedef ignore the naysayers
>>>>>
>>>>> If you really care, you should really provide some arguments,
>>>>> like us "naysayers" did ...
>>>>
>>>> You mean arguments like "I don't like using typedefs"?  I didn't
>>>> see any comments in this thread that amounted to anything more
>>>> than a statement of personal preference or opinion, from those
>>>> opposing the use of typedefs.  OTOH, there were several comments
>>>> from people in favor of typedefs that gave reasons to prefer
>>>> typedefs (in some cases) that are at least somewhat objective,
>>>> rather than just stating a preference.
>>>
>>> A typedef for a struct type creates a new name (such as "foo") for a
>>> type that already has a perfectly valid name (such as "struct foo").
>>
>> Not necessarily;  as long as struct type is not self-referential,
>> it can be typedef'ed without using a tag.
>
> True.  But that creates an artificial distinction between
> self-referential and non-self-referential structs.  My point is
> that if you have a tag, you don't need a typedef.

It's not a distinction, just an observation.  I already understood
the point;  I was just making a factual correction.


>>> The "struct foo" name still has to be used inside the struct definition
>>> if the type declares a pointer to the same type (unless you use a
>>> forward declaration).
>>
>> The cost of doing either of those is small.  Besides, the most
>> important use case for typedef'ing a struct is to make a
>> (mostly) opaque type, in which case the header file will
>> forward-declare the struct type (without defining its contents)
>> along with the typedef, so the incremental cost of doing
>> a forward declaration is zero.
>
> Yes, if you want an opaque type, a typedef is perfectly appropriate; I
> should have mentioned that.  By "opaque" in this case, I mean that the
> code that uses the type doesn't need to know or care that the type is a
> struct.
>
> I haven't seen a whole lot of code like that.  It's more common, at
> least in code I've seen, to declare a typedef for a struct type and then
> write code that freely refers to its members.

That's easy to believe, and I think part of the reason for that
happening is lots of people giving blanket advice like "don't use
typedefs for structs" rather than talking about opaque types and
why it's good to use them.  Hearing so many comments about not
using typedefs, it's easy for people to come away with the wrong
lesson.


>>> Using distinct identifiers for the tag and the typedef name are
>>> different identifers, which is very common, can lead to confusion.
>>
>> I can't really parse your sentence,
>
> Bad editing on my part; delete "are different identifiers".
>
>>                                     but in any case it seems
>> mostly orthogonal to the question about whether it's a good
>> idea to use a typedef.  Even though tags and typedef names
>> are in different name spaces, there can be confusion between
>> them, and they should be chosen with that possibility kept in
>> mind.  It's easy to avoid confusion just by following some
>> sort of naming convention, such as (for example) appending
>> an '_s' to any struct tag that has an associated typedef.
>> (Or whatever other convention is suitable for the context,
>> that was meant just as an example.)
>
> Too may programmers *don't* follow any particular convention.
> I see plenty of code like:
>
>     typedef struct foo {
>         /* ... */
>     } bar;
>
> where the names "foo" and "bar" don't have any particular relationship.
>
> Strictly following some naming convention (like "typedef struct foo_s {
> ... } foo") is better, but that's still two different identifiers to
> keep track of.  Using the same identifier for both is even better.

Actually I don't agree with this last piece of advice, but it
should be mostly irrelevant because properly done a struct
that is typedef'ed has its tag appear in a very small number of
places, ideally just two or three.


>>> Using a typedef for a struct type has few benefits.  The
>>> drawbacks are not terribly serious if you do it right, but
>>> in my opinion the benefits are minor enough that it's not
>>> worth doing.
>>
>> You haven't listed any of what you think are benefits.
>> I'm curious to know what those might be.

Promoting opaque types, and information hiding, are two of the
most important.

> I mentioned it later: it gives the type a name that's a single
> identifier, and saves a little typing.

More importantly, it saves horizontal space, which can be
important in places like function prototypes.


>>> Of course if you think that having a one-word name for a type
>>> is a significant benefit, then you're going to disagree with
>>> this argument.
>>
>> 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 typedef'ing
is bad;  never typedef'ing is bad.  A good developer needs to
understand the problems of both extremes.

[toc] | [prev] | [next] | [standalone]

#18356

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Keith Thompson <kst-u@mib.org> writes:
[on typedef structs]

>> I mentioned it later: it gives the type a name that's a single
>> identifier, and saves a little typing.
>
> More importantly, it saves horizontal space, which can be
> important in places like function prototypes.

Pet peeve: why can't C's usual declaration syntax be used in function
prototypes (and definitions)?  I.e.:

  int memcmp(const void *s1, *s2; size_t n);

It seems a shame to me.  I wonder if it was every considered.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18371

On 03/ 9/12 10:41 AM, Ben Bacarisse wrote:
> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>
>> Keith Thompson<kst-u@mib.org>  writes:
> [on typedef structs]
>
>>> I mentioned it later: it gives the type a name that's a single
>>> identifier, and saves a little typing.
>>
>> More importantly, it saves horizontal space, which can be
>> important in places like function prototypes.
>
> Pet peeve: why can't C's usual declaration syntax be used in function
> prototypes (and definitions)?  I.e.:
>
>    int memcmp(const void *s1, *s2; size_t n);
>
> It seems a shame to me.  I wonder if it was every considered.

It doesn't work very well if the parameters aren't named in a function 
declaration.  You can't have a nameless variable declaration, but you 
can have a nameless parameter in a function declaration.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#18372

On 2012-03-09, Ian Collins <ian-news@hotmail.com> wrote:
> On 03/ 9/12 10:41 AM, Ben Bacarisse wrote:
>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>
>>> Keith Thompson<kst-u@mib.org>  writes:
>> [on typedef structs]
>>
>>>> I mentioned it later: it gives the type a name that's a single
>>>> identifier, and saves a little typing.
>>>
>>> More importantly, it saves horizontal space, which can be
>>> important in places like function prototypes.
>>
>> Pet peeve: why can't C's usual declaration syntax be used in function
>> prototypes (and definitions)?  I.e.:
>>
>>    int memcmp(const void *s1, *s2; size_t n);
>>
>> It seems a shame to me.  I wonder if it was every considered.
>
> It doesn't work very well if the parameters aren't named in a function 
> declaration.  You can't have a nameless variable declaration, but you 

Is there a syntactic issue with a nameless declaration with multiple
abstract declarators like void *, *, **; ? Off the top of my head,
I can't see it.

(Suppose there is an issue; that can simply be disallowed. You can't
use that to write nameless paramters, but if there is just one declarator,
then you can. No need to throw out the concept just because it can't
"do" nameless params.)

Those should be allowed in structures too. It could be useful for padding.
Such a member would be initialized when the struct is initialized.

union { int x; char [256]; }; /* unnamed padding */

There exists an extension for unnamed unions in some compilers.
That works out:

struct { union { int x; int y }; int z };

That union is an unnamed member like char [256];

[toc] | [prev] | [next] | [standalone]

#18383

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-03-09, Ian Collins <ian-news@hotmail.com> wrote:
>> On 03/ 9/12 10:41 AM, Ben Bacarisse wrote:
>>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>>
>>>> Keith Thompson<kst-u@mib.org>  writes:
>>> [on typedef structs]
>>>
>>>>> I mentioned it later: it gives the type a name that's a single
>>>>> identifier, and saves a little typing.
>>>>
>>>> More importantly, it saves horizontal space, which can be
>>>> important in places like function prototypes.
>>>
>>> Pet peeve: why can't C's usual declaration syntax be used in function
>>> prototypes (and definitions)?  I.e.:
>>>
>>>    int memcmp(const void *s1, *s2; size_t n);
>>>
>>> It seems a shame to me.  I wonder if it was every considered.
>>
>> It doesn't work very well if the parameters aren't named in a function 
>> declaration.  You can't have a nameless variable declaration, but you 
>
> Is there a syntactic issue with a nameless declaration with multiple
> abstract declarators like void *, *, **; ? Off the top of my head,
> I can't see it.

No, I can't see how there can be.  Currently, a comma ends a full
parameter declaration (named or nameless) but restoring its role as a
terminator for just the declarator (as in normal, non-prototype,
declarations) seems harmless.  It may even be possible to have this
syntax co-exit with the correct one, though that was not my original
point -- I can't see any hope of a change now.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18360

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
>>> 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 typedef'ing
> is bad;  never typedef'ing is bad.  A good developer needs to
> understand the problems of both extremes.

Ok, let me refine my stated position.

For a struct type that's not opaque, i.e., where the code that
uses the type is expected to refer to its members by name, I see
very little reason to use a typedef.  My personal preference in
such cases is to declare the type with a tag, like "struct foo",
and then consistently refer to the type as "struct foo".  The only
benefit of a typedef is to provide a one-word name for a type that
already has a two-word name.  A drawback is that, in practice,
programmers don't use consistent conventions for the tag name and
the typedef name (using the same identifier for both alleviates
that problem).  Another drawback is that you still need a tag for
self-referential types, but not for non-self-referential types,
a distinction that isn't necessary if you just use the tag.

I don't *strongly* feel that typedefs for such structs are a bad idea.
Having a one-word name for a type is of *some* benefit.  I don't mind
tha fact that C++ in effect does this for you.

For a type that's truly opaque, i.e., where the code that uses it never
refers to members by name, a typedef is appropriate.  In such cases,
having to refer to the type as "struct foo" unnecessarily leaks
information: client code shouldn't have to care that the type is a
struct.  You should be able to change the type from a struct to an
integer without breaking client code.  The type FILE in <stdio.h>
is a good example of this.

But I find that the former case is much more common than the latter.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#18404

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>>>> 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.  [snip]
>
> Ok, let me refine my stated position.  [snip]

A step in the right direction, I appreciate that.  Just
two comments:

one:  for future reference, I think it would help to
show examples of the different kinds of use cases, not
just describe them;

two:  opaque types, ADT's, information hiding and OOP are
all related concepts but aren't exactly the same.  Some
times it's okay to lump them all together, other times
it's important to distinguish them and talk about them
separately.  I don't mean to offer advice about which
is which, only that it's important to think about in
which cases they should be distinguished and which not.

[toc] | [prev] | [next] | [standalone]

#18387

On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >> Keith Thompson <kst-u@mib.org> writes:
> >>> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> >>>>> On Sat, 2012-01-21, Marco wrote:


> >>>>>> keep using typedef ignore the naysayers

<snip>

> >>> A typedef for a struct type creates a new name (such as "foo") for a
> >>> type that already has a perfectly valid name (such as "struct foo").

yes but its a long ugly name. The C++ people seem to agree, once you've defined a struct you don't have to scatter "struct" keywords about the place.

<snip>

> >> [...] the most
> >> important use case for typedef'ing a struct is to make a
> >> (mostly) opaque type, 

"...an important reason for typedef'ing a struct is to make an opaque type"

<snip>

> > Yes, if you want an opaque type, a typedef is perfectly 
> > appropriate; I should have mentioned that.  By "opaque" in this 
> > case, I mean that the code that uses the type doesn't need to 
> > know or care that the type is a struct.
> >
> > I haven't seen a whole lot of code like that.  It's more common, at
> > least in code I've seen, to declare a typedef for a struct type 
> > and then write code that freely refers to its members.
> 
> That's easy to believe, and I think part of the reason for that
> happening is lots of people giving blanket advice like "don't use
> typedefs for structs" rather than talking about opaque types and
> why it's good to use them.  Hearing so many comments about not
> using typedefs, it's easy for people to come away with the wrong
> lesson.

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"

> >>> Using distinct identifiers for the tag and the typedef name are
> >>> different identifers, which is very common, can lead to confusion.
> >>
> >> I can't really parse your sentence,
> >
> > Bad editing on my part; delete "are different identifiers".
> >
> >>                                     but in any case it seems
> >> mostly orthogonal to the question about whether it's a good
> >> idea to use a typedef.  Even though tags and typedef names
> >> are in different name spaces, there can be confusion between
> >> them, and they should be chosen with that possibility kept in
> >> mind.  It's easy to avoid confusion just by following some
> >> sort of naming convention, such as (for example) appending
> >> an '_s' to any struct tag that has an associated typedef.
> >> (Or whatever other convention is suitable for the context,
> >> that was meant just as an example.)
> >
> > Too may programmers *don't* follow any particular convention.
> > I see plenty of code like:
> >
> >     typedef struct foo {
> >         /* ... */
> >     } bar;
> >
> > where the names "foo" and "bar" don't have any particular relationship.
> >
> > Strictly following some naming convention (like "typedef struct foo_s {
> > ... } foo") is better, but that's still two different identifiers to
> > keep track of.  Using the same identifier for both is even better.
> 
> Actually I don't agree with this last piece of advice, but it
> should be mostly irrelevant because properly done a struct
> that is typedef'ed has its tag appear in a very small number of
> places, ideally just two or three.
> 
> 
> >>> Using a typedef for a struct type has few benefits.  The
> >>> drawbacks are not terribly serious if you do it right,

what drawbacks?

 but
> >>> in my opinion the benefits are minor enough that it's not
> >>> worth doing.
> >>
> >> You haven't listed any of what you think are benefits.
> >> I'm curious to know what those might be.
> 
> Promoting opaque types, and information hiding, are two of the
> most important.
> 
> > I mentioned it later: it gives the type a name that's a single
> > identifier, and saves a little typing.

<snip>

> >> 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

 Always typedef'ing
> is bad;  never typedef'ing is bad.  A good developer needs to
> understand the problems of both extremes.

[toc] | [prev] | [next] | [standalone]

#18391

On 2012-03-09, nick_keighley_nospam@hotmail.com wrote:
> On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>> > Tim Rentsch <txr@alumni.caltech.edu> writes:
>> >> Keith Thompson <kst-u@mib.org> writes:
>> >>> A typedef for a struct type creates a new name (such as "foo") for a
>> >>> type that already has a perfectly valid name (such as "struct foo").
>
> yes but its a long ugly name.

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

> The C++ people seem to agree, once you've defined a struct you don't
> have to scatter "struct" keywords about the place.

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

[toc] | [prev] | [next] | [standalone]

#18425

On 2012-03-09, Ike Naar <ike@iceland.freeshell.org> wrote:
> On 2012-03-09, nick_keighley_nospam@hotmail.com wrote:
>> On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>> > Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> >> Keith Thompson <kst-u@mib.org> writes:
>>> >>> A typedef for a struct type creates a new name (such as "foo") for a
>>> >>> type that already has a perfectly valid name (such as "struct foo").
>>
>> yes but its a long ugly name.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#18435

On 2012-03-10, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2012-03-09, Ike Naar <ike@iceland.freeshell.org> wrote:
>> On 2012-03-09, nick_keighley_nospam@hotmail.com wrote:
>>> On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>> > Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> >> Keith Thompson <kst-u@mib.org> writes:
>>>> >>> A typedef for a struct type creates a new name (such as "foo") for a
>>>> >>> type that already has a perfectly valid name (such as "struct foo").
>>>
>>> yes but its a long ugly name.
>>
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#18436

On 03/10/12 08:59 PM, Ike Naar wrote:
> On 2012-03-10, Kaz Kylheku<kaz@kylheku.com>  wrote:
>> On 2012-03-09, Ike Naar<ike@iceland.freeshell.org>  wrote:
>>> On 2012-03-09, nick_keighley_nospam@hotmail.com wrote:
>>>> On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
>>>>> Keith Thompson<kst-u@mib.org>  writes:
>>>>>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>>>>>> Keith Thompson<kst-u@mib.org>  writes:
>>>>>>>> A typedef for a struct type creates a new name (such as "foo") for a
>>>>>>>> type that already has a perfectly valid name (such as "struct foo").
>>>>
>>>> yes but its a long ugly name.
>>>
>>> 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.
>
> Exactly. And if "all" is a small number, using a typedef to avoid
> clutter can be counterprodutive.

Where small = 1 and one sixth?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#18443

On Friday, March 9, 2012 1:04:29 PM UTC, Ike Naar wrote:
> On 2012-03-09, nick_keighley wrote:
> > On Thursday, March 8, 2012 8:45:37 PM UTC, Tim Rentsch wrote:
> >> Keith Thompson <kst-u@mib.org> writes:
> >> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >> >> Keith Thompson <kst-u@mib.org> writes:
> >> >>> A typedef for a struct type creates a new name (such as "foo") for a
> >> >>> type that already has a perfectly valid name (such as "struct foo").
> >
> > yes but its a long ugly name.
> 
> If "struct" is long and ugly, how about "typedef"?

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

> > The C++ people seem to agree, once you've defined a struct you don't
> > have to scatter "struct" keywords about the place.
> 
> What's more, in C++ you don't have to scatter "typedef" keywords about
> the place either ;-)

you've not used the STL then?   :-)

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web