Re: static methods of local structs as template parameters
On 2012-11-15 01:18, Chris Vine wrote:> In C++98/03 I have on occasions
used static methods of local structs in
function scope to emulate nested functions in the kind of circumstances
where in C++11 you might use a lambda expression. Sometimes the static
method might be passed to a standard container algorithm, such as
std::find_if() or std::transform(). An argument may or not be bound
with std::ptr_fun() and std::bind2nd/bind1st().
This has worked on every version of gcc I have tried it on but it has
been suggested to me that in C++98/03 (as opposed to C++11) I have
just been lucky and it contravenes ?14.3.1.2 of the C++98 standard which
provides that:
"A local type, a type with no linkage, an unnamed type or a type
compounded from any of these types shall not be used as a
template-argument for a template type-parameter."
I suspect he may be right.
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.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]