Dereferencing std::auto_ptr to invoke a member function

[matt.elkins]

Hello all, this is my first time posting. I was recently working on a
project that involved significant use of member function invocations.
It just so happened that one object on which I wished to invoke a
method was wrapped in an std::auto_ptr, but interestingly enough, I
could not invoke the method straight from the std::auto_ptr -- I had
to extract the underlying object pointer first. As an illustration
(off the top of my head, I did not test this particular example):

// Define Foo
struct Foo {void Bar() {}};

// Use a typedef to make life easier, then create the method pointer
typedef void (Foo::*FOO_FUN)();
FOO_FUN fun(&Foo::Bar);

// Create two Foos -- one wrapped in an std::auto_ptr, one not
Foo * foo1(new Foo);
std::auto_ptr <Foo> foo2(new Foo);

// Attempt invocation
(foo1->*fun)(); // Works
(foo2.get()->*fun)(); // Works
(foo2->*fun)(); // Compiler error

This error was caused by the fact that ->* is a single, distinct
operator, not a composition of -> and *, and the std::auto_ptr was
overloaded for -> but not ->* (at least according to the documentation
on std::auto_ptr that I could find -- I was not reading the Standard
itself). This long-winded preamble (apologies) brings me to my
question: was this overload intentionally left out of std::auto_ptr,
or is it an oversight (or is it actually in there and just an
oversight in the implementation)? If intentional, what was the
rationale? If not intentional, what the odds we will see it in the
next Standard?

Thanks!
-Matthew Elkins

 

[Victor Bazarov]

[..problem arising auto_ptr's not overloading operator->* ..]
This long-winded preamble (apologies) brings me to my
question: was this overload intentionally left out of std::auto_ptr,
or is it an oversight (or is it actually in there and just an
oversight in the implementation)? If intentional, what was the
rationale? If not intentional, what the odds we will see it in the
next Standard?

The correct place to ask those questions would be 'comp.std.c++'
where they discuss the standardisation process, rationales, what
goes into the next one, etc.

AFAIK, auto_ptr (and its variations) provides no overload for ->*
(as per the Standard).

V

 

[matt.elkins]

[..problem arising auto_ptr's not overloading operator->* ..]
This long-winded preamble (apologies) brings me to my
question: was this overload intentionally left out of std::auto_ptr,
or is it an oversight (or is it actually in there and just an
oversight in the implementation)? If intentional, what was the
rationale? If not intentional, what the odds we will see it in the
next Standard?

The correct place to ask those questions would be 'comp.std.c++'
where they discuss the standardisation process, rationales, what
goes into the next one, etc.

AFAIK, auto_ptr (and its variations) provides no overload for ->*
(as per the Standard).

V

Apologies, I'll do so.

 

[James Kanze]

On Nov 29, 6:41 pm, (e-mail address removed) wrote:

[...]

This error was caused by the fact that ->* is a single, distinct
operator, not a composition of -> and *, and the std::auto_ptr was
overloaded for -> but not ->* (at least according to the documentation
on std::auto_ptr that I could find -- I was not reading the Standard
itself). This long-winded preamble (apologies) brings me to my
question: was this overload intentionally left out of std::auto_ptr,
or is it an oversight (or is it actually in there and just an
oversight in the implementation)? If intentional, what was the
rationale? If not intentional, what the odds we will see it in the
next Standard?

I think it's intentional. Try modifying auto_ptr to support it,
and I think you'll see why. It's a bother, but most programs
don't use ->* that much, so it's something we can live with.

If you do know how to implement it, and are willing to write up
a proposal, I'm sure that the committee would be interested.
Not necessarily for auto_ptr itself (which some members of the
committee want to deprecate), but for the new intelligent
pointers being added.