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?

 
 
Ian Collins
Guest
Posts: n/a
 
      06-19-2013
Tim Rentsch wrote:
> Tiib <(E-Mail Removed)> writes:
>
>> On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>>> [snip]
>>>
>>> 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++.

>>
>> For me that is also fine. I dislike habit of some compilers
>> to discuss "struct person_structure_tag" as result in some
>> diagnostics, but that is minor.
>>
>> However 'struct person', (that several people said to be their
>> favorite form of usage) is not available with this definition
>> (it is with "3th" in both languages). I like when interfaces are
>> least intrusive when it comes to favorite styles of usage.

>
> I emphatically disagree with this reaction. Every style guide
> I have ever read recommends consistency. Encouraging or
> accommodating the use of multiple ways of doing the same thing
> is just wrong. Furthermore part of the point of using the
> longer name as a structure tag is so that 'struct person'
> _cannot_ be used; that C++ allows it is simply an unfortunate
> consequence of C++'s design choices.


C++ dose not allow it.

--
Ian Collins
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      06-19-2013
On 06/19/2013 05:54 PM, Ian Collins wrote:
> Tim Rentsch wrote:
>> Tiib <(E-Mail Removed)> writes:
>>
>>> On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>>>> [snip]
>>>>
>>>> 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++.
>>>
>>> For me that is also fine. I dislike habit of some compilers
>>> to discuss "struct person_structure_tag" as result in some
>>> diagnostics, but that is minor.
>>>
>>> However 'struct person', (that several people said to be their
>>> favorite form of usage) is not available with this definition
>>> (it is with "3th" in both languages). I like when interfaces are
>>> least intrusive when it comes to favorite styles of usage.

>>
>> I emphatically disagree with this reaction. Every style guide
>> I have ever read recommends consistency. Encouraging or
>> accommodating the use of multiple ways of doing the same thing
>> is just wrong. Furthermore part of the point of using the
>> longer name as a structure tag is so that 'struct person'
>> _cannot_ be used; that C++ allows it is simply an unfortunate
>> consequence of C++'s design choices.

>
> C++ dose not allow it.


What provision of what version of the C++ standard is violated by use of
that typedef? "g++ -std=c++98" has no problem with the following code:

typedef struct person_structure_tag {
char *name;
char *surname;
} person;
person p;
struct person_structure_tag q;
person_structure_tag r;

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      06-19-2013
James Kuyper wrote:
> On 06/19/2013 05:54 PM, Ian Collins wrote:
>> Tim Rentsch wrote:
>>> Tiib <(E-Mail Removed)> writes:
>>>
>>>> On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>>>>> [snip]
>>>>>
>>>>> 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++.
>>>>
>>>> For me that is also fine. I dislike habit of some compilers
>>>> to discuss "struct person_structure_tag" as result in some
>>>> diagnostics, but that is minor.
>>>>
>>>> However 'struct person', (that several people said to be their
>>>> favorite form of usage) is not available with this definition
>>>> (it is with "3th" in both languages). I like when interfaces are
>>>> least intrusive when it comes to favorite styles of usage.
>>>
>>> I emphatically disagree with this reaction. Every style guide
>>> I have ever read recommends consistency. Encouraging or
>>> accommodating the use of multiple ways of doing the same thing
>>> is just wrong. Furthermore part of the point of using the
>>> longer name as a structure tag is so that 'struct person'
>>> _cannot_ be used; that C++ allows it is simply an unfortunate
>>> consequence of C++'s design choices.

>>
>> C++ dose not allow it.

>
> What provision of what version of the C++ standard is violated by use of
> that typedef? "g++ -std=c++98" has no problem with the following code:


None, that's not what I was relying to.

I was answering "...'struct person' _cannot_ be used; that C++ allows
it..".

--
Ian Collins
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      06-20-2013
On 06/19/2013 07:05 PM, Ian Collins wrote:
> James Kuyper wrote:
>> On 06/19/2013 05:54 PM, Ian Collins wrote:
>>> Tim Rentsch wrote:
>>>> Tiib <(E-Mail Removed)> writes:
>>>>
>>>>> On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>>>>>> [snip]
>>>>>>
>>>>>> 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++.
>>>>>
>>>>> For me that is also fine. I dislike habit of some compilers
>>>>> to discuss "struct person_structure_tag" as result in some
>>>>> diagnostics, but that is minor.
>>>>>
>>>>> However 'struct person', (that several people said to be their
>>>>> favorite form of usage) is not available with this definition
>>>>> (it is with "3th" in both languages). I like when interfaces are
>>>>> least intrusive when it comes to favorite styles of usage.
>>>>
>>>> I emphatically disagree with this reaction. Every style guide
>>>> I have ever read recommends consistency. Encouraging or
>>>> accommodating the use of multiple ways of doing the same thing
>>>> is just wrong. Furthermore part of the point of using the
>>>> longer name as a structure tag is so that 'struct person'
>>>> _cannot_ be used; that C++ allows it is simply an unfortunate
>>>> consequence of C++'s design choices.
>>>
>>> C++ dose not allow it.

>>
>> What provision of what version of the C++ standard is violated by use of
>> that typedef? "g++ -std=c++98" has no problem with the following code:

>
> None, that's not what I was relying to.
>
> I was answering "...'struct person' _cannot_ be used; that C++ allows
> it..".


OK - I see what you mean now. I'm not sure what Tim meant by that comment.
In the context of the typedef above, neither language allows the type to
be referred to using 'struct person'. Both languages allow you to use
either "struct person_structure_tag" or "person" to refer to that type.
The difference between the two languages is that C++ allows you to also
refer to that type using 'person_structure_tag', without having to use
the 'struct' keyword.
--
James Kuyper
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-02-2013
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> 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.

>
> The costs and benefits are minor. I've acknowleged before that
> plenty of smart people prefer to use typedefs for structs. I have
> no great problem with that; I just prefer not to in my own code.


Ack. You talk about the weighting factors ("are minor") but
don't say what things are being weighed ("costs and benefits").
The whole thrust of my comments is to get people to separate the
objective considerations and the subjective weighing of those
considerations. It muddies the discussional waters to conflate
them.

> Omitting the typedef means there's (at least) one less thing to get
> wrong.


This illustrates why it's important first to list all the
consequences ("costs and benefits") and then second to weigh
them. What are some considerations that might favor using
a typedef? Without considering both we can't make a good
decision.

> If, hypothetically, the language didn't permit typedefs for structs,
> then this conversation would be unnecessary.


I don't see why you say this. It's like saying "If things were
different, they wouldn't be the same." True but irrelevant.

> And I suggest that if you're going to *add* a declaration to a piece
> of code, the burden of proof should be on the argument in favor of
> adding it. If it doesn't help, why do it?


I suggest you're offering a flawed meta-argument. Any coding
decision, either "adding" something or "omitting" something,
carries both advantages and drawbacks. Your suggestion boils
down to saying, if we can identify a particular cost (for some
coding choice) then the burden of proof is now on the chooser.
But all choices have costs. For example, not using a typedef
for structs will normally make programs longer; that is a cost.
Does this mean the burden of proof should be on the argument
in favor of not using typedefs? No of course it doesn't. It
is only by considering both the advantages _and_ disadvantages
of both cases, and weighing them against each other, that we
will arrive at a judicious assessment.

> Also, I've seen too much code that defines both a struct tag and
> a typedef name for the same type, with no obvious relationship
> between the two names. That's confusing. Dropping the typedef
> removes that particular source of confusion.


What you're implicitly saying is that using typedefs gives bad
programmers more opportunities to make poor choices. The only
effective remedy for bad programmers is not to let them program.
I take it as given that the question being addressed is when or
whether it makes sense to use typedefs for structs, but with the
understanding that said typedefs are written by developers who
are competent. I don't see any value in deciding whether some
coding practice makes sense when carried out by _in_competent
developers, because it never does, regardless of what choice is
made.

> What's *your* opinion on the matter?


More below..

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

>
> Of course I'll follow coding standards for existing code that I'm
> working on. I can't think of a good reason for a coding standard or
> style rule to require a struct tag and a typedef to have distinct
> names (other than perhaps the one you mention below).
>
>> It may be useful to have the two names be different to reduce the
>> possibility of confusion.

>
> If you know that "foo" and "struct foo" are the same type, what
> confusion is avoided by calling them "foo" and "struct foo_s", for
> example -- or "foo" and "struct bar"?


There is some utility to choosing tag names with suffixes _s, _u,
or _e, for structs, unions, or enums, respectively, to avoid
accidental collision in unrelated types (since tags for structs,
unions, and enums all share a common name space). This matters
(or more precisely, can matter) because how type names are
chosen may be different for structs, unions, and enums.

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

>
> Ok, that's a valid reason. I note that this still implies a
> consistent convention.
>
>>> 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.

>
> You say "in all cases". Are there some cases where they should have
> the same name, and other cases where they shouldn't? How are such
> cases distinguished?


Here are some different possibilities, in increasing order of
restrictiveness:

A. No special relationship between typedef name and tag name.

B. Given tag name, we can deduce typedef name, but not vice
versa (eg, typedef struct TDNAME_<random_string> TDNAME.

C. Given either tag name or typedef name we can deduce the
other (eg, typedef struct TDNAME_s TDNAME.

D. Typedef name and tag name are the same string.

I can't think of any situation where A seems like the best
choice; there may be one, but I haven't thought of any.

In most cases I think B is sufficient. More specifically, when
giving a struct a typedef name, normally I would expect the
struct tag to appear in at most two or three places (where the
typedef appears (plus one for a leading 'struct TAG;'), and where
the structure contents are defined). Also I'm sort of assuming
that given a typedef name it should be fairly easy to locate
the corresponding definition of struct contents (eg, using grep);
this assumption is slightly more restrictive than B, so please
consider that condition added to the description of B.

In some cases it might be important (in some contexts) to use
either the typedef name or the 'struct TAG' form, and switch back
and forth between them. For example, implementing an opaque
type, we might want to use the typedef name in declaring function
parameters, but use the 'struct TAG' form for other declarations
in source responsible for implementing those interface functions.
In these cases choice C is attractive. Alternatively, in cases
where source code is processed automatically in some way, eg, to
produce documentation, it might be helpful to be able to map in
either direction. (I don't have any particular examples in mind
for the last one -- I'm just mentioning it as a possibility.)

Case D is pretty much like case A -- there may be some cases
where it's important to insist on D rather than C, but I can't
think of any offhand. As long as the mapping from typedef name
to tag name is one-to-one and easily invertible, I don't know any
really compelling reason to insist on D rather than C. As above
though there may be such cases that just haven't occurred to me
as yet.

Different circumstances may prompt different choices, even within
a single program. Especially in a large code base, different
factors may dominate in different use cases. Part of why this
happens in this case is different kinds of structs are used in
different ways; different usage patterns may suggest different
choices for type naming rules. It's hard to codify what these
different patterns are exactly. Many style guidelines basically
punt on the problem and adopt a "one size fits all" approach.
For structs in particular I don't think that's appropriate; it
seems better IMO to promote per-domain local consistency, but
also allow the possibility that different domains may favor
different choices of naming style rules.


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

>
> They're not synonymous, but they're related.
>
>> 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.

>
> Sure, I see your point. I have my own preferences about how explicit
> code should be. They differ from the preferences of a lot of other
> C programmers -- and they're not always internally consistent.
>
> My bottom line about typedefs for structs is that a typedef doesn't
> add anything very useful.


Knowing that doesn't really tell me anything. Without knowing
what it is you're weighing, it doesn't help to know what the
weights are. It's important to be explicit: we can't have
a useful discussion if we don't know what it is the other
person is talking about.

> (I don't consider the ability to use a single identifier for a
> type name to be very useful; YMMV).


Surely that isn't the only difference you see between using a
typedef name and not using one, or even the most important
one (I hope!).

> Part of it, I suppose, is my tendency to think of C code in terms
> of the underlying semantics. Given "typedef struct foo { ... }
> foo;", I think of "struct foo" as the *real* name of the type, and
> "foo" as a mere alias. Others might have a mental model that says
> "foo" is the real name of the type.


Here I think is the crux of the matter, at least for many
developers. It's common, especially in C, to understand programs
by relating the source code to what happens in the underlying
executed code. Having the word 'struct' present helps bridge
that gap. (I should add that I don't think what you said is the
same is this; I see them as related but not as synonymous.)
People used to thinking in terms of concrete types may be more
comfortable if 'struct' is used in naming the type (and like you
may think of 'struct whatever' as the real name of the type).
Conversely, people used to thinking in terms of abstract types
may be more comfortable if a typedef name is used, especially in
code that doesn't (directly) access any internals (regardless of
whether the type is "opaque" or not), to promote the abstract
type aspects. People in the second group may not think of either
type name as being the "real" name of the type, but rather view
the two namings as referring to distinct types, an "external"
type and a "representation" type, with the implementing module
being allowed to convert between them; indeed some programming
languages support this type model directly in their language
definition.

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

>
> I don't exhaustively explore all the possible benefits and costs
> every time I write about typedefs.


I'm not asking you (or anyone) to do this every time, only the
first time (and perhaps also incrementally if/when new kinds of
consequences/advantages/disadvantages occur to you). And since
you have asked, let me go through this exercise myself.


using 'struct' in type name using typedef name as type name
------------------------------ ---------------------------------
type name is two tokens type name is one token

key token in tag name space key token in type name space

name always shows "structness" "structness" usually not shown
(but may be through name choice)

uses partially tied to choice uses not tied to choice of
of underlying representation underlying representation

The last two rows are related but slightly different: in the
first case the audience under consideration is human readers, and
in the second case compilers or other software tools.

On the lexical/syntactic side, most of the benefits accrue on the
side of using a typedef name: the name may be shorter; it is a
single token, which provides a better impedance match for things
like grep or using a type name as part of a different identifier
(eg, part of a function name); not having 'struct' (have to) be
part of the name provides more latitude in choice of name (for
example, we might want all type names to start with a capital
letter, which is possible for 'struct' only by using preprocessor
tricks). I can't think of any benefit that comes from having the
type name have to be two tokens rather than one. As far as the
name space differentiation goes, I don't see either side as
inherently advantaged or disadvantaged -- could go either way,
depending on other external factors.

On the semantic side, as far as compilation goes, I think all the
benefits are on the side of using a typedef name. Two key
examples: if we want to change the underlying implementation
(ie, to a non-struct type), that can be done without having to
change every declaration; also, if the relevant header defining
the type name has not been included, using a type name will
likely cause a syntax error, whereas using 'struct' often will
compile okay, usually with wrong semantics. A variation on the
second of these is where the key token (tag name or typedef name)
is misspelled -- for typedef names that's typically gives a
syntax error, but with 'struct' it gives a program that is still
syntactically allowed (and semantically typically wrong in cases
where no constraint violation has been caused). I can't think of
any benefit, as far as compilation processing goes, that accrues
on the side of using the 'struct' form everywhere.

On the semantic side when considering human readers, there is
basically only one consequence -- the "structness" of a type is
explicit in each declaration -- but various people have different
viewpoints as to whether this should be taken as an advantage or
disadvantage. Compare these two statements: "Using 'struct'
lets readers know when a declaration is based on a structure
type", versus "Using 'struct' forces readers to know when a
declaration is based on a structure type". Certainly in some
ways knowing for sure that a type is a structure type is a
positive -- for example, it removes ambiguity when members are
accessed whether they are in a struct or a union. But adding
information is not always a positive. In cases where it isn't
important to know whether a particular declaration involves a
struct type (which I believe is true much of the time, if not
most of the time), then having 'struct' be present lowers the
signal-to-noise ratio for relevant information. Using a typedef
name makes it easier to ignore such extraneous information, again
with a caveat that different people have different ideas about
when such information is extraneous. And using typedef names is
likely to be a better match for developers who are used to
thinking in terms of abstract types (and here again this is
definitely different for different developers).

In listing the various considerations, I have tried to account
only for intrinsic aspects, not extrinsic ones such as local
custom or externally imposed coding standards or style guides.
Such extrinsic factors are more appropriately considered as part
of the subsequent subjective weighting phase. Also, I could
list other consequences along with those listed above, but all
the other ones I thought of seemed contrived, so I didn't list
them.

Now on to the subjective weighting phase.

I put a high value on less restricted name choice, especially
being able to use a shorter name. Horizontal space is precious
when trying to observe a line width restriction of 79 or 80
characters. The word 'struct' plus the necessary following space
is 8.75% of an 80 character line, and in most cases unneeded
wasted space.

I put a positive value, but not so high as the previous case, on
having type names be one token instead of two. Convenience,
mostly. A small plus.

My weight for the type/tag name space distinction is close to
epsilon, or perhaps negative epsilon.

I put a high value on the factors affecting the compilation
process: more so on the improved error-catching behavior when
using typedefs, but to a degree also the comparative ease of
changing an underlying representation. Maybe a better way
to say that second one is that the weight is high but the
inherent value of the benefit is relatively low -- it's nice
to have when you need it, but it isn't needed as often as
the first factor is relevant.

For semantic factors pertaining to human readers, I put a high
value on making a reader-friendly choice, but which choice that
is depends a lot on circumstances. For example, if the type is
meant to be viewed as an opaque type, it's almost always better
(meaning, more reader-friendly) to use a typedef name rather than
something like "struct foo *". As the other end of the spectrum,
for any Standard-defined type (which could also include types
defined under POSIX), I think it's more reader-friendly to use
the name as it is given in the relevant external document. I
myself prefer to think in terms of abstract types when possible,
so for me personally I normally would use typedef names rather
than the 'struct' form, because it's a better expression for how
I think about the code. Here again I believe we see the crux of
the problem -- most developers would agree that this axis merits
a high weight, but they have different ideas about which side of
the scale to put the weight on. And different use cases often
mean a different choice for which side of the scale, even for
the same developer.

Summing all this up into a statement of personal opinion: unless
there are some particular motivations to the contrary, normally
it is better to use a typedef name rather than the 'struct' form
of naming. The biggest downside of following this course is that
how the code looks is discordant with the mental model of many
developers, whose response to such code is (understandably) rather
unfavorable. However, this drawback can be overcome with time
and experience, and meanwhile all the other positives are clearly
on the side of the scale favoring typedefs.

A final comment: my hope is readers will focus on the process
followed, and not just the final opinion statement.


> A lot of what I post here is probably too long as it is.


I don't think anyone[*] minds long postings, as long as the ratio
of relevant content to length is not too low. FWIW I appreciate
and value your comments, even the long ones and even ones I don't
necessarily agree with.
[*] "anyone" == "any reasonable reader of c.l.c"
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      07-03-2013
On Tuesday, 2 July 2013 22:42:20 UTC+3, Tim Rentsch wrote:
> I'm not asking you (or anyone) to do this every time, only the
> first time (and perhaps also incrementally if/when new kinds of
> consequences/advantages/disadvantages occur to you). And since
> you have asked, let me go through this exercise myself.


....
Wow.
....

> A final comment: my hope is readers will focus on the process
> followed, and not just the final opinion statement.


The process was great and you considered lot of things.
You should write a blog instead maybe.

My comment is that the other tools were perhaps less considered
than compiler and compiling process was. It is certainly harder to
weight them than compilers. We all use compilers but the other
tools differ. Also the tools evolve.

For one example mine habit to:

typedef struct person person;

It became habit for several reasons (other reasons I posted elsewhere).
One was that I started to use Doxygen. Doxygen did not have
TYPEDEF_HIDES_STRUCT option back then and later it did not work good
enough (it did take only one typedefing pattern into account). Probably
it works better now. It feels to be very popular tool so how well it
supports typedefs should perhaps affect some weights.

In general the various things in and around names (like prefixes,
suffices and cases and 'struct', 'enum', 'union') may be of low
benefit when there are mostly tools in use that can be configured
to visualize that information plentifully (with syntax highlighting
and other graphics) when needed.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-03-2013
Ian Collins <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
>> Tiib <(E-Mail Removed)> writes:
>>
>>> On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>>>> [snip]
>>>>
>>>> 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++.
>>>
>>> For me that is also fine. I dislike habit of some compilers
>>> to discuss "struct person_structure_tag" as result in some
>>> diagnostics, but that is minor.
>>>
>>> However 'struct person', (that several people said to be their
>>> favorite form of usage) is not available with this definition
>>> (it is with "3th" in both languages). I like when interfaces are
>>> least intrusive when it comes to favorite styles of usage.

>>
>> I emphatically disagree with this reaction. Every style guide
>> I have ever read recommends consistency. Encouraging or
>> accommodating the use of multiple ways of doing the same thing
>> is just wrong. Furthermore part of the point of using the
>> longer name as a structure tag is so that 'struct person'
>> _cannot_ be used; that C++ allows it is simply an unfortunate
>> consequence of C++'s design choices.

>
> C++ dose not allow it.


Sorry, what I was trying to say came out completely garbled.
What I meant was C++ allows a structure tag to be used as
though it's a type name even when there is no typedef. This
language feature in C++ implicitly promotes a style rule in
C where the typedef'ed name for a struct is the same as the
struct tag. As far as C++ goes this design decision may be
perfectly fine, I express no opinion about that. But I
don't think the implied style rule is necessarily a good
choice when writing C code (even in cases where both C and
C++ are used in the same program).
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-05-2013
Tiib <(E-Mail Removed)> writes:

> On Wednesday, 19 June 2013 20:05:19 UTC+3, Tim Rentsch wrote:
>> Tiib <(E-Mail Removed)> writes:
>> > On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>> >>[snip]
>> >>
>> >> 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++.
>> >
>> > For me that is also fine. I dislike habit of some compilers
>> > to discuss "struct person_structure_tag" as result in some
>> > diagnostics, but that is minor.
>> >
>> > However 'struct person', (that several people said to be
>> > their favorite form of usage) is not available with this
>> > definition (it is with "3th" in both languages). I like
>> > when interfaces are least intrusive when it comes to
>> > favorite styles of usage.

>>
>> I emphatically disagree with this reaction. Every style guide
>> I have ever read recommends consistency. Encouraging or
>> accommodating the use of multiple ways of doing the same thing
>> is just wrong.

>
> It is impossible to be consistent when each library that is used
> pushes their yet another viewpoint of what is "not wrong style".
>
>> Furthermore part of the point of using the longer name as a
>> structure tag is so that 'struct person' _cannot_ be used; that
>> C++ allows it is simply an unfortunate consequence of C++'s
>> design choices.

>
> If language design choices of C++ are so unfortunate and bad then
> how come that so lot (statistically most) of finalists of all
> language neutral programming contests are using it? C++ is useful
> tool. It is pointless to fight with a tool anyway.
>
> I believe that "person" is enough and "struct" is redundant, but
> if someone else feels that explicit "struct person" is more clear
> then the 5 letters can not hurt me. I write them myself when
> coding standard of particular product I work on suggests so.
>
>> >> 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.
>> >
>> > If it is interface that is meant for usage in both languages
>> > (possibly by third parties with unknown taste in style) then
>> > the better the authors know both languages the easier to
>> > everybody. If it is not such interface then it does not
>> > matter.

>>
>> Even if I agreed with this implication, the premise doesn't
>> match how things actually are currently, nor is it likely to
>> anytime in the near future. Design decisions should be made
>> based on how the world actually is, not on wishful thinking.

>
> How they are currently? I had impression that we currently are
> not discussing design but style. Style ... how struct names are
> arranged and used.


I think you misunderstood the point of my comments.
Unfortunately, I find your communicational style too
bellicose to try to explain further.
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      07-05-2013
On Friday, 5 July 2013 05:38:44 UTC+3, Tim Rentsch wrote:
> Tiib <(E-Mail Removed)> writes:
> > On Wednesday, 19 June 2013 20:05:19 UTC+3, Tim Rentsch wrote:
> >> Tiib <(E-Mail Removed)> writes:
> >> > On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
> >> >> 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.
> >> >
> >> > If it is interface that is meant for usage in both languages
> >> > (possibly by third parties with unknown taste in style) then
> >> > the better the authors know both languages the easier to
> >> > everybody. If it is not such interface then it does not
> >> > matter.
> >>
> >> Even if I agreed with this implication, the premise doesn't
> >> match how things actually are currently, nor is it likely to
> >> anytime in the near future. Design decisions should be made
> >> based on how the world actually is, not on wishful thinking.

> >
> > How they are currently? I had impression that we currently are
> > not discussing design but style. Style ... how struct names are
> > arranged and used.

>
> I think you misunderstood the point of my comments.
> Unfortunately, I find your communicational style too
> bellicose to try to explain further.


Yes, I do not understand. I can't even parse myself saying something
hostile above.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-05-2013
Tiib <(E-Mail Removed)> writes:

> On Friday, 5 July 2013 05:38:44 UTC+3, Tim Rentsch wrote:
>> Tiib <(E-Mail Removed)> writes:
>> > On Wednesday, 19 June 2013 20:05:19 UTC+3, Tim Rentsch wrote:
>> >> Tiib <(E-Mail Removed)> writes:
>> >> > On Sunday, 16 June 2013 18:15:56 UTC+3, Tim Rentsch wrote:
>> >> >> 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.
>> >> >
>> >> > If it is interface that is meant for usage in both languages
>> >> > (possibly by third parties with unknown taste in style) then
>> >> > the better the authors know both languages the easier to
>> >> > everybody. If it is not such interface then it does not
>> >> > matter.
>> >>
>> >> Even if I agreed with this implication, the premise doesn't
>> >> match how things actually are currently, nor is it likely to
>> >> anytime in the near future. Design decisions should be made
>> >> based on how the world actually is, not on wishful thinking.
>> >
>> > How they are currently? I had impression that we currently are
>> > not discussing design but style. Style ... how struct names are
>> > arranged and used.

>>
>> I think you misunderstood the point of my comments.
>> Unfortunately, I find your communicational style too
>> bellicose to try to explain further.

>
> Yes, I do not understand. I can't even parse myself saying
> something hostile above.


Let me try saying it differently. It appears you put more energy
into arguing than you do either communicating or listening.
 
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