Re: "static" objects and functions
On Jun 2, 4:04 pm, Jess <w...@hotmail.com> wrote:
[...]
Thank you so much for giving me these examples. :) There are really
so many incoherences, headache...Moreover, about the requirement on
"const" ("const object is illegal unless the object either has a non-
trivial constructor or an initializer"), is it universal or is it only
applicable when it's within a namespace?
It's universal, but it applies (obviously, if you think about
it) when the object is created, not when it is declared. So:
struct Toto
{
int const titi ; // No initializer here...
Toto() ;
} ;
Toto::Toto()
: titi( 42 ) // initializer required here...
{
}
There is a special case for const static members of integral
type; the initializer can appear in the declaration (in the
class definition) rather than in the definition of the object.
[...]
How can a function be declared within such local scope?
void
f()
{
std::vector< int > v( std::istream_iterator< int >( file ),
std::istream_iterator< int >() ) ;
}
:-). The problem is more often, how can we ensure that a
definition is not a function declaration in local scope; in the
above, the programmer probably wanted to define a local variable
v, using the two iterator constructor of vector. In fact, he has
declared a function (with external linkage, in global scope)
taking two arguments, and istream_iterator<int>, and a pointer
to a function returning and istream_iterator<int>, and returning
a vector<int>.
Why is above a declaration?
Because the standard says that if something can be interpreted
as a declaration, it is. Both of the sub-expressions
"std::istream_iterator< int >( file )" and
"std::istream_iterator< int >()" can be interpreted as
declarations. And if they are declarations, then the result is
the declaration of a function. To make it clearer, replace the
complicated type names with simple symbols: A for
"std::vector< int >", and B for "std::istream_iterator< int >":
A v( B (file), B() ) ;
Now, remove the superfluous parentheses, and rewrite the second
declaration according to the special rules which apply to
function parameters, and you get:
A v( B file, B (*)() ) ;
Which looks very much like a function declaration, a function v
taking two arguments, a B, and a pointer to a function returning
a B, and returning an A.
It doesn't look like a definition either.
To me, it looks like calling the function "v": the first argument
passed to "v" is an iterator (constructed from "file") and the second
argument is also an iterator, constructed by the default
constructor.
And what does the "std::vector< int >" do in the statement? If
a statement starts with the name of a type, and that name is not
immediately followed by a '(', it's either a declaration of some
sort, or completely illegal. (If the name of the type is
immediately followed by a '(', it might still be a declaration.
Or it might not be, depending on what follows.)
[...]
There's an interesting (perverse?) example of this in the
standard:
static int i ; // 1.
void g()
{
int i ; // 2. Hides the static 1.
{
extern int i ; // 3.
}
}
The line labeled 3 refers to yet a third object (not defined
here): since the declaration at 2 hides the declaration at 1,
the compiler doesn't "see" it, and since the declaration at 2
has no linkage, the declaration at 3 declares a new object, with
external linkage (different from the object with internal
linkage defined at 1).
I can see that declaration at line 2 hides declaration at 1. I think
"i" at line 2 is also a definition, which is visable to inner block
(i.e. line 3).
That's correct so far.
Therefore, I think line 3 is saying declare the "i" at
line 2 as external.
That would be logical, and it would be logical (IMHO) for the
above to be an error, since there are conflicting linkage
specifications. According to the standard, however, the "i" in
line 2 has no binding, so no other declaration can refer to it.
Thus, since line 3 can't refer to it, and line 1. isn't visible
at this point, line 3 declares still another i.
Whether you or I think that this is a good idea, or the way it
should be, is irrelevant. The above example is taken directly
from the standard.
I thought in general, objects declared at outer
block are always visible in the inner blocks, unless there's a re-
declaration/definition of it in the inner blocks, is this wrong?
(And if you aren't thoroughly confused yet, you should be.)
I am thoroughly confused, as you've correctly guessed... :(
Well, you seemed to want to know all of the details. And they
are confusing. I've written compilers in the past, and worked
with language standards for something like 20 years, and I still
have to go very, very slowly when attacking this in C++. (And
if you think that this is confusing, wait until you attack
function overload resolution, or name binding in templates.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34