auto_ptr and arguments

[Noah Roberts]

Often I have a method which accepts a pointer to some class as an
argument. Usually that pointer is managed by the caller through
std::auto_ptr. I would assume that you could pass the auto_ptr in to
the method call and conversion would automagically take place, but this
does not happen. I end up having to explicitly call auto_ptr.get().

Is there a good way around this?

NR

[Michael Winter]

Re: auto_ptr and arguments

There's no conversion operator that returns a value of type T* (where T is
the element type), so in the first case: no. The only way to get around
this would be to derive a class from this one with a method like:

template <class T>
class MyAutoPtr : public std::auto_ptr<T >
{
public:
operator( _Ty* ) const { return _Ptr; }
}

This is probably flawed syntactically (many times over), but you get the
point.

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.u k (remove [no-spam] to reply)

[Gianni Mariani]

Re: auto_ptr and arguments

Noah Roberts wrote:[color=blue]
> Often I have a method which accepts a pointer to some class as an
> argument. Usually that pointer is managed by the caller through
> std::auto_ptr. I would assume that you could pass the auto_ptr in to
> the method call and conversion would automagically take place, but this
> does not happen. I end up having to explicitly call auto_ptr.get().
>
> Is there a good way around this?[/color]

No.

auto_ptr is designed specifically to manage that pointer and it is
trying to make sure you do not inadvertenly put that pointer into
another auto_ptr.

I think it's a bit over the top myself but it's not my call.

I have written a more lax replacement for auto_ptr butI would only
reccomend it to people who know what they're doing with all the hidden
issues that come with it.

You could theoretically do this yourself - create a class that is an
auto_ptr that knows how to convert implicitly.


template <typename T>
class MyNastyAutoPtr : public auto_ptr<T>
{
public:

MyNastyAutoPtr( ....)
... other constructors and assignment mumbo jumbo ...

operator const T* ()
{
return get();
}

};

[Shane Beasley]

Re: auto_ptr and arguments

Noah Roberts <nroberts@donte mailme.com> wrote in message news:<3F6C9090. 3010504@dontema ilme.com>...
[color=blue]
> Often I have a method which accepts a pointer to some class as an
> argument. Usually that pointer is managed by the caller through
> std::auto_ptr. I would assume that you could pass the auto_ptr in to
> the method call and conversion would automagically take place, but this
> does not happen. I end up having to explicitly call auto_ptr.get().[/color]

auto_ptr is designed to be used like a pointer, not to be
interchangeable with pointers; conversions either way are explicit. It
should not be possible to accidentally give ownership to auto_ptr, nor
to transfer ownership from auto_ptr to some other entity. (It is with
this in mind that I usually shun auto_ptr altogether, in favor of
boost.org smart pointers, where applicable; auto_ptr's copy semantics
are incorrect in almost every case except when returning a dynamic
object from a function. But since it's the only standard smart pointer
right now, I wouldn't blame anyone for using it exclusively.)
[color=blue]
> Is there a good way around this?[/color]

No, nor should there be. ap.get() is the designated way to get access
to the underlying pointer. If you're insane, you could overload your
functions to accept either a pointer or an auto_ptr; or you could
accept, by value or const reference, a class which offers an implicit
conversion from either. But that's a lot more work than just using
"ap.get()" when you mean "get ap's underlying pointer."

- Shane

[Kevin Goodsell]

Re: auto_ptr and arguments

Michael Winter wrote:
[color=blue]
> There's no conversion operator that returns a value of type T* (where T is
> the element type), so in the first case: no. The only way to get around
> this would be to derive a class from this one with a method like:
>
> template <class T>
> class MyAutoPtr : public std::auto_ptr<T >
> {
> public:
> operator( _Ty* ) const { return _Ptr; }[/color]

These identifiers are reserved for the implementation. C++ programs are
forbidden to use identifiers beginning with an underscore followed by
either an upper case letter or another underscore. Your standard library
probably does this, but that's because it is part of the implementation
and is required to do so - otherwise, it would be treading on names that
are reserved for *your* use.

Also, when you reply please quote some relevant context from the message
you are replying to. Otherwise we don't know exactly what message you
are replying to, and it may even be a message that we haven't received yet.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Noah Roberts]

Re: auto_ptr and arguments

Gianni Mariani wrote:[color=blue]
> Noah Roberts wrote:
>[color=green]
>> Often I have a method which accepts a pointer to some class as an
>> argument. Usually that pointer is managed by the caller through
>> std::auto_ptr. I would assume that you could pass the auto_ptr in to
>> the method call and conversion would automagically take place, but
>> this does not happen. I end up having to explicitly call auto_ptr.get().
>>
>> Is there a good way around this?[/color]
>
>
> No.
>
> auto_ptr is designed specifically to manage that pointer and it is
> trying to make sure you do not inadvertenly put that pointer into
> another auto_ptr.[/color]

That actually makes a lot of sense to me now that I think about it.

Thanks,
NR

[Andre Kostur]

Re: auto_ptr and arguments

Noah Roberts <nroberts@donte mailme.com> wrote in news:3F6C9090.3 010504
@dontemailme.co m:
[color=blue]
> Often I have a method which accepts a pointer to some class as an
> argument. Usually that pointer is managed by the caller through
> std::auto_ptr. I would assume that you could pass the auto_ptr in to
> the method call and conversion would automagically take place, but this
> does not happen. I end up having to explicitly call auto_ptr.get().
>
> Is there a good way around this?[/color]

Well... the first question I'd have is: do you _really_ understand what
auto_ptr<> does?

and... have your function take in an auto_ptr<>& instead of a naked pointer
(if you want to assume that everyone calling you will get using auto_ptr
<>), or you have to .get() the pointer out of the auto_ptr<>.

Automatically converting the auto_ptr<> to a pointer would make it too easy
to "accidental ly" get a copy of the pointer, let the auto_ptr go out of
scope, then use that copy of the pointer (now pointing at deleted
memory....)