K&R p 130

[mdh]

Hi All,
Just when I thought things were going to get easy!

Structs.

I **thought** I had copied the examples pretty closely, but am getting
a number of errors.
The code:

>>>>>>

#include <stdio.h>
int main (int argc, const char * argv[]) {

struct point {
int x;
int y;
};
struct point makepoint( int, int); /* error. previous decl of
'makepoint' was here*/

struct point p1 = makepoint(8,9);

printf("%d, %d\n", p1.x, p1.y);
}


struct point makepoint(int x, int y) {
struct point temp;
temp.x = x;
temp.y = y;
return temp;
}

The error I got in the past has meant that something has been defined
twice, but as far as I can tell, ( probably incorrectly) I have
declared a struct called point, then declared a function which accepts
two integer arguments and returns a 'point' structure. Clearly I am
missing something.

In addition, I am getting a number of errors in makepoint function
defintion, which may become obvious once my initial query is cleared.
If not, I will ask then.

Lastly, K&R say , on p 130, of the makepoint function, "notice that
there is no conflict between the argument name and the member with the
same name". I assume that this refers to the lines

temp.x = x;
temp.y = y;

Thanks as usual.

[mdh]

On Aug 17, 7:47*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

. *Let me write it out
compressed for convenience:

int main(void)
{
* * struct point { int x, y; }; * * * /* The struct tag point has a */
* * struct point makepoint(int, int); /* meaning all the way down */
* * struct point p = makepoint(1, 2); /* to here... */

}

struct point makepoint(int a, int b) /* ... but not here where it */
{ * * * * * * * * * * * * * * * * * */* is also needed. */
* /* stuff */

}

Outside main, "struct point" has no meaning, so the definition is
rejected.

OK...I think I am getting it.
Is this then correct.

A struct is a type ( just like int is a type) but one which I ( the
programmer...if I can call myself that :-) ) are able to declare. So,
essentially, up to now, when I have declared *anything* within main,
it has always been of a type that was ?"inherent" to C, unlike my own
type "point" which I need when defining "makepoint" . So,
theoretically , "re-declaring" it just before the definition would
work, except it would be "clunky" and in any case, that is in essence
what one is doing by moving the declarations outside of main.

[mdh]

On Aug 17, 7:47*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>
Your function foo does not rely on anything with a limited scope. *Its
return type and parameter type are all keywords that have the same
meaning everywhere. *If any of these types involved identifiers with
function scope, it too would have gone wrong.

One last little point. The identifier "foo" as in the following.
int main(void){

sometype foo ( some argument );

use foo;
}
sometype foo ( some arguments){};
}

When I call "foo" in main, that identifier does "know" where to find
the definition of foo. The identifier "foo" though has block scope, if
I understand this correctly.
So, how then does the call to foo get handled correctly?

Thank you.

[Ben Bacarisse]

mdh <md**@comcast.n etwrites:

On Aug 17, 7:47Â*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>>
Your function foo does not rely on anything with a limited scope. Â*Its
return type and parameter type are all keywords that have the same
meaning everywhere. Â*If any of these types involved identifiers with
function scope, it too would have gone wrong.

>

One last little point. The identifier "foo" as in the following.
int main(void){

sometype foo ( some argument );

use foo;
}
sometype foo ( some arguments){};
}

When I call "foo" in main, that identifier does "know" where to find
the definition of foo. The identifier "foo" though has block scope, if
I understand this correctly.

No, there are two identifiers with the same letters and thus two
scopes. They are "linked" by the fact the declaration of foo in
main is, by default, a declaration of a function with extern linkage.

So, how then does the call to foo get handled correctly?

I don't know how to answer questions like this, because I don't see
the problem! Maybe I have answered it with the above clarification.

--
Ben.

[mdh]

On Aug 17, 8:28*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

The key part is "declared in separate translation units". *Two
structs, declared in the same translation unit, even in separate
scopes, can't ever be compatible -- no matter how similar they look.

OK..., this is unique only to structs, unions and enums. And if so,
is this due to the complicated nature of those objects, and perhaps
the way C stores them internally? Or...that's just the way it
is? :-)

If so, thanks again for clarifying this issue for me.

[mdh]

On Aug 17, 8:47*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>
No, there are two identifiers with the same letters and thus two
scopes. *They are "linked" by the fact the declaration of foo in
main is, by default, a declaration of a function with extern linkage.

So, how then does the call to foo get handled correctly?

Thanks Ben...

[mdh]

On Aug 17, 1:30 am, ³Â·åÑï <BlueBlues.Che. [e-mail] te:

On 8ÔÂ17ÈÕ, ÏÂÎç2ʱ25·Ö, mdh <m...@comcast.n etwrote:

On Aug 16, 11:12 pm, santosh <santosh....@gm ail.comwrote:

Here's your code corrected:

#include <stdio.h>

struct point {
int x;
int y;

};

struct point makepoint( int, int);

snip
}

So I once again ran into a scope issue? In this case block scope? vs
file scope which you implemented? Santosh, could you help me
understand why I can declare 'int foo(int);' within "main" and then
call it, but I cannot do the same with the struct?

The return type of 'int foo(int)' is "int", which is a built-in type
of the language, that means you can use it in the global
scope(wherever in your program).
But "struct point" is a type you defined yourself, and you have
defined it in function main(), so you have to use it just within the
local-scope of main. In your code, you defeined a function return type
struct point out of the local-scope of main, it breaks the rule
mentioned above.:-)

Thank you.

[Barry Schwarz]

On Sun, 17 Aug 2008 08:37:55 -0700 (PDT), mdh <md**@comcast.n et>
wrote:

>On Aug 17, 7:47*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>>
Your function foo does not rely on anything with a limited scope. *Its
return type and parameter type are all keywords that have the same
meaning everywhere. *If any of these types involved identifiers with
function scope, it too would have gone wrong.

>

One last little point. The identifier "foo" as in the following.
int main(void){

sometype foo ( some argument );

use foo;
}
sometype foo ( some arguments){};
}

When I call "foo" in main, that identifier does "know" where to find
the definition of foo. The identifier "foo" though has block scope, if
I understand this correctly.
So, how then does the call to foo get handled correctly?

The call gets handled correctly because the linker, not the compiler,
is responsible for resolving the addresses.

During compilation, the compiler sees a prototype for foo at block
scope. It creates an entry for foo in an internal table that says foo
is a function being called (plus additional information about the
return and argument types). When you call foo, it generates data
(code?) in your object module that tells the linker that it needs to
find foo and adjust the data so that when this code is reached foo
will receive control. At the end of the block, it deletes the entry
for foo from the internal table because the prototype went out of
scope.

The compiler then sees the definition of foo which is at file scope.
It creates an entry for foo in an internal table that says foo is a
function being defined with external linkage (plus additional
information about return and argument types). {Note: since the
prototype is out of scope, the compiler cannot check that the
prototype and definition are consistent.} It also generates data in
your object module telling the linker that foo is here. At the end of
the function, the compiler does not clear the entry because the
definition is at file scope. Any subsequent code would be able to
"see" foo.

During linking, the linker builds tables of functions defined and
functions needed (using the data the compiler put in the object
module). Since foo appears in both, it uses the defined function to
provide the required adjustment at the point where foo is called. Any
functions needed that are not already defined in the object module
(like printf) are found by searching libraries.

--
Remove del for email

[Ben Bacarisse]

mdh <md**@comcast.n etwrites:

On Aug 17, 8:28Â*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>The key part is "declared in separate translation units". Â*Two
structs, declared in the same translation unit, even in separate
scopes, can't ever be compatible -- no matter how similar they look.

OK..., this is unique only to structs, unions and enums. And if so,
is this due to the complicated nature of those objects, and perhaps
the way C stores them internally? Or...that's just the way it
is? :-)

You got me. I don't know. It has the feel of being one of those
things where the rule that got picked is the simplest one that does
what is needed.

--
Ben.

[mdh]

On Aug 17, 11:06*am, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>

The key part is "declared in separate translation units". *Two
structs, declared in the same translation unit, even in separate
scopes, can't ever be compatible -- no matter how similar they look.

OK..., *this is *unique only to structs, unions and enums. And if so,
is this due to the complicated nature of those objects, and perhaps
the way C stores them internally? *Or...that's just the way it
is? *:-)

You got me. *.....

Ben.

Thanks Ben.

Well, you enlightened me, esp with the ref to the "foo" declaration in
main, defined elsewhere.

" They are "linked" by the fact the declaration of foo in
main is, by default, a declaration of a function with extern linkage."

"

[Nick Keighley]

On 17 Aug, 09:25, "Malcolm McLean" <regniz...@btin ternet.comwrote :

"mdh" <m...@comcast.n etwrote in message

On Aug 16, 11:12 pm, santosh <santosh....@gm ail.comwrote:

So I once again ran into a scope issue? *In this case block scope? vs
file scope which you implemented? *Santosh, could you help me
understand why I can declare 'int foo(int);' within "main" and then
call it, but I cannot do the same with the struct?

The struct is not local to main. It is used in another function.
Similarly if you called foo() from anywhere except main(), you'd have to
prototype it again.
This is why we normally place structures and prototypes at the top of the
file, usually wrapped up into a header.

why "usually"?

--
Nick Keighley