MESSAGE
| DATE | 2010-02-13 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] C++ Workshop - side discussing on C++ variable declarations
|
On Thursday 11 February 2010 19:24:44 Ruben Safir wrote:
> On Thu, Feb 11, 2010 at 07:01:11PM -0500, Ajai Khattri wrote:
> > On Thu, 11 Feb 2010, Ruben Safir wrote:
> > > Anyone have any constructive insight on this conversation I had with a
> > > friend?
> >
> > I dont see what the problem is. If you're linking to code that is outside
> > the current file you must tell the compiler that it is defined
> > EXTERNally.
> >
> > Often when your code is spread across several files, you might want to
> > refer to symbols defined in other files or other libraries, so you must
> > declare them ahead of your code.
>
> Its the idea that if you define the var (that is, not use the extern
> keyword), that it can create a problem that is bothering me and getting
> under my skin.
My understanding is the 'extern' keyword for a variable in a header means that
a variable is defined _elsewhere_, but that the code section that loads the
header should also have access to the variable. The variable does have to be
declared elsewhere (in only one place) _without_ the 'extern' keyword for this
to work.
This is confusing, so think of it as having a similar context to an additional
"hard link" on a filesystem which has the same name but in a different
directory. A concrete example: say you've got a Linux box in which there is
only a root / filesystem, and you have a user account on the system in /home
under the username 'rsafir'. If you then make a hard link in your home
directory named 'rsafir' which references an mbox file in /var/mail/rsafir,
then both the /home/rsafir/rsafir and /var/mail/rsafir hard links point to the
same inode, and thus the /same file/, with the same storage location on disk.
If you instead make a new file in your home directory with the same name of
'rsafir', a new inode is created and the hard link that is made to this inode
has the same name, but /does not/ point to the one in /var/mail/rsafir, and
does not share the same storage location on disk.
So likewise, without the 'extern' keyword, what would happen is that you'd
have /another/ variable with the same name, with a different unique storage
location, leading to confusion. [Same variable name, but different scope!]
The linker has to figure out where the 'extern' "links" go. In other words,
when you use the 'extern' keyword you're telling the compiler that the
variable does exist somewhere else, and it "takes it on faith" with the
expectation that the linker will be able to figure out where that variable is
so that it can complete the "link" later.
Although I *think* I understand the theory, the actual practice of using this
feature still confuses me a bit.
> There is also the lack of clarity with declaration, and defining that is
> bothing me. It gets down to compiler theory and behavior, which I'm
> trying to slowly bring in with accuracy to the working write up. I know
> more than most, but not nearly enough. Hopefully, doing this will get
> me to clarify a lot of the compiler issues. Most of all, I want to
> right correct material.
I've always wanted some clarification on this issue, too. i.e. keep up the
good work. :-)
-- Chris
--
Chris Knadle
Chris.Knadle-at-coredump.us
|
|
