> Thanks for pointing that out. I really missed that. By the way, does
> anyone know the rationale for deprecating static for objects but not fo=
r
> functions? I'm puzzled, because I see more reasons to deprecate static
> functions rather than static objects...


Are you sure you haven't mixed that up.

As far as I am aware, "static" indeed HAS been deprecated for functions,=20
but NOT for objects/variables.

It HASN'T been deprecated for objects/variables because it's used=20
commonly, e.g.:

//some_header.hpp
float const pi =3D 3.14;

which is actually just an abbreviation of:

static float const pi =3D 3.14;


-Tom=E1s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

NULL@NULL.NULL ha scritto:
>> Thanks for pointing that out. I really missed that. By the way, does
>> anyone know the rationale for deprecating static for objects but not for
>> functions? I'm puzzled, because I see more reasons to deprecate static
>> functions rather than static objects...
>
>
> Are you sure you haven't mixed that up.
>
> As far as I am aware, "static" indeed HAS been deprecated for functions,
> but NOT for objects/variables.

That's what I thought, but the standard is unambiguously clear:

7.3.1.1/2: The use of the static keyword is deprecated when declaring
objects in a namespace scope (see annex D); the unnamed-namespace
provides a superior alternative.

D.2/1: The use of the static keyword is deprecated when declaring
objects in namespace scope (see 3.3.5).

> It HASN'T been deprecated for objects/variables because it's used
> commonly, e.g.:

It IS. See above.

> //some_header.hpp
> float const pi = 3.14;
>
> which is actually just an abbreviation of:
>
> static float const pi = 3.14;

Well... Unless explicitly extern, const objects have always internal
linkage regardless of the presence of the static keyword. Please, follow
me, it's very very subtle: the fact that the two syntaxes achieve the
same result does NOT mean that one is (or is intended to be) an
abbreviation of the other, it's just an accident.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In the following code:

template <class T> static void foo (T &x) {
    x = x + 1;
}

template <class T> static void bar(T &x) {
    foo(x);
}

int main() {
    bar(10);
}

The foo function is not considered in bar because foo is not of
external linkage [14.6.4.2]. But this is unintuitive for cases like
this code because the calling function is also not of external linkage,
and both the caller and callee are limited to the same translation
unit. How about relaxing [14.6.4.2] allowing functions with
non-external linkage to consider calls to other functions with
non-external linkage?

Many compilers allow do looking-up function templates with non-external
linkage (EDG allows it in default mode but not in strict mode, sun
compiler has -features=[no%]tmplrefstatic option to allow looking up
such template functions), which is more intuitive for programmers.

-Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

> How about relaxing [14.6.4.2] allowing functions with
> non-external linkage to consider calls to other functions with
> non-external linkage?

    I believe the consensus is that the use of "static" is deprecated, and
that these functions should go in an unnamed namespace.

-Tom   s

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Ganesh ha scritto:
> In the following code:
>
> template <class T> static void foo (T &x) {
>     x = x + 1;
> }
>
> template <class T> static void bar(T &x) {
>     foo(x);
> }
>
> int main() {
>     bar(10);
> }
>
> The foo function is not considered in bar because foo is not of
> external linkage [14.6.4.2]. But this is unintuitive for cases like
> this code because the calling function is also not of external linkage,
> and both the caller and callee are limited to the same translation
> unit. How about relaxing [14.6.4.2] allowing functions with
> non-external linkage to consider calls to other functions with
> non-external linkage?
>
> Many compilers allow do looking-up function templates with non-external
> linkage (EDG allows it in default mode but not in strict mode, sun
> compiler has -features=[no%]tmplrefstatic option to allow looking up
> such template functions), which is more intuitive for programmers.
>

As the use of static in this context is deprecated, I see little
motivation to amend the standard in a way that promotes such use.
Moreover, this is not the only case where the use of static creates
problems with templates, so I would expect programmers to always prefer
unnamed namespaces when dealing with templates, as they are definitely a
much better option.

Just my opinion,

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Ganesh wrote:
> In the following code:
>
> template <class T> static void foo (T &x) {
>     x = x + 1;
> }
>
> template <class T> static void bar(T &x) {
>     foo(x);
> }
>
> int main() {
>     bar(10);
> }
>

and 10 is not an l-value.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> Ganesh ha scritto:
> > In the following code:
> >
> > template <class T> static void foo (T &x) {
> >     x = x + 1;
> > }
> >
> > template <class T> static void bar(T &x) {
> >     foo(x);
> > }
> >
> > int main() {
> >     bar(10);
> > }
> >
> > The foo function is not considered in bar because foo is not of
> > external linkage [14.6.4.2]. But this is unintuitive for cases like
> > this code because the calling function is also not of external linkage,
> > and both the caller and callee are limited to the same translation
> > unit. How about relaxing [14.6.4.2] allowing functions with
> > non-external linkage to consider calls to other functions with
> > non-external linkage?
> >
> > Many compilers allow do looking-up function templates with non-external
> > linkage (EDG allows it in default mode but not in strict mode, sun
> > compiler has -features=[no%]tmplrefstatic option to allow looking up
> > such template functions), which is more intuitive for programmers.
> >
>
> As the use of static in this context is deprecated, I see little
> motivation to amend the standard in a way that promotes such use.
> Moreover, this is not the only case where the use of static creates
> problems with templates, so I would expect programmers to always prefer
> unnamed namespaces when dealing with templates, as they are definitely a
> much better option.

No, the use of the keyword static in this context has not been
deprecated. Appendix D of the C++ Standard deprecates the use of static
when declaring objects in namespace scope. The keyword static in the
case qualifies function definitions in namespace scope. And as    1.8/1
makes clear, a function is not an object.

So although defining a function within an unnamed namespace may in fact
be a better idea than declaring the function static - it would not be a
better idea because the C++ standard has deprecated static functions.
It has not.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy ha scritto:

> No, the use of the keyword static in this context has not been
> deprecated. Appendix D of the C++ Standard deprecates the use of static
> when declaring objects in namespace scope. The keyword static in the
> case qualifies function definitions in namespace scope. And as =A71.8/1
> makes clear, a function is not an object.
>=20
> So although defining a function within an unnamed namespace may in fact
> be a better idea than declaring the function static - it would not be a
> better idea because the C++ standard has deprecated static functions.
> It has not.

Thanks for pointing that out. I really missed that. By the way, does
anyone know the rationale for deprecating static for objects but not for
functions? I'm puzzled, because I see more reasons to deprecate static
functions rather than static objects...

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]