typedef /struct and the scope problems

[myth.drannon]

lets say I have a header file :

struct AAAA
{
blabla.....
};
typedef struct AAAA A;
typedef struct BBB
{
blabla...
.....
} B;
I try to compile it and get an error message that "AAA" has already
been declared in the current scope ! ( And I checked everywhere it is
not ! )
What's funny is , that when I remove the second typedef it compiles
well.
Any ideas why such a weird behavior ?
Thanks ?

[Jordan Abel]

On 2006-03-03, my**********@gmail.com <my**********@gmail.com> wrote:

lets say I have a header file :

struct AAAA
{
blabla.....
};
typedef struct AAAA A;
typedef struct BBB
{
blabla...
.....
} B;
I try to compile it and get an error message that "AAA" has already
been declared in the current scope ! ( And I checked everywhere it is
not ! )
What's funny is , that when I remove the second typedef it compiles
well.
Any ideas why such a weird behavior ?
Thanks ?

No idea. What compiler are you using, it may be broken

[Keith Thompson]

"my**********@gmail.com" <my**********@gmail.com> writes:

lets say I have a header file :

struct AAAA
{
blabla.....
};
typedef struct AAAA A;
typedef struct BBB
{
blabla...
.....
} B;
I try to compile it and get an error message that "AAA" has already
been declared in the current scope ! ( And I checked everywhere it is
not ! )
What's funny is , that when I remove the second typedef it compiles
well.
Any ideas why such a weird behavior ?

That's odd, I get a parse error on "blabla.....".

If I fix the syntax errors, it compiles without error. Obviously the
error is in code you haven't bothered to show us (probably on line
42).

If you post a complete compilable source file that exhibits the
problem, we can probably help. If not, we're not mindreaders.

--
Keith Thompson (The_Other_Keith) ks***@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.

[myth.drannon]

Intel's one.

[myth.drannon]

struct float
{
int e;
int m;
};

typedef struct float A;

typedef struct BBB
{
A floatA;
} B;

[Keith Thompson]

"my**********@gmail.com" <my**********@gmail.com> writes:

Intel's one.

Intel's one what?

Please read <http://cfaj.freeshell.org/google/> (that URL has been
posted here hundreds of times).

--
Keith Thompson (The_Other_Keith) ks***@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.

[Keith Thompson]

"my**********@gmail.com" <my**********@gmail.com> writes:

struct float
{
int e;
int m;
};

typedef struct float A;

typedef struct BBB
{
A floatA;
} B;

Without context (see <http://cfaj.freeshell.org/google/>), it's
difficult to know what you're asking about this code.

But the fact that "float" is a reserved word is going to cause some
problems. You didn't mention any syntax errors in your original post.
Is this *really* the exact code that you compiled? If not, please
post the exact code (copy-and-paste it, *don't* re-type it) and
provide enough context so we can figure out why you're showing it to
us.

--
Keith Thompson (The_Other_Keith) ks***@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.

[myth.drannon]

ok _float instead of float :) , names aside ....

struct _float
{
int e;
int m;
};

typedef struct _float A;

typedef struct BBB
{
A floatA;
} B;

removing
typedef struct _float A;

and using :
struct _float floatA
will compile .... still why this typedef line creates problems.

[Nils O. Selåsdal]

my**********@gmail.com wrote:

ok _float instead of float :) , names aside ....

struct _float
{
int e;
int m;
};

typedef struct _float A;

typedef struct BBB
{
A floatA;
} B;

removing
typedef struct _float A;

and using :
struct _float floatA
will compile .... still why this typedef line creates problems.

There is no problem. It compiles fine here.
If you want further help, I suggest you post the /actual/
code. Then you post the actual command line used to compile it,
and the output/errors that produces.

[CBFalconer]

"my**********@gmail.com" wrote:

ok _float instead of float :) , names aside ....

struct _float
{
int e;
int m;
};

typedef struct _float A;

typedef struct BBB
{
A floatA;
} B;

removing
typedef struct _float A;

and using :
struct _float floatA
will compile .... still why this typedef line creates problems.

Don't alter material you quote. Do preserve attribution lines for
any quoted material. Do snip anything not germane to your reply.

_float is an identifier reserved for the implementation. You
should not use it. In general, do not use any identifiers that
begin with a '_' (although that is slight overkill).

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Jordan Abel]

On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:

"my**********@gmail.com" wrote:

ok _float instead of float :) , names aside ....

> > struct _float
> > {
> > int e;
> > int m;
> > };
> >
> > typedef struct _float A;
> >
> > typedef struct BBB
> > {
> > A floatA;
> > } B;

removing
typedef struct _float A;

and using :
struct _float floatA
will compile .... still why this typedef line creates problems.

Don't alter material you quote. Do preserve attribution lines for
any quoted material. Do snip anything not germane to your reply.

_float is an identifier reserved for the implementation. You
should not use it. In general, do not use any identifiers that
begin with a '_' (although that is slight overkill).

For completeness,

You may use an identifier that begins with _ and a lowercase letter, or
_ and a digit, or the identifier _, in the following situations: As a
struct member. As a static or automatic identifier with block scope. The
following possibility may or may not require that no standard headers
are included: As a static identifier with file scope or a macro. The
following possibility definitely requires that no standard headers are
included: As an identifier in the tag namespace (i.e. name of a struct,
enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]

[Micah Cowan]

Jordan Abel <ra*******@gmail.com> writes:

For completeness,

You may use an identifier that begins with _ and a lowercase letter, or
_ and a digit, or the identifier _, in the following situations: As a
struct member. As a static or automatic identifier with block scope. The
following possibility may or may not require that no standard headers
are included: As a static identifier with file scope or a macro.
This last is never a possibility.
The
following possibility definitely requires that no standard headers are
included: As an identifier in the tag namespace (i.e. name of a struct,
enum, or union)
No. You may never do this, headers included or no. They are reserved
without qualification.
You may never use an identifier that begins with _ and an uppercase
letter or a second _.

Right.

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote: [snip] For completeness,

You may use an identifier that begins with _ and a lowercase letter, or
_ and a digit, or the identifier _, in the following situations: As a
struct member. As a static or automatic identifier with block scope. The
following possibility may or may not require that no standard headers
are included: As a static identifier with file scope or a macro. The
following possibility definitely requires that no standard headers are
included: As an identifier in the tag namespace (i.e. name of a struct,
enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]

I honestly don't know. I've read the rules about which identifiers
are reserved for which purposes, but since it's so trivially easy to
avoid any and all identifiers starting with '_', I don't bother to
remember them.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Joe Wright]

Jordan Abel wrote:

On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:

"my**********@gmail.com" wrote:

ok _float instead of float :) , names aside ....
>struct _float
>{
> int e;
> int m;
>};
>
>typedef struct _float A;
>
>typedef struct BBB
>{
> A floatA;
>} B;

removing
typedef struct _float A;

and using :
struct _float floatA
will compile .... still why this typedef line creates problems.

Don't alter material you quote. Do preserve attribution lines for
any quoted material. Do snip anything not germane to your reply.

_float is an identifier reserved for the implementation. You
should not use it. In general, do not use any identifiers that
begin with a '_' (although that is slight overkill).

For completeness,

You may use an identifier that begins with _ and a lowercase letter, or
_ and a digit, or the identifier _, in the following situations: As a
struct member. As a static or automatic identifier with block scope. The
following possibility may or may not require that no standard headers
are included: As a static identifier with file scope or a macro. The
following possibility definitely requires that no standard headers are
included: As an identifier in the tag namespace (i.e. name of a struct,
enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]

My advice is "Don't do it!". There is never a need for an application
program to name anything with a leading underscore. Never.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:

[snip]

For completeness,

You may use an identifier that begins with _ and a lowercase letter, or
_ and a digit, or the identifier _, in the following situations: As a
struct member. As a static or automatic identifier with block scope. The
following possibility may or may not require that no standard headers
are included: As a static identifier with file scope or a macro. The
following possibility definitely requires that no standard headers are
included: As an identifier in the tag namespace (i.e. name of a struct,
enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]

I honestly don't know. I've read the rules about which identifiers
are reserved for which purposes, but since it's so trivially easy to
avoid any and all identifiers starting with '_', I don't bother to
remember them.

To be clear, I don't mean to imply that discussing the detailed rules
is inappropriate, just that depending on them is unwise.

--
Keith Thompson (The_Other_Keith) ks***@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.

[Vladimir S. Oka]

Keith Thompson wrote:

Keith Thompson <ks***@mib.org> writes:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:

[snip]

For completeness,

You may use an identifier that begins with _ and a lowercase letter,
or _ and a digit, or the identifier _, in the following situations:
As a struct member. As a static or automatic identifier with block
scope. The following possibility may or may not require that no
standard headers
are included: As a static identifier with file scope or a macro.
The following possibility definitely requires that no standard
headers are included: As an identifier in the tag namespace (i.e.
name of a struct, enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]

I've recently read the Standard on this, and think this is the extent of
it (as far as _ goes).
I honestly don't know. I've read the rules about which identifiers
are reserved for which purposes, but since it's so trivially easy to
avoid any and all identifiers starting with '_', I don't bother to
remember them.

I agree with this approach as well. I use it myself. I consider meddling
there is just for the people who like to live dangerously... ;-)

--
BR, Vladimir

There was a young fellow from Cal.,
In bed with a passionate gal.
He leapt from the bed,
To the toilet he sped;
Said the gal, "What about me, old pal?"

[Jordan Abel]

On 2006-03-04, Vladimir S. Oka <no****@btopenworld.com> wrote:

Keith Thompson wrote:

Keith Thompson <ks***@mib.org> writes:

Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:
[snip]
For completeness,

You may use an identifier that begins with _ and a lowercase letter,
or _ and a digit, or the identifier _, in the following situations:
As a struct member. As a static or automatic identifier with block
scope. The following possibility may or may not require that no
standard headers
are included: As a static identifier with file scope or a macro.
The following possibility definitely requires that no standard
headers are included: As an identifier in the tag namespace (i.e.
name of a struct, enum, or union)

You may never use an identifier that begins with _ and an uppercase
letter or a second _.

[Anyone, did I miss anything or are any of these incorrect?]
I've recently read the Standard on this, and think this is the extent of
it (as far as _ goes).
I honestly don't know. I've read the rules about which identifiers
are reserved for which purposes, but since it's so trivially easy to
avoid any and all identifiers starting with '_', I don't bother to
remember them.

I agree with this approach as well. I use it myself. I consider meddling
there is just for the people who like to live dangerously... ;-)

It can be useful on struct members as a "suggestion" to users of an API
that the member is "private". Other than that, I agree.

[Vladimir S. Oka]

Jordan Abel wrote:

On 2006-03-04, Vladimir S. Oka <no****@btopenworld.com> wrote:

Keith Thompson wrote:

Keith Thompson <ks***@mib.org> writes:
Jordan Abel <ra*******@gmail.com> writes:
> On 2006-03-04, CBFalconer <cb********@yahoo.com> wrote:
[snip]
> For completeness,
>
> You may use an identifier that begins with _ and a lowercase
> letter, or _ and a digit, or the identifier _, in the following
> situations: As a struct member. As a static or automatic
> identifier with block scope. The following possibility may or may
> not require that no standard headers
> are included: As a static identifier with file scope or a macro.
> The following possibility definitely requires that no standard
> headers are included: As an identifier in the tag namespace (i.e.
> name of a struct, enum, or union)
>
> You may never use an identifier that begins with _ and an
> uppercase letter or a second _.
>
> [Anyone, did I miss anything or are any of these incorrect?]

I've recently read the Standard on this, and think this is the extent
of it (as far as _ goes).

I honestly don't know. I've read the rules about which identifiers
are reserved for which purposes, but since it's so trivially easy
to avoid any and all identifiers starting with '_', I don't bother
to remember them.

I agree with this approach as well. I use it myself. I consider
meddling there is just for the people who like to live dangerously...
;-)

It can be useful on struct members as a "suggestion" to users of an
API that the member is "private". Other than that, I agree.

Yes, that can be one safe way of using it. I still tend not to do it, as
it breeds bad habits. One might slip one day... ;-)

--
BR, Vladimir

Today is what happened to yesterday.

[myth.drannon]

It was such a stupid mistake !
I was loading the header file twice :)
simple

#ifndef MY_HEADER
#define MY_HEADER

solved it ...

Thank you guys for all your help !

[Michael Wojcik]

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".

Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

C provides a mechanism for data abstraction - incomplete structure
types. Why not use it?

(And this has benefits beyond hiding data structure implementation
details; for example, it forces users of the API to call a factory
function to allocate the structure, since they can't declare objects
of that type, nor use sizeof on it. And that, in turn, lets the
implementation track its objects, enforce an RAII-like pattern of
use, and so on.)

--
Michael Wojcik mi************@microfocus.com

Some seem to live on credit as naturally as they breathe, and I remember
the surprise of one of these: "What! You don't owe anybody anything! Good
Lord! man, lend me half a sovereign." -- Arthur Ransome

[Jordan Abel]

On 2006-03-09, Michael Wojcik <mw*****@newsguy.com> wrote:

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".
Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members. Or even allow for macros to access
bits of the struct

C provides a mechanism for data abstraction - incomplete structure
types. Why not use it?

(And this has benefits beyond hiding data structure implementation
details; for example, it forces users of the API to call a factory
function to allocate the structure, since they can't declare objects
of that type, nor use sizeof on it. And that, in turn, lets the
implementation track its objects, enforce an RAII-like pattern of
use, and so on.)

[Michael Wojcik]

[Sorry for the late reply; I have been out of the office.]

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-09, Michael Wojcik <mw*****@newsguy.com> wrote:

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

[re starting identifiers with an underscore]
It can be useful on struct members as a "suggestion" to users of an API
that the member is "private".
Surely a more effective suggestion is to have the API pass pointers
to an incomplete struct type, and not let the users see its contents
at all.

Not if you also want public members.

Obviously, but that's another advantage of my suggestion: it avoids
mixing public and private data in the same type, which is a Bad Idea.

If you really can justify a mix of public and private data in one type,
make it a struct of public members and a pointer to an incomplete
struct containing the private ones. There, that wasn't so hard, was
it?
Or even allow for macros to access bits of the struct

Premature optimization, generally. Unless an accessor call is in a
time-critical section of code, this trades robustness (from opacity
and abstraction) and ease of maintenance (because the calling code
needn't change) for a dubious - sometimes nonexistent, thanks to
caching effects - performance gain.

OO programmers are finally coming around to the understanding that
public members are bad for software maintenance. It'd be nice
(though unrealistic) to think that most experienced C programmers had
already figured that out.

--
Michael Wojcik mi************@microfocus.com

Advertising Copy in a Second Language Dept.:
Tapestry of the encounting and the farewell, the birth and the death.
You can hear the human being's song running through the 100 years.
-- Squaresoft

[Jordan Abel]

On 2006-03-17, Michael Wojcik <mw*****@newsguy.com> wrote:

[Sorry for the late reply; I have been out of the office.]

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-09, Michael Wojcik <mw*****@newsguy.com> wrote:

> In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:
>>
>> [re starting identifiers with an underscore]
>> It can be useful on struct members as a "suggestion" to users of an API
>> that the member is "private".
>
> Surely a more effective suggestion is to have the API pass pointers
> to an incomplete struct type, and not let the users see its contents
> at all.

Not if you also want public members.

Obviously, but that's another advantage of my suggestion: it avoids
mixing public and private data in the same type, which is a Bad Idea.

If you really can justify a mix of public and private data in one type,
make it a struct of public members and a pointer to an incomplete
struct containing the private ones. There, that wasn't so hard, was
it?

Or even allow for macros to access bits of the struct

Premature optimization, generally.

Not all optimization is premature, and the point in time at which the
optimization takes place does not change the possible techniques
involved.

In a typical C library, there are plenty of macros that access members
of FILE.

[Michael Wojcik]

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-17, Michael Wojcik <mw*****@newsguy.com> wrote:

In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-09, Michael Wojcik <mw*****@newsguy.com> wrote:
> In article <sl***********************@random.yi.org>, Jordan Abel <ra*******@gmail.com> writes:
>>
>> [re starting identifiers with an underscore]
>> It can be useful on struct members as a "suggestion" to users of an API
>> that the member is "private".
>
> Surely a more effective suggestion is to have the API pass pointers
> to an incomplete struct type, and not let the users see its contents
> at all.

Not if you also want public members.
Or even allow for macros to access bits of the struct
Premature optimization, generally.

Not all optimization is premature,

Gee, if only I had qualified my "premature optimization" claim...
oh, I did.
and the point in time at which the
optimization takes place does not change the possible techniques
involved.
Fine. Make that "pointless optimization, generally".
In a typical C library, there are plenty of macros that access members
of FILE.

Yes, and so what? No doubt that's a tremendous boon to the tiny
proportion of programs which use stdio macros to perform actions on
FILE objects within a time-critical section of code, for some
unguessable reason, and which are mysteriously not I/O-bound as a
result.

For all other programs, making those macros function calls and
keeping FILE opaque would be fine; indeed, it would be better, since
it would discourage the foolish from poking about in stdio.h and
manipulating the contents of FILE structures directly.

So, as I said: *generally* not a useful optimization.

--
Michael Wojcik mi************@microfocus.com

The lecturer was detailing a proof on the blackboard. He started to say,
"From the above it is obvious that ...". Then he stepped back and thought
deeply for a while. Then he left the room. We waited. Five minutes
later he returned smiling and said, "Yes, it is obvious", and continued
to outline the proof. -- John O'Gorman