I get an ICE C1001 (compiler file 'msc1.cpp', line 2708) again: using
a pointer to member function where the data is wrapped in a namespace.
e.g:
#include <bitset>
namespace Bla
{
typedef std::bitset<2> Bitset2;
}
void TestCePmf()
{
Bla::Bitset2& (Bla::Bitset2::* mpf2)() = &Bla::Bitset2::reset;
<--
}
Comeaus compiler seems to accept it (and since that is a defacto
standard), I suspect a bug vc 7.1. It seems however solvable by adding
an extra typedef:
void TestCePmf()
{
typedef Bla::Bitset2 Bitset2Bla;
Bitset2Bla& (Bitset2Bla::* mpf3)() = &Bitset2Bla::reset;
}
Not answering your question, but note that taking an address of a STL
class' method is not portable. An implementation is allowed to add extra
parameters (with defaults) to any method, so you don't know what
signature the method really has.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925
Huh? I take the address because boost bind can't deal with function
overloads. But it also means that a lot of my code would be non
portable since many STL functions gets bind in it (e.g push_back).
C++ standard:
17.4.4.4/2 An implementation can declare additional non-virtual member
function signatures within a class:
- by adding arguments with default values to a member function
signature;172) The same latitude does not extend to the implementation
of virtual or global functions, however.
- by replacing a member function signature with default values by two or
more member function signatures with equivalent behavior;
- by adding a member function signature for a member function name.
Footnote 172: Hence, taking the address of a member function has an
unspecified type.
That's then the next c++ disappointment which I have to swallow.
Above paragraph does not harm you when you make the direct call.
However most of the time I must adapt functions to work with
<algorithm>, and all those bind constructions are non portable.
Perhaps at the time they did write above standard, there was no
powerful (tr1/boost) bind library which exposes a downside of above
rules.
Maybe this is worth a cross post.