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]

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]

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.

 

[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]

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]

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.

 

[myth.drannon]

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

removing
typedef struct _float A;

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

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

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


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]

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


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]

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]

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]

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.

 

[Joe Wright]

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.

 

[Keith Thompson]

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.

 

[Vladimir S. Oka]

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

[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 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]

[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... ;-)

 

[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]

[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 (e-mail address removed)

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