[SOLVED] typedef in C ( Compiler Point of view )

ravishekhar.82 · 04-15-2010, 06:48 AM

Hi,

Code:

typedef int (elevator_merge_fn)(int *,char *);

struct elevator_ops
{
  elevator_merge_fn *elevator_merge_fn;
};

I want to know how Compile differentiate b/w both elevator_merge_fn in elevator_merge_fn *elevator_merge_fn .

Sergei Steshenko · 04-15-2010, 07:01 AM

Quote:

Originally Posted by ravishekhar.82

Hi,

Code:

typedef int (elevator_merge_fn)(int *,char *);

struct elevator_ops
{
  elevator_merge_fn *elevator_merge_fn;
};

I want to know how Compile differentiate b/w both elevator_merge_fn in elevator_merge_fn *elevator_merge_fn .

Apparently by using separate tables for type names and structures.

ravishekhar.82 · 04-15-2010, 07:19 AM

Quote:

Apparently by using separate tables for type names and structures.

Can you elaborate little bit more b'coz I did not get how table for structures will come into picture.
Also below code is also not having any compilation problem:

Code:

typedef int (elevator_merge_fn)(int *,char *);

int main ()
{
  elevator_merge_fn *elevator_merge_fn;

  return 0;
}

johnsfine · 04-15-2010, 07:34 AM

In your examples, the type named elevator_merge_fn is in global scope, while the pointer named elevator_merge_fn is in a local scope.

C can always keep track of the same name in two different scopes.

The tricky part in each case is that you use the global scoped name inside the local scope to define the local scoped name.

I've read the C++ rules for doing that (though I couldn't quote every detail and consequence from memory). I expect (but haven't read any standard) that such rules are similar in C.

A simple (but hopefully still correct) view of such rules is that the scope of the locally scoped name doesn't begin until it is declared, so the outer scope name can be used up to and including in the declaration/definition of the locally scoped name.

ForzaItalia2006 · 04-15-2010, 12:13 PM

Quote:

Originally Posted by johnsfine

A simple (but hopefully still correct) view of such rules is that the scope of the locally scoped name doesn't begin until it is declared, so the outer scope name can be used up to and including in the declaration/definition of the locally scoped name.

Hey John,

yes you're correct. At least according to C99, the declaration becomes valid/visible with the finishing semi-colon. Check out C99, 6.2.1 (1)

Quote:

Structure, union, and enumeration tags have scope that begins just after the appearance of the tag in a type specifier that declares the tag. Each enumeration constant has scope that begins just after the appearance of its defining enumerator in an enumerator list. Any other identifier has scope that begins just after the completion of its declarator.

- Andi -

ravishekhar.82 · 04-16-2010, 01:25 AM

Quote:

In your examples, the type named elevator_merge_fn is in global scope, while the pointer named elevator_merge_fn is in a local scope.
C can always keep track of the same name in two different scopes.

Yes that's quite true for the example given 2nd.

Is it also true for Code I put first time ??? i.e. for

Code:

    typedef int (elevator_merge_fn)(int *,char *);

    struct elevator_ops
   {
     elevator_merge_fn *elevator_merge_fn;
   };

I am asking this b'coz if scope explanation could have fitted here then this code could have compiled with g++ which is not the case.

Error is :

Code:

 1.cpp:7: error: declaration of ‘int (* elevator_ops::elevator_merge_fn)(int*, char*)’
 1.cpp:3: error: changes meaning of ‘elevator_merge_fn’ from ‘typedef int elevator_merge_fn(int*, char*)’

ForzaItalia2006 · 04-18-2010, 03:45 PM

Quote:

Originally Posted by ravishekhar.82

Is it also true for Code I put first time ??? i.e. for

Code:

    typedef int (elevator_merge_fn)(int *,char *);

    struct elevator_ops
   {
     elevator_merge_fn *elevator_merge_fn;
   };

This is very similar to the function-local definition. Here, you have a structure declaration, while the member 'names' of the structure are ONLY local to the structure in the vague sense that each structure has a separate symbol table to lookup the names. That's why you don't get any name collision errors.

Quote:

Originally Posted by ravishekhar.82

I am asking this b'coz if scope explanation could have fitted here then this code could have compiled with g++ which is not the case.

By using g++, you compile your code obviously with the C++ compiler and NOT with the C compiler. I currently don't know how strict C++ is (apparently very stricter than C :-)) from a formal/C++-standard point-of-view. You might be confused about this error because you possibly think that C is a subset of C++ and though each valid C code should be compiled by a C++ compiler, right? But that's not completely true. There are some cases where the C compiler just gives a warning, while the C++ fails to compile, e.g. when dealinig with implicit function prototypes.

paulsm4 · 04-18-2010, 04:35 PM

Hi -

Quote:

FACT:
C can always keep track of the same name in two different scopes.

Absolutely true. But that doesn't mean you should actually do it

Code:

   /* PUNISHABLE SIN: */
   typedef int (elevator_merge_fn)(int *,char *);

   struct elevator_ops
   {
     elevator_merge_fn *elevator_merge_fn;
   };

Code:

   /* MUCH BETTER: */
   typedef int (elevator_merge_fn_t)(int * height, char * name);

   struct elevator_ops
   {
     elevator_merge_fn_t *elevator_merge_p;
   };

IMHO .. PSM

PS:
Just so we're all on the same page:

Quote:

http://eli-project.sourceforge.net/c_html/c.html

If more than one declaration of a particular identifier is visible
at any point in a translation unit, the syntactic context
disambiguates uses that refer to different entities. Thus, there are
separate name spaces for various categories of identifiers, as
follows:

* label names (disambiguated by the syntax of the label declaration
and use);

* the tags of structures, unions, and enumerations (disambiguated by
following any/11/ of the keywords struct , union , or enum );

* the members of structures or unions; each structure or union has a
separate name space for its members (disambiguated by the type of the
expression used to access the member via the . or -> operator);

* all other identifiers, called ordinary identifiers (declared in
ordinary declarators or as enumeration constants).

"Global" vs "local" scope was cited above. Another, equally important aspect of this question is "tag" vs "members of structures or unions" identifier scopes. Both of which are separate/distinct from the aforementioned "global" vs "local" scopes

johnsfine · 04-18-2010, 09:12 PM

Quote:

Originally Posted by johnsfine

A simple (but hopefully still correct) view of such rules is that the scope of the locally scoped name doesn't begin until it is declared, so the outer scope name can be used up to and including in the declaration/definition of the locally scoped name.

I was talking about declarations in functions and I was thinking about C. Since the example turns out to be C++, I want to disown much of the above statement.

I still don't recall the exact rules for when names come into scope in C++ (and never even thought of it as an interesting issue in C). But for names in struct's in C++, it is clearly not true that the name comes into scope only when declared.

In C++, you can use the name of a member of a struct within the definition of that struct before the declaration of that member. So the example at the start of this thread is wrong in C++. I was expecting it would be correct in C, but I haven't tried it.

Generally my opinion on this kind of detail in the language standard is that caring about it is foolish. Simply using a different name is easier and clearer.

There are many difficult issues in C++ where I expect the programmers I supervise to learn obscurities of the language standard, because I don't see a good alternative to writing code that depends on knowing those obscurities. In this case, I think it is easier to not take advantage of any cases in which it might work to use an outer scope name between the opening { of a scope and the end of declaration of a name that masks that outer scope name.