Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: What is better and why?

Reply
Thread Tools

Re: What is better and why?

 
 
Tim Rentsch
Guest
Posts: n/a
 
      06-15-2013
Keith Thompson <(E-Mail Removed)> writes:

> "paskali" <(E-Mail Removed)> writes:
>> 1st:
>>
>> struct person {
>> char *name;
>> char *surname;
>> };

>
> That's my own preference. The type has a name "struct person";
> I don't feel the need to give it another one.


How this is expressed seems a little funny to me. Does this mean
you think there is never any reason to give a structure type a
different name (ie, using typedef)? Or only that there is never
a _need_ to do so? Or that there usually is not a need to do so?
Or what?

>> 2nd:
>>
>> typedef struct {
>> char *name;
>> char *surnname;
>> } person;

>
> That form is perfectly valid in this simple case. It has the
> advantage that the type has a name that's a single identifier.
> But that name doesn't become visible until the end of the
> declaration -- which means that the struct can't contain a
> pointer to another object of the same type.
>
>> 3th:
>>
>> typedef struct person {
>> char *name;
>> char *surname;
>> } person;

>
> Also perfectly valid, and it lets you declare a member of type
> "struct person*". Since typedef names and tag names are in
> different namespaces (not in the C++ sense of the word
> "namespace"), it's ok to use the same identifier for both.


Certainly it is legal. Is it desirable? I'm not sure if
you're ducking the question or just glossing over what
you think the answer is.

> A drawback, IMHO, is that you can only refer to the type as
> "struct person" inside the declaration, but you're obviously
> expected to refer to it as "person" once the declaration is
> complete.


I'm somewhat surprised you didn't explain one of the common
idioms for working around this problem, eg,

struct person;
typedef struct person person;
struct person { ... };

which allows use of the typedef name 'person' when defining
the contents of the type 'struct person'.

>> 4th:
>>
>> [example having dangerous naming choice, and response, snipped]

>
>> ?

>
> I prefer the 1st form. Many other people prefer the 3rd, because it
> gives the type a name that's a single identifier, and you don't need
> the "struct" keyword every time you refer to it. My own opinion is
> that making the fact that it's a struct explicit is a good idea --


This sounds like a circular statement. How is it different from
saying, "It's better to use the 'struct' form when declaring
things, becausee it's a good idea for the 'struct' keyword to be
present in the declaration." How is that not just tautological?

> unless it's an opaque type such that code should use it without
> knowing that it's a struct (in particular, not referring to the
> names of any of its members). Type FILE, defined in <stdio.h>,
> is an example of an opaque type.


Discussions about questions of style often lead nowhere. A large
part of why that's true is people give their conclusions first and
then give their reasoning/arguments second. It's a bad process.
When considering a style question, it's better to start with an
attitude of withholding judgment, and try to list objectively all
the plusses and minusses of each choice. (Obviously these will
sometimes be complementary; it's still good to list both.) The
objective listing of plusses and minusses should be something
everyone can agree on, as objectively verifiable facts. Then,
only after the costs and benefits are listed, explain which
factors are thought to deserve relatively more or less weight.
Separating out the objective and subjective aspects in this way,
including especially leading off with the objective aspects, is
much more likely to yield an illumniting discussion, not to
mention providing a better example to those who are still learning
how to form opinions on such issues.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2013
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> "paskali" <(E-Mail Removed)> writes:
>>> 1st:
>>>
>>> struct person {
>>> char *name;
>>> char *surname;
>>> };

>>
>> That's my own preference. The type has a name "struct person";
>> I don't feel the need to give it another one.

>
> How this is expressed seems a little funny to me. Does this mean
> you think there is never any reason to give a structure type a
> different name (ie, using typedef)? Or only that there is never
> a _need_ to do so? Or that there usually is not a need to do so?
> Or what?


I'm not sure it *means* that, but there is never a *need* to give a
struct type another name. If the language didn't permit typedefs for
structs, it would not lose any real expressive power.

For example, <time.h> defines a type "struct tm". It doesn't define a
typedef for it. IMHO such a typedef is not necessary, and would not be
particularly beneficial.

An advantage of a typedef is that it gives the type a name that's a
single identifer. I don't see that as a particularly important
advantage. Others do.

It does make sense to use a typedef when the type is opaque, i.e., when
code that uses the type is not expected to be written to depend on the
fact that the type is a struct. Type FILE is a good example of this;
it's likely to be a typedef for a struct, but portable code that uses
type FILE cannot refer to its members or assume that it's a struct.

>>> 2nd:
>>>
>>> typedef struct {
>>> char *name;
>>> char *surnname;
>>> } person;

>>
>> That form is perfectly valid in this simple case. It has the
>> advantage that the type has a name that's a single identifier.
>> But that name doesn't become visible until the end of the
>> declaration -- which means that the struct can't contain a
>> pointer to another object of the same type.
>>
>>> 3th:
>>>
>>> typedef struct person {
>>> char *name;
>>> char *surname;
>>> } person;

>>
>> Also perfectly valid, and it lets you declare a member of type
>> "struct person*". Since typedef names and tag names are in
>> different namespaces (not in the C++ sense of the word
>> "namespace"), it's ok to use the same identifier for both.

>
> Certainly it is legal. Is it desirable? I'm not sure if
> you're ducking the question or just glossing over what
> you think the answer is.


I'm not *deliberately* ducking the question, I just didn't feel like
writing about it at great length. If you're going to define a typedef
for a struct, IMHO it's better to use the same identifier for the tag
and the typedef name. I can think of no good reason to make the
identifiers distinct.

If you're going to use distinct identifiers, I think you should at least
follow a consistent convention, such as appending "_t" to the tag name
to form the typedef name (though I think POSIX reserves identifiers
ending in "_t" for some purposes).

>> A drawback, IMHO, is that you can only refer to the type as
>> "struct person" inside the declaration, but you're obviously
>> expected to refer to it as "person" once the declaration is
>> complete.

>
> I'm somewhat surprised you didn't explain one of the common
> idioms for working around this problem, eg,
>
> struct person;
> typedef struct person person;
> struct person { ... };
>
> which allows use of the typedef name 'person' when defining
> the contents of the type 'struct person'.


I didn't explain it because I didn't think of it -- not too surprising,
since I prefer not to use typedefs for structs at all.

>>> 4th:
>>>
>>> [example having dangerous naming choice, and response, snipped]

>>
>>> ?

>>
>> I prefer the 1st form. Many other people prefer the 3rd, because it
>> gives the type a name that's a single identifier, and you don't need
>> the "struct" keyword every time you refer to it. My own opinion is
>> that making the fact that it's a struct explicit is a good idea --

>
> This sounds like a circular statement. How is it different from
> saying, "It's better to use the 'struct' form when declaring
> things, becausee it's a good idea for the 'struct' keyword to be
> present in the declaration." How is that not just tautological?


Referring to a type as "struct foo" makes it clear to the reader
that it's a struct type. Referring to it as "foo" does not.
All else being equal, more clarity is better than less clarity.
Where's the tautology?

[...]

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      06-16-2013
Keith Thompson wrote:
> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>>
>>> I prefer the 1st form. Many other people prefer the 3rd, because it
>>> gives the type a name that's a single identifier, and you don't need
>>> the "struct" keyword every time you refer to it. My own opinion is
>>> that making the fact that it's a struct explicit is a good idea --

>>
>> This sounds like a circular statement. How is it different from
>> saying, "It's better to use the 'struct' form when declaring
>> things, becausee it's a good idea for the 'struct' keyword to be
>> present in the declaration." How is that not just tautological?

>
> Referring to a type as "struct foo" makes it clear to the reader
> that it's a struct type. Referring to it as "foo" does not.
> All else being equal, more clarity is better than less clarity.
> Where's the tautology?


I'd argue that if you need to add "struct" when referring to a type to
add clarity, there's something wrong with the code. If the distinction
is important in the current context (the code accesses members), it
should be obvious. If the distinction isn't important (the variable is
effectively opaque), "struct" is nothing more than a distraction.

--
Ian Collins
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      06-16-2013
On Saturday, 15 June 2013 20:36:13 UTC+3, Tim Rentsch wrote:
> Keith Thompson <(E-Mail Removed)> writes:
> > "paskali" <(E-Mail Removed)> writes:
> >> 3th:
> >>
> >> typedef struct person {
> >> char *name;
> >> char *surname;
> >> } person;

> >
> > Also perfectly valid, and it lets you declare a member of type
> > "struct person*". Since typedef names and tag names are in
> > different namespaces (not in the C++ sense of the word
> > "namespace"), it's ok to use the same identifier for both.

>
> Certainly it is legal. Is it desirable? I'm not sure if
> you're ducking the question or just glossing over what
> you think the answer is.


C++ has for whatever reason chosen to make that typedef
implicit. Making it explicit is also legal C++. So that variant
may add convenience when the declaration is included and
used both in C and C++ code since it is legal in both
languages and results with same effect in both languages.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      06-16-2013
Keith Thompson <(E-Mail Removed)> wrote:

(snip)
> I'm not sure it *means* that, but there is never a *need* to give a
> struct type another name. If the language didn't permit typedefs for
> structs, it would not lose any real expressive power.


> For example, <time.h> defines a type "struct tm". It doesn't define a
> typedef for it. IMHO such a typedef is not necessary, and would not be
> particularly beneficial.


> An advantage of a typedef is that it gives the type a name that's a
> single identifer. I don't see that as a particularly important
> advantage. Others do.


> It does make sense to use a typedef when the type is opaque, i.e., when
> code that uses the type is not expected to be written to depend on the
> fact that the type is a struct. Type FILE is a good example of this;
> it's likely to be a typedef for a struct, but portable code that uses
> type FILE cannot refer to its members or assume that it's a struct.


Yes, I don't normally used typedef on my structs, but I do like
FILE not being stuct FILE. Then again, how much does typedef
help over #define?

-- glen
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      06-16-2013
On 2013-06-16, glen herrmannsfeldt <(E-Mail Removed)> wrote:
> Yes, I don't normally used typedef on my structs, but I do like
> FILE not being stuct FILE. Then again, how much does typedef
> help over #define?


typedef works in non-trivial cases where #define doesn't.

struct thing { int i; double d; };

typedef struct thing thing, thing2[2];

thing a_thing;
thing2 a_thing2;

How would you do this, using #define instead of typedef?
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Keith Thompson <(E-Mail Removed)> wrote:
>
> (snip)
>> I'm not sure it *means* that, but there is never a *need* to give a
>> struct type another name. If the language didn't permit typedefs for
>> structs, it would not lose any real expressive power.

>
>> For example, <time.h> defines a type "struct tm". It doesn't define a
>> typedef for it. IMHO such a typedef is not necessary, and would not be
>> particularly beneficial.

>
>> An advantage of a typedef is that it gives the type a name that's a
>> single identifer. I don't see that as a particularly important
>> advantage. Others do.

>
>> It does make sense to use a typedef when the type is opaque, i.e., when
>> code that uses the type is not expected to be written to depend on the
>> fact that the type is a struct. Type FILE is a good example of this;
>> it's likely to be a typedef for a struct, but portable code that uses
>> type FILE cannot refer to its members or assume that it's a struct.

>
> Yes, I don't normally used typedef on my structs, but I do like
> FILE not being stuct FILE. Then again, how much does typedef
> help over #define?


Surely someone as bright as you can discover many or most of
the important differences, without outside help.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
Ike Naar <(E-Mail Removed)> writes:

> On 2013-06-16, glen herrmannsfeldt <(E-Mail Removed)> wrote:
>> Yes, I don't normally used typedef on my structs, but I do like
>> FILE not being stuct FILE. Then again, how much does typedef
>> help over #define?

>
> typedef works in non-trivial cases where #define doesn't.
>
> struct thing { int i; double d; };
>
> typedef struct thing thing, thing2[2];
>
> thing a_thing;
> thing2 a_thing2;
>
> How would you do this, using #define instead of typedef?


Surely the question is meant to ask about using #define
only for the name of the struct type, not for more
complicated type constructors like arrays.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
Someone writes:

> On Saturday, 15 June 2013 20:36:13 UTC+3, Tim Rentsch wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>> > "paskali" <(E-Mail Removed)> writes:
>> >> 3th:
>> >>
>> >> typedef struct person {
>> >> char *name;
>> >> char *surname;
>> >> } person;
>> >
>> > Also perfectly valid, and it lets you declare a member of type
>> > "struct person*". Since typedef names and tag names are in
>> > different namespaces (not in the C++ sense of the word
>> > "namespace"), it's ok to use the same identifier for both.

>>
>> Certainly it is legal. Is it desirable? I'm not sure if
>> you're ducking the question or just glossing over what
>> you think the answer is.

>
> C++ has for whatever reason chosen to make that typedef
> implicit. Making it explicit is also legal C++. So that
> variant may add convenience when the declaration is included
> and used both in C and C++ code since it is legal in both
> languages and results with same effect in both languages.


This seems like a non-argument to me. It is also true that

typedef struct person_structure_tag {
char *name;
char *surname;
} person;

allows the use of 'person' as a type name in both C and C++.
Moreover, this form relies less on knowing what the C++ rules
are for how names of struct types are handled, which clearly
is an advantage for people coming from a C background.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-16-2013
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> "paskali" <(E-Mail Removed)> writes:
>>>> 1st:
>>>>
>>>> struct person {
>>>> char *name;
>>>> char *surname;
>>>> };
>>>
>>> That's my own preference. The type has a name "struct person";
>>> I don't feel the need to give it another one.

>>
>> How this is expressed seems a little funny to me. Does this mean
>> you think there is never any reason to give a structure type a
>> different name (ie, using typedef)? Or only that there is never
>> a _need_ to do so? Or that there usually is not a need to do so?
>> Or what?

>
> I'm not sure it *means* that, but there is never a *need* to give a
> struct type another name. If the language didn't permit typedefs for
> structs, it would not lose any real expressive power.
>
> For example, <time.h> defines a type "struct tm". It doesn't define a
> typedef for it. IMHO such a typedef is not necessary, and would not be
> particularly beneficial.
>
> An advantage of a typedef is that it gives the type a name that's a
> single identifer. I don't see that as a particularly important
> advantage. Others do.
>
> It does make sense to use a typedef when the type is opaque, i.e., when
> code that uses the type is not expected to be written to depend on the
> fact that the type is a struct. Type FILE is a good example of this;
> it's likely to be a typedef for a struct, but portable code that uses
> type FILE cannot refer to its members or assume that it's a struct.


Let me ask my question(s) more directly. What are the benefits of
using a typedef name for struct types (as opposed to using 'struct'
and a tag)? What are the costs? In which cases do the costs (a)
clearly outweigh the benefits, (b) clearly underweigh the benefits,
and (c) approximately balance the benefits? The third question is
meant to elicit opinion, the first two more objective assessments.

>>>> 2nd:
>>>>
>>>> typedef struct {
>>>> char *name;
>>>> char *surnname;
>>>> } person;
>>>
>>> That form is perfectly valid in this simple case. It has the
>>> advantage that the type has a name that's a single identifier.
>>> But that name doesn't become visible until the end of the
>>> declaration -- which means that the struct can't contain a
>>> pointer to another object of the same type.
>>>
>>>> 3th:
>>>>
>>>> typedef struct person {
>>>> char *name;
>>>> char *surname;
>>>> } person;
>>>
>>> Also perfectly valid, and it lets you declare a member of type
>>> "struct person*". Since typedef names and tag names are in
>>> different namespaces (not in the C++ sense of the word
>>> "namespace"), it's ok to use the same identifier for both.

>>
>> Certainly it is legal. Is it desirable? I'm not sure if
>> you're ducking the question or just glossing over what
>> you think the answer is.

>
> I'm not *deliberately* ducking the question, I just didn't feel like
> writing about it at great length. If you're going to define a typedef
> for a struct, IMHO it's better to use the same identifier for the tag
> and the typedef name. I can think of no good reason to make the
> identifiers distinct.


The names are in different namespaces; different style rules,
coding standards, or other considerations, may apply in the
two cases.

It may be useful to have the two names be different to reduce the
possibility of confusion.

It may be useful to have the two names be different to deliberately
make it harder to use the other name, eg,

typedef struct foo_avoid_using_this_struct_tag foo;

> If you're going to use distinct identifiers, I think you should
> at least follow a consistent convention, such as appending "_t"
> to the tag name to form the typedef name (though I think POSIX
> reserves identifiers ending in "_t" for some purposes).


Certainly there is some benefit to doing this, but there also
can be benefit from not necessarily tying the two names together in
all cases. In either case I don't think it matters very much;
typically I expect the struct tag would appear on only two or
three places for those structs having both a tag and a typedef
name.


>>> A drawback, IMHO, is that you can only refer to the type as
>>> "struct person" inside the declaration, but you're obviously
>>> expected to refer to it as "person" once the declaration is
>>> complete.

>>
>> I'm somewhat surprised you didn't explain one of the common
>> idioms for working around this problem, eg,
>>
>> struct person;
>> typedef struct person person;
>> struct person { ... };
>>
>> which allows use of the typedef name 'person' when defining
>> the contents of the type 'struct person'.

>
> I didn't explain it because I didn't think of it -- not too surprising,
> since I prefer not to use typedefs for structs at all.
>
>>>> 4th:
>>>>
>>>> [example having dangerous naming choice, and response, snipped]
>>>
>>>> ?
>>>
>>> I prefer the 1st form. Many other people prefer the 3rd, because it
>>> gives the type a name that's a single identifier, and you don't need
>>> the "struct" keyword every time you refer to it. My own opinion is
>>> that making the fact that it's a struct explicit is a good idea --

>>
>> This sounds like a circular statement. How is it different from
>> saying, "It's better to use the 'struct' form when declaring
>> things, becausee it's a good idea for the 'struct' keyword to be
>> present in the declaration." How is that not just tautological?

>
> Referring to a type as "struct foo" makes it clear to the reader
> that it's a struct type. Referring to it as "foo" does not.
> All else being equal, more clarity is better than less clarity.
> Where's the tautology?


Oh, but now you're saying something different. Your earlier
statement didn't say anything about clarity, only about being
explicit. They are not synonymous.

Furthermore the idea that adding information necessarily adds
clarity is, at the very least, subject to debate. If that were
true, then why not do this:

struct foo_int_x_double_z {
int x;
double z;
};

Now we know just from a declaration what members and member types a
struct has! Obviously this suggestion is meant rhetorically, but I
hope you can see my point. Including the keyword 'struct' in each
and every declaration that uses the underlying structure type may
not necessarily lead to code that is easier to understand, and
certainly not always significantly easier to understand.

Also, and perhaps most important, is the point you gloss over:
"all else being equal". It is precisely because all else is not
equal that the question is raised. If you don't consider both
benefits AND costs, and make an effort to weigh one against the
other, any conclusions reached are unlikely to have much value.
Do you agree with that? If you don't I'm very curious to hear
why not.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
xmp, what to use instead of. myphplists@yahoo.com HTML 9 04-29-2013 03:35 PM
what is the advantage of using maven for java standalone app mcheung63@gmail.com Java 13 04-16-2013 01:42 AM
What Linux freeware will blur faces & show all frames of a 30second AVI video? Danny D. Digital Photography 8 04-14-2013 10:18 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM



Advertisments