Re: static methods of local structs as template parameters
{ Your quoting is excessive. Please trim your quoting and try to include
only the minimum necessary to establish the context. -mod }
On Fri, 16 Nov 2012 03:17:32 CST
Daniel Kr?gler <daniel.kruegler@googlemail.com> wrote:
[snip]
First I would like to be sure that I understand your usage of these
static functions. Here is a canonical example of what I believe is
your use-case:
#include <algorithm>
void test(int* b, int* e) {
struct L {
static bool isOK(int a) { return a == 42; }
};
std::find_if(b, e, L::isOK);
}
Is this a correct example?
Although the type of a static member
function seems to me to be a function and not a local type, the
question is whether static member functions of local classes have
linkage. ?3.5/5 provides that a member function of class scope has
external linkage if the name of the class has external linkage,
which it doesn't in this case, and ?3.5/8 provides that "Names not
covered by these rules have no linkage".
I agree with that conclusion.
If right, it would follow that static member functions of local
structs could only be used in this way in C++98 as arguments to
non-template functions. Or possibly, by virtue of ?3.5/2 the
static member function cannot be referred to by function pointer at
all.
A strict reading of the C++03 wording allows this interpretation, but
I'm not aware of an implementation that really enforces this, see
below for reasons why they don't.
The actual part that enters during template deduction is the function
pointer of type "bool (*)(int)" in above example. Note that
[temp.deduct.call] p2 says:
"2 If P is not a reference type:
[..]
? If A is a function type, the pointer type produced by the
function-to-pointer standard conversion (4.3) is used in place of A
for type deduction; [..]"
Even if P is a reference type, I there is no really a problem here,
because still the deduced type ("bool(int)") is independent of the
local type name L.
The actual reason for the previous restriction was related to the
problem of implementations that did somehow need to mangle the actual
local type (Like that of L above) and any derived types. This could
easily happen in variants of above canonical examples, like this one:
#include <algorithm>
void test(int* b, int* e) {
struct L {
bool operator()(int a) const { return a == 42; }
};
std::find_if(b, e, L());
}
This is indeed in violation with the C++03 standard and several
implementations do correctly reject that.
What do people think is this the correct construction of the C++98
standard in this case?
According to a very conservative interpretation, yes. But this problem
has early been noticed to be actually a defect in the C++03 standard,
see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#319
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#389
which are both fixed in CD1, so can be considered as fixes of issues
of the C++03 standard. If you look at the given examples (especially
in #319), you will find several examples that would not be supported
by a strict reading, but everyone expects them to do that.
Personally I would consider your usage as "intended to work" and I'm
unaware of any C++98/C++03 implementation that doesn't support it.
Thank you. Yes, I am concerned with the first example you give above.
I was aware that the second case (trying to instantiate a template with
a local functor class as type parameter) would fail in C++98. It was
to work around that that I have on occasions used the static member
function approach to localise simple predicates, transformations and
the like.
This linkage issue is quite interesting and I have been playing around
with it. I think I have managed to provoke an issue with gcc-4.4 to
gcc-4.6 when passing a static member function of a local struct as an
argument to a non-template library function which takes the function as
a callback, including when using the -std=c++0x flag. I cannot get
gcc-4.7 to misbehave though. However, the effect is quite
unpredictable, so I may have got my tests wrong. If I have found
something, the conclusion may be that you are safe instantiating
template functions, such as the standard container algorithms, with
static member functions of local structs because in fact there will be
no external linkage involved and for the reasons you mention the
templates will resolve correctly, but not necessary if you export the
static member functions to external entities.
If I have read it right, this seems to be the issue in the defects
reports you mention. However, referring to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#389 , the
library function I have tested has C++ and not C linkage so is not able
to take advantage of the dispensation mentioned there.
Chris
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]