Re: Question about variable scope conflict
- From: dj3vande@xxxxxxxxxxxxxxxxxxxxxxxxxxx
- Date: Fri, 30 Nov 2007 19:15:23 +0000 (UTC)
In article <KJ6dnaWOWI16xc3aRVnyuQA@xxxxxx>,
Richard Heathfield <rjh@xxxxxxxxxxxxxxx> wrote:
David Mathog said:
Apparently it allows
it, I guess to avoid accidental name conflicts, for instance between a
global in a library and a similarly named variable in a function.
Presumably, yes - but it's Yet Another Good Reason to minimise or even
eliminate your use of file scope objects.
I've found that putting all of the file scope objects in one of two
structs (one for external linkage and one for internal) both makes it
harder to run into this problem and makes keeping track of what's where
a lot easier.
(So instead of having num_fds at file scope and curr_fd at function
scope, I have ioloop_data.num_fds at file scope and when I see curr_fd
in the code I know it's _not_ at file scope.)
This also has the side effect of making it a lot easier to eliminate
file-scope variables entirely should it be necessary to do so (they're
already wrapped up nicely in a struct, and all that's required is
adding code to create and destroy copies of that struct and changing
the existing interfaces to include a pointer to that struct everywhere
- not always trivial, but not nearly as hard as it could be). I've had
to do that rather less often than I've written code that used a single
struct to hold its file-scope objects, but even looking at just that
side effect the cost-benefit ratio probably comes out favoring the
benefit side.
dave
.
- References:
- Question about variable scope conflict
- From: David Mathog
- Re: Question about variable scope conflict
- From: Richard Heathfield
- Question about variable scope conflict
- Prev by Date: Re: memcat fn
- Next by Date: Re: Global Variables : Where are they stored ?
- Previous by thread: Re: Question about variable scope conflict
- Next by thread: bus error
- Index(es):
Relevant Pages
|
