Re: Yet another brute force sudoku solver

Giorgos Keramidas said:

On Mon, 20 Oct 2008 04:51:34 -0700 (PDT), jameskuyper@xxxxxxxxxxx wrote:
Richard wrote:
jameskuyper@xxxxxxxxxxx writes:
Richard wrote:
"Default User" <defaultuserbr@xxxxxxxxx> writes:
Trent Josephsen wrote:
Boon wrote:
#include <stdio.h>

static int grid[9][9];
...
And file scope IS global (as anyone without a rod up their arse
knows

it) since anyone can declare an extern and then see it.
...
suggesting, such declarations have internal linkage, not external
linkage. As a result, declaring the same identifier with external
linkage in a different translation unit will not make this
definition visible in that translation unit. You need to understand
the distinction between scope and linkage.

I dont know where you got that impression of my meaning. I suppose its
that word "declare" again. I should have posted an example.

Perhaps you should. I don't know how to make a file scope identifier
with internal linkage (such as the array 'grid' defined above) visible
from another translation unit by "declar[ing] an extern", unless the
identifier with external linkage refers to something different from
what the identifier with internal linkage refers to. If you know how
to do this, could you give us an example?

You can define an object with internal linkage in one file, and a
function with external linkage that returns a pointer to that object.
Then other translation units can call the function to obtain the runtime
location of the object and use the pointer to access it.

Yes, and that would provide access to the object in question, but not using
the *identifier* in question. In the case in point, the identifier,
'grid', is at file scope (which means it can be seen throughout the rest
of the translation unit in which it appears) but is static (which means it
can't be seen from anywhere else). James's point is that just adding:

extern int grid[9][9];

to another translation unit will *not* make the original identifier visible
in that other translation unit.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: extern
    ... For objects it is a "tentative declaration" NOT an extern, although it has external linkage. ... If nothing else is seen by the end of the translation unit then it is as if there was a declaration with a 0 initialiser at the end of the translation unit. ...
    (comp.lang.c)
  • Re: Scope of specifier extern
    ... But none of them have scope; ... The keyword "extern" affects ... The "scope" concept answers the question "can I `see' that identifier ... The "linkage" concept ...
    (comp.lang.c)
  • Re: Array definition guarantees
    ... linkage tells you where, ... identifier that is spelled sufficiently similarly. ... I think it is closer to say that scope tells you where the name ... The second glitch in this is the "extern" keyword. ...
    (comp.lang.c)
  • Re: redeclaration of p with no linkage
    ... Such objects have 'no linkage' and you can't have two of them in the ... same scope. ... "For an identifier declared with the storage-class specifier extern in ... the prior declaration specifies internal or external linkage, ...
    (comp.lang.c)
  • Re: Array definition guarantees
    ... linkage tells you where, ... identifier that is spelled sufficiently similarly. ... I think it is closer to say that scope tells you where the name ... The second glitch in this is the "extern" keyword. ...
    (comp.lang.c)