C1001 ICE with .NET 2003 compiling pointer to member functions
gas...@hotmail.com
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;
}
Igor Tandetnik
news:1186487558.1...@g4g2000hsf.googlegroups.com
> #include <bitset>
>
> namespace Bla
> {
> typedef std::bitset<2> Bitset2;
> }
>
> void TestCePmf()
> {
> Bla::Bitset2& (Bla::Bitset2::* mpf2)() = &Bla::Bitset2::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
gas...@hotmail.com
>> ...
>>
> > void TestCePmf()
> > {
> > Bla::Bitset2& (Bla::Bitset2::* mpf2)() = &Bla::Bitset2::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).
Igor Tandetnik
news:1186524482.0...@g4g2000hsf.googlegroups.com
> On 7 aug, 20:43, "Igor Tandetnik" <itandet...@mvps.org> wrote:
>>> ...
>>>
>>> void TestCePmf()
>>> {
>>> Bla::Bitset2& (Bla::Bitset2::* mpf2)() = &Bla::Bitset2::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.
>
> 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.
gas...@hotmail.com
> <gast...@hotmail.com> wrote in message
> 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.