|
|
|
|
|
|
| Author |
Message |
Frederick Gotham
*nix forums Guru
Joined: 09 Jun 2006
Posts: 502
|
 Posted: Tue Jun 27, 2006 2:03 am Post subject:
Re: Forward Declarations
|
|
|
Tom Plunket posted:
| Quote: | struct something
{
int member;
};
This would deposit an unnamed "struct something" right there in the
translation unit (if that's the proper C vocabulary, anyway) where the
structure was defined.
|
Common sense tells me that that would be a whoefully redundant thing to do.
Even in C++ -- where the definition of an object can result in the
execution of code -- it would still be ridiculous (C++ is full of all sorts
of optimizations like "Named Return Value Optimization").
--
Frederick Gotham |
|
| Back to top |
|
 |
Keith Thompson
*nix forums Guru
Joined: 28 Feb 2005
Posts: 5173
|
| Posted: Tue Jun 27, 2006 2:19 am Post subject:
Re: Forward Declarations
|
|
|
Frederick Gotham <fgothamNO@SPAM.com> writes:
| Quote: | Keith Thompson posted:
Logically, since this:
struct something {
int member;
} x, y;
creates two objects, and this:
struct something {
int member;
} x;
creates one object, then this:
struct something {
int member;
};
should create none.
In the spirit of keeping things mathematical, maybe "should create zero
objects" would be a better way of putting it? ; )
|
In the spirit of reading and writing plain English, I thought (and
still think) that the word "none" is perfectly clear.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. |
|
| Back to top |
|
|
Dave Thompson
*nix forums Guru
Joined: 21 Feb 2005
Posts: 340
|
| Posted: Mon Jul 10, 2006 8:19 am Post subject:
Re: Forward Declarations
|
|
|
On Mon, 26 Jun 2006 15:01:00 -0700, Tom Plunket <gamedev@fancy.org>
wrote:
<snip>
| Quote: | It's been years since I "learned" C, but at the time the sage wisdom
who was providing me with guidance said I should /always/ typedef
structures, because a structure definition all by itself would yield
an unnamed instance of that structure right at that location. E.g.
struct something
{
int member;
};
Does not, and never did, as already said. |
Are you sure you, or your guide, didn't misunderstand or misremember
the issue of including or omitting a struct _tag_?
struct { elements } zorg;
creates an 'anonymous' struct type, which you cannot refer to later --
i.e. you cannot create another variable, or a pointer to one, or a
function argument, etc., which the compiler will recognize as the same
type. (Unlike some other non-C languages, which do use so called
'structural' or 'deep' type compatibility.)
struct good { elements } lelu;
creates a variable _and_ a tag (type) which you can use later.
struct good { elements };
creates _only_ the tag (type). Which you can use later,
and that is the only way to use it, so if you don't, it's useless :-)
<OT> In C++, the tag name(s) in the latter form are available as
typenames by themselves, in addition to 'struct good' as in C (which
is still permitted). People often say loosely that C++ automatically
does typedef for you, but this isn't strictly right; even in C++ you
can still declare both an ordinary-identifier foo and a tag foo in the
same scope, but it is very bad style, even worse than it is in C.
- David.Thompson1 at worldnet.att.net |
|
| Back to top |
|
|
ena8t8si@yahoo.com
*nix forums Guru Wannabe
Joined: 15 Feb 2006
Posts: 103
|
| Posted: Mon Jul 17, 2006 8:57 pm Post subject:
Re: Forward Declarations
|
|
|
Keith Thompson wrote:
| Quote: | Tom Plunket <gamedev@fancy.org> writes:
Chris Torek wrote:
For those who insist on treating C as if it were C++...
Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
put it in the standard do you figure?
C has no concept of "sin" other than the trigonometric function.  }
The idea that using typedefs for structure types is poor style is
actually rather controversial. Chris Torek and I happen to agree on
this point, but plenty of smart people don't.
An argument in favor of using a typedef is that it provides a one-word
name for a type. In my opinion, that's not a strong enough reason to
use it.
|
Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
If client code should view a struct transparently,
then no typedef - just use struct.
In my programming, I tend to use abstraction rather
a lot, so usually types are typedef'ed. But I
understand both modes, and use either, as appropriate.
There is one typedef idiom that bears mentioning:
typedef struct { ... } *Foo;
This idiom is useful when the underlying structs
should always be malloc'ed, never static or auto.
Because of how the type is declared, no code will
have these structs other than {m,c,re}alloc()'ed
ones. |
|
| Back to top |
|
|
Keith Thompson
*nix forums Guru
Joined: 28 Feb 2005
Posts: 5173
|
| Posted: Mon Jul 17, 2006 9:46 pm Post subject:
Re: Forward Declarations
|
|
|
ena8t8si@yahoo.com writes:
| Quote: | Keith Thompson wrote:
Tom Plunket <gamedev@fancy.org> writes:
Chris Torek wrote:
For those who insist on treating C as if it were C++...
Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
put it in the standard do you figure?
C has no concept of "sin" other than the trigonometric function. }
The idea that using typedefs for structure types is poor style is
actually rather controversial. Chris Torek and I happen to agree on
this point, but plenty of smart people don't.
An argument in favor of using a typedef is that it provides a one-word
name for a type. In my opinion, that's not a strong enough reason to
use it.
Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
If client code should view a struct transparently,
then no typedef - just use struct.
In my programming, I tend to use abstraction rather
a lot, so usually types are typedef'ed. But I
understand both modes, and use either, as appropriate.
There is one typedef idiom that bears mentioning:
typedef struct { ... } *Foo;
This idiom is useful when the underlying structs
should always be malloc'ed, never static or auto.
Because of how the type is declared, no code will
have these structs other than {m,c,re}alloc()'ed
ones.
|
In that case, it would probably make sense to hide the *alloc() and
free() calls behind some type-specific functions; the *alloc()
wrappers could also do any necessary initialization of the struct
members. This is basically what fopen() and fclose() do, except that
the pointer isn't hidden behind a typedef; the members of the
structure are effectively hidden not by the fact that there's no name
for the structure type (there is, FILE), but by the fact that the
details are undocumented, and code that depends on them will break
when ported.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this. |
|
| Back to top |
|
|
ena8t8si@yahoo.com
*nix forums Guru Wannabe
Joined: 15 Feb 2006
Posts: 103
|
| Posted: Tue Jul 18, 2006 9:53 am Post subject:
Re: Forward Declarations
|
|
|
Keith Thompson wrote:
| Quote: | ena8t8si@yahoo.com writes:
Keith Thompson wrote:
Tom Plunket <gamedev@fancy.org> writes:
Chris Torek wrote:
For those who insist on treating C as if it were C++...
Ah, I didn't realize what a sin it was to use 'typedef'. Why'd they
put it in the standard do you figure?
C has no concept of "sin" other than the trigonometric function. }
The idea that using typedefs for structure types is poor style is
actually rather controversial. Chris Torek and I happen to agree on
this point, but plenty of smart people don't.
An argument in favor of using a typedef is that it provides a one-word
name for a type. In my opinion, that's not a strong enough reason to
use it.
Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
If client code should view a struct transparently,
then no typedef - just use struct.
In my programming, I tend to use abstraction rather
a lot, so usually types are typedef'ed. But I
understand both modes, and use either, as appropriate.
There is one typedef idiom that bears mentioning:
typedef struct { ... } *Foo;
This idiom is useful when the underlying structs
should always be malloc'ed, never static or auto.
Because of how the type is declared, no code will
have these structs other than {m,c,re}alloc()'ed
ones.
In that case, it would probably make sense to hide the *alloc() and
free() calls behind some type-specific functions; the *alloc()
wrappers could also do any necessary initialization of the struct
members. This is basically what fopen() and fclose() do, except that
the pointer isn't hidden behind a typedef; the members of the
structure are effectively hidden not by the fact that there's no name
for the structure type (there is, FILE), but by the fact that the
details are undocumented, and code that depends on them will break
when ported.
|
It depends what you want to achieve.
If you want the structure members accessed only
within the implementing module, then something
like
typedef struct __FILE FILE;
in a header, and a subsequent
struct __FILE { ... };
in the implementing module is usually a good way
to do that. (User code shouldn't use the __'s,
other than that it's the same.)
If what you want is to guarantee that struct
instances are made only through *alloc(), then
the idiom
typedef struct { ... } *Foo;
is a way to do that. C gives you a choice,
but it has to be one or the other, it can't
be both. |
|
| Back to top |
|
|
Michael Wojcik
*nix forums Guru
Joined: 10 Apr 2005
Posts: 336
|
| Posted: Tue Jul 18, 2006 8:13 pm Post subject:
Re: Forward Declarations
|
|
|
In article <1153169865.042056.34870@35g2000cwc.googlegroups.com>, ena8t8si@yahoo.com writes:
| Quote: |
Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
|
Perhaps, but since C already contains an idiom for opaque types which
does not require a typedef, the typedef is still superfluous.
When I have a header file that contains:
struct foo;
struct foo *MakeFoo(void);
void UseFoo(struct foo *);
I know I am dealing with an opaque type. No typedef need apply.
What's more, I know that I am dealing with a pointer-to-incomplete-
structure, which is useful if, for example, I want to insert some
temporary instrumentation that tracks the struct-foo objects I have
created; I know I can print some representation of a struct foo *
with the %p format specifier (after casting it to void *), for
example. That's much better than a typedef that hides the fact that
I am dealing with a pointer, which I realize is not what you
suggested, but is all too common among the fans of typedef.
--
Michael Wojcik michael.wojcik@microfocus.com
Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation". |
|
| Back to top |
|
|
ena8t8si@yahoo.com
*nix forums Guru Wannabe
Joined: 15 Feb 2006
Posts: 103
|
| Posted: Wed Jul 19, 2006 9:59 pm Post subject:
Re: Forward Declarations
|
|
|
Michael Wojcik wrote:
| Quote: | In article <1153169865.042056.34870@35g2000cwc.googlegroups.com>, ena8t8si@yahoo.com writes:
Usually the best argument in favor of using a typedef
is that the name defined reflects how you want client
code to view the type.
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
Perhaps, but since C already contains an idiom for opaque types which
does not require a typedef, the typedef is still superfluous.
When I have a header file that contains:
struct foo;
struct foo *MakeFoo(void);
void UseFoo(struct foo *);
I know I am dealing with an opaque type. No typedef need apply.
|
You're using the term opaque in different
sense than I was. As I was using the term,
opaque means a type that client code should
know nothing about. The "opaque type" that
you suggest requires client code to know
(a) that it's a pointer and (b) that the
pointer points to a struct. That's more
translucent than opaque.
For translucent types, struct foo * is ok.
A type intended to be really opaque should
use typedef. |
|
| Back to top |
|
|
Michael Wojcik
*nix forums Guru
Joined: 10 Apr 2005
Posts: 336
|
| Posted: Thu Jul 20, 2006 9:43 pm Post subject:
Re: Forward Declarations
|
|
|
In article <1153346348.617917.106060@i3g2000cwc.googlegroups.com>, ena8t8si@yahoo.com writes:
| Quote: | Michael Wojcik wrote:
In article <1153169865.042056.34870@35g2000cwc.googlegroups.com>, ena8t8si@yahoo.com writes:
If client code should view the type as opaque, then
using typedef for a struct type makes sense.
Perhaps, but since C already contains an idiom for opaque types which
does not require a typedef, the typedef is still superfluous.
You're using the term opaque in different
sense than I was.
|
Perhaps I am, but I find the distinction you draw trivial and
superfluous.
| Quote: | As I was using the term,
opaque means a type that client code should
know nothing about.
|
This cannot be achieved in C. The "client code" can still apply the
sizeof operator to a typedef, for example. Assuming an implementation
with decent QoI, trial code can be written to determine what types the
typedef is compatible with, by observing diagnostics.
| Quote: | The "opaque type" that
you suggest requires client code to know
(a) that it's a pointer and (b) that the
pointer points to a struct.
|
So what? In some languages (eg OCaml), essentially all user-defined
types are references to structured types. That doesn't seem to be a
problem for them. I'll be damned if I can think why this would be a
problem in C. What precious information is leaking out of the abstract
interface?
| Quote: | That's more translucent than opaque.
|
The size and nature of the contents are invisible outside the
interface. That's as good a definition of "opaque type" as any other
I've seen.
| Quote: | A type intended to be really opaque should
use typedef.
|
You're welcome to that opinion. I don't find it convincing.
I'll also note in passing that using typedefs for "opaque" (abstract)
types encourages not wrapping elementary types in structs. And that,
in turn, may lead to maintenance problems, if the type needs to be
extended later, but existing callers have divined its non-struct
nature (eg by reading headers) and written code that relies on that
fact.
If struct is your only type-abstraction mechanism, this is never an
issue.
--
Michael Wojcik michael.wojcik@microfocus.com
He smiled and let his gaze fall to hers, so that her cheek began to
glow. Ecstatically she waited until his mouth slowly neared her own.
She knew only one thing: rdoeniadtrgove niardgoverdgovnrdgog. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Nov 21, 2008 5:11 am | All times are GMT
|
|
Unsecured Loans | Online Dating | McDonalds | Credit Counseling | MPAA
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
C
