Question about a struct declaration

[Andrey Tarasevich]

Re: Question about a struct declaration

Willem wrote:

Andrey wrote:
) Richard Heathfield wrote:
)...
)Er... I disagree.
)
) Well, then, can you come up with a different implementation hiding
) technique that would satisfy the following two requirements:
>
Richard doesn't want you not to use typedef'd pointers like that,
he wants you to typedef the pointer as typedef T <something>
and then have the client code use it as *T
>
In other words: hide the type, but don't hide the pointeryness.
At least I think that's what he means.

I understand that perfectly well. I'm taking about the situations when
library specification does not want to restrict implementations to using
pointer types and at the same time does not want to prevent them from
doing that. 'pthreads' library specification is one example of that.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Re: Question about a struct declaration

Richard wrote:

>Hide the pointeriness? No, it actually _doesn't_ hide the
>pointeriness . The pointeriness will be clearly visible in the
>interface header, in the typedef.

>
Exactly. Its not clearly indicated at the line its used. Its one of the
few times I would agree with Heathfield on a style issue.

It is not a style issue. It is an issue of implementing a given abstract
specification. Some abstract specification of some library exposes type
'T' and objects of type 'T' have to be user-definable and at the same
the inner workings of what's really hiding behind 'T' needs (is
preferred) to be hidden from the user (I already provided examples:
'pthread_t' in 'ptherads', or simply 'va_list' in our standard library).
The perfectly viable approach in this case is to use a typedef-ed
pointer to an undefined struct. There's no style issues here, and even
if someone is still inclined to see "style issues" here for some reason,
they are largely secondary.

--
Best regards,
Andrey Tarasevich

[Richard]

Re: Question about a struct declaration

Andrey Tarasevich <andreytarasevi ch@hotmail.comw rites:

Richard wrote:

>>Hide the pointeriness? No, it actually _doesn't_ hide the
>>pointerines s. The pointeriness will be clearly visible in the
>>interface header, in the typedef.

>>
>Exactly. Its not clearly indicated at the line its used. Its one of the
>few times I would agree with Heathfield on a style issue.

>
It is not a style issue. It is an issue of implementing a given
abstract specification. Some abstract specification of some library
exposes type 'T' and objects of type 'T' have to be user-definable and
at the same the inner workings of what's really hiding behind 'T'
needs (is preferred) to be hidden from the user (I already provided
examples: 'pthread_t' in 'ptherads', or simply 'va_list' in our
standard library). The perfectly viable approach in this case is to
use a typedef-ed pointer to an undefined struct. There's no style
issues here, and even if someone is still inclined to see "style
issues" here for some reason, they are largely secondary.

Aha. I follow you now. Thanks for the explanation.

[Keith Thompson]

Re: Question about a struct declaration

Richard Heathfield <rjh@see.sig.in validwrites:

Andrey Tarasevich said:
<snip>

However, if one day you'll need to do something like that

typedef struct dummy *dummy;

>
Please don't hide pointers in typedefs.
>

and use it as a dual-language header (C and C++) you'll run into
problems with C++, wince in C++ the latter declaration is illegal. If
this is an issue in your case, then it is a good idea to choose
different identifiers for struct tag and the typedef name. Otherwise,
the same identifier can safely be used (unless I'm missing some other
issue).

[...]

Hiding pointers in typedefs is *usually* a bad idea. The only
exception is when you want the type to be opaque, meaning that client
code will never treat it as a pointer. A more common approach is to
export a pointer to an opaque type, such as stdio's FILE*, but making
the pointer type itself opaque isn't necessarily evil.

(I suppose "isn't necessarily evil" might not be the highest praise I
could have offered.)

But the real problem with

typedef struct dummy *dummy;

is that the identifier "dummy" is used both for the struct tag and for
a *pointer to* the struct type. It's common to use the same identifier
for a struct tag and a pointer to the struct, as in:

typedef struct dummy dummy;

But making "struct dummy" a struct and "dummy" a pointer will only
cause confusion, whether you're trying to write dual-language code or
not. Pick two different names.

I think the generic word "dummy" obscured the problem in this case.
In real life, the name(s) would be more descriptive, perhaps something
like:

typedef struct widget_info *handle;

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

[Richard Tobin]

Re: Question about a struct declaration

In article <lzd4opcz3z.fsf @stalkings.ghot i.net>,
Keith Thompson <kst@cts.comwro te:

>Hiding pointers in typedefs is *usually* a bad idea.

Nonsense!

>The only
>exception is when you want the type to be opaque, meaning that client
>code will never treat it as a pointer.

Much more reasonable.

In my experience, creating opaque types is the *usual* reason for
typedefing pointers, so it is *usually* a good idea...

>But the real problem with
>
typedef struct dummy *dummy;
>
>is that the identifier "dummy" is used both for the struct tag and for
>a *pointer to* the struct type.

I don't see that as a problem - "dummy" is the pointer type and
"struct dummy" is the struct type. Used consistently, that would be a
perfectly reasonable convention. The usual, opaque, use has the short
name, and the rare, struct, use has "struct" to draw attention to it.

>It's common to use the same identifier
>for a struct tag and a pointer to the struct, as in:
>
typedef struct dummy dummy;

Again, I don't find that "common". Increasingly libraries export
mostly-opaque types, and client programs rarely have occasion to
use the struct type itself.

-- Richard
--
:wq

[Andrey Tarasevich]

Re: Question about a struct declaration

Keith Thompson wrote:

>
But the real problem with
>
typedef struct dummy *dummy;
>
is that the identifier "dummy" is used both for the struct tag and for
a *pointer to* the struct type. It's common to use the same identifier
for a struct tag and a pointer to the struct, as in:
>
typedef struct dummy dummy;
>
But making "struct dummy" a struct and "dummy" a pointer will only
cause confusion, whether you're trying to write dual-language code or
not. Pick two different names.

I'd say that in the implementation hiding situations giving the same
name to the exposed type and to the hidden-struct tag is not a problem,
but (quite the opposite) a way to remind the user, who's thoughtlessly
trying to use 'struct dummy' in his code, that there's something else
named 'dummy' he should really be using instead.

I think the generic word "dummy" obscured the problem in this case.
In real life, the name(s) would be more descriptive, perhaps something
like:
>
typedef struct widget_info *handle;
>

No, _that_ would be a bad idea. Giving a descriptive name to something
that is supposed to be hidden is a way to encourage the user to start
making unwarranted assumptions and even attempt break the implementation
protection. There's no reason for the user to know anything
"descriptiv e" about what's hiding behind the 'handle' (besides the
information given in the specification).

--
Best regards,
Andrey Tarasevich

[John Bode]

Re: Question about a struct declaration

On Apr 16, 4:04 am, heavyz <heavyzh...@gma il.comwrote:

In C, if i want to declare a struct, there are 3 methods to do so:
>
1: struct dummy { ... };
2: typedef struct { ... } dummy;
3: typedef struct _dummy { ... } dummy;
>
Usually i use the first method to declare my structs, but in many open
source projects (such as libxml2), the third method is used. I am just
curious about the difference.. Would somebody tell me which method is
recommended, and why? Thanks in advance.
>
ZHENG Zhong

Using the typedef name (methods 2 and 3) allows you to sort-of de-
emphasize the "struct-ness" of dummy; you're basically telling the
user of that type to think in terms of dummy as an atomic entity (much
like a scalar), not as a collection of items. See FILE in stdio.h as
an example; we're not expected to know anything about the details of
FILE items, just to pass pointers to them between the various stdio
functions.

As others have pointed out, identifiers with leading underscores
(_dummy) are reserved for the implementation, and should not be used
in application code.