Re: [Boost-users] static reflection

Subject: Re: [Boost-users] static reflection
From: James Pritts (jbpritts_at_[hidden])
Date: 2008-09-18 10:29:57

So is the error valid, meaning does the error conform the C++
standard?   In that case MSVC 9  would be the compiler in error, and
the code is malformed.  There is a subtlety to the using keyword when
making base class overloaded member visible.  I read that using
"introduces" the member function to the scope of the derived class,
rather than making it part of the derived class's type.  The gcc
compiler is refusing to cast the
ReturnType(DerivedClass::*)(ArgumentType) to
ReturnType(BaseClass::*)(ArgumentType).  This is a show stopper
because there is no way to explicitly get the address of the
overloaded base class member.  e.g.  I cannot say
&Class::operator(float), I can only say &Class::operator() and the
lvalue in an assignemtn statement determines which function address to
acquire.  In a larg inheritance tree, however, I would have no way of
knowing what base class the overloaded operator is defined in.

I was using MPL to automatically create boost::variant static visitors
from a group of standalone classes by using inheritance.  The using
keyword is required because visitors overload operator()(...) for
their various types, and overloaded members are hidden by default when
inheriting.  I never understood why this is the case.

Later in the code, I need to check if the static visitor supports a
type at run time.  This is why I need member function introspection,
and it would have worked save for this one obscure snafu.  It works on
MSCV9 according to Steven, but that does me no good.

Jimmy.

On Thu, Sep 18, 2008 at 5:12 AM, Manfred Doudar
<manfred.doudar_at_[hidden]> wrote:
> On Thu, 18 Sep 2008 10:15:23 +0200
> Filip Konvièka <filip.konvicka_at_[hidden]> wrote:
>
>> Hi,
>>
>> > Sorry for top posting here, but I didn't receive Steven's response.
>> > I'm using i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build
>> > 5488).
>>
>> I used to do some member function pointer tests myself, and I was
>> stopped by c++/8171 (fixed in gcc 4.3.0).
>>
>> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8171
>>
>> I don't know if it is the case here though.
>>
>
> Nope - tried on Linux i686, GCC 4.3.0 and the same error as reported by
> James.
>
>
> --
> Manfred
> 18 September, 2008
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users