auto_ptr_ref

[Neelesh Bodas]

Hello All,
My question is regarding the implementation of auto pointers - How
does the class auto_ptr_ref work?

eg: suppose I have :

auto_ptr<int> foo();

int bar()
{
auto_ptr<int*> k = foo();
}

The exact sequence of calls as I see here is (no optimizations assumed)
-
1) foo returns auto_ptr<int> by value
2) CC is called on the return value.
3) The returned auto_ptr<int> is converted to auto_ptr_ref<in t> by
using operator auto_ptr_ref
4) Now since this is a copy initialization and not a direct
initialization, the RHS (whose type is now auto_ptr_ref<in t>) needs to
get converted to auto_ptr<int> again - done by ctor of auto_ptr<int>
which takes auto_ptr_ref<in t>
5) Now CC should be called - but again we are back to old problem - the
generated auto_ptr is temporary and hence cannot be passed as a
non-const reference to the function.

Seems I am going somewhere in cycle :-(

Josuttis' book doesnot say enough on this -

<quote>
"The mechanism relies on a slight difference between the overloading
and template argument deduction rules. This difference is too subtle to
be of use as a general programming tool, but it is sufficient to enable
the auto_ptr class to work correctly."
</quote>

Can somebody explain what I am not getting here?

[Alf P. Steinbach]

* Neelesh Bodas:

eg: suppose I have :

auto_ptr<int> foo();

int bar()
{
auto_ptr<int*> k = foo();
}

The exact sequence of calls as I see here is (no optimizations assumed)
-
1) foo returns auto_ptr<int> by value
OK.

2) CC is called on the return value.
No, there is no std::auto_ptr( std::auto_ptr const& ) copy constructor.

3) The returned auto_ptr<int> is converted to auto_ptr_ref<in t> by
using operator auto_ptr_ref
OK.

4) Now since this is a copy initialization and not a direct
initialization, the RHS (whose type is now auto_ptr_ref<in t>) needs to
get converted to auto_ptr<int> again - done by ctor of auto_ptr<int>
which takes auto_ptr_ref<in t>
OK.

5) Now CC should be called
No, you've reached the goal.

- but again we are back to old problem - the
generated auto_ptr is temporary and hence cannot be passed as a
non-const reference to the function.

What generated auto_ptr? The one generated is the one you've named 'k'.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Neelesh Bodas]

Hi Alf, Thanks for the help.

Actually, more I think on this, more confusion it is creating.

auto_ptr<int> foo();

int bar()
{
auto_ptr<int*> k = foo();
}

Isn't is correct that whever a function returns by value, a CC must get
called on the return value(Though it might be optimized away by the
compiler?)

No, there is no std::auto_ptr( std::auto_ptr const& ) copy constructor.

I believe that we do not need a std::auto_ptr( std::auto_ptr const& )
copy constructor - std::auto_ptr( std::auto_ptr& ) would do the work -
since the source of the copy inside "foo" is not necessarily a const :

std::auto_ptr<i nt> foo()
{
std::auto_ptr<i nt> v;
return v; // a copy ctor will be called on v since this is return by
value
}

But when I debugged throgh std::auto_ptr code I didnot find any call to
the given copy constructor (as you said in the reply.)

I am not getting where exactly I am going wrong.

[Alf P. Steinbach]

* Neelesh Bodas:

Hi Alf, Thanks for the help.

Actually, more I think on this, more confusion it is creating.

auto_ptr<int> foo();

int bar()
{
auto_ptr<int*> k = foo();
}
Isn't is correct that whever a function returns by value, a CC must get
called on the return value(Though it might be optimized away by the
compiler?)
No. _Some_ constructor must be called. That call can be optimized
away, but the constructor must be available to be called (the as-if rule
for optimization).

No, there is no std::auto_ptr( std::auto_ptr const& ) copy constructor.

I believe that we do not need a std::auto_ptr( std::auto_ptr const& )
copy constructor - std::auto_ptr( std::auto_ptr& ) would do the work -
since the source of the copy inside "foo" is not necessarily a const :

std::auto_ptr<i nt> foo()
{
std::auto_ptr<i nt> v;
return v; // a copy ctor will be called on v since this is return by
value
}

But when I debugged throgh std::auto_ptr code I didnot find any call to
the given copy constructor (as you said in the reply.)

That is unfortunately a different effect.

Here the reference-to-non-const copy constructor could be called, and I
believe _is_ called at the formal level (the C++ abstract machine
level), but that call is optimized away by your compiler.

However, declare 'v' as const, or use a temporary, and you're no longer
in possible copy constructor call territory: _some_ constructor must be
called (although it can be optimized away), but in the case of const or
temporary auto_ptr that constructor isn't the copy constructor.

I am not getting where exactly I am going wrong.

This time it was mistaking the compiler's optimization as confirmation
of a misinterpretati on of what I wrote (sorry about not being more
clear). I didn't mean that a copy constructor is never called for any
function result. I meant that a copy constructor does not always have
to be called, and in particular I meant, and wrote, that std::auto_ptr
doesn't have a ref-to-const copy constructor, which is the usual copy
constructor used for a function result.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Neelesh Bodas]

Hello Alf,

Alf P. Steinbach wrote:

No. _Some_ constructor must be called. That call can be optimized
away, but the constructor must be available to be called (the as-if rule
for optimization).

Thanks, this clears my misunderstandin g.

Continuing on my previous mail, we see that there are _two_ user
defined conversions going on one after the other in a single expression
-

1) std::auto_ptr<i nt> to std::auto_ptr_r ef<int> by a call to
std::auto_ptr<i nt>operator auto_ptr_ref<in t>()
2) Call to the converting constructor
std::auto_ptr<i nt>(std::auto_p tr_ref<int>) to create the result of type
auto_ptr<int>

If I understand right, since both of these are user defined
conversions, only one of them is allowed.

Could you please comment on this?

[Alf P. Steinbach]

* Neelesh Bodas:

* Alf P. Steinbach:

No. _Some_ constructor must be called. That call can be optimized
away, but the constructor must be available to be called (the as-if rule
for optimization).

Thanks, this clears my misunderstandin g.

Continuing on my previous mail, we see that there are _two_ user
defined conversions going on one after the other in a single expression
-

1) std::auto_ptr<i nt> to std::auto_ptr_r ef<int> by a call to
std::auto_ptr<i nt>operator auto_ptr_ref<in t>()
2) Call to the converting constructor
std::auto_ptr<i nt>(std::auto_p tr_ref<int>) to create the result of type
auto_ptr<int>

If I understand right, since both of these are user defined
conversions, only one of them is allowed.

Could you please comment on this?

I'd rather not... ;-)

Because it's an issue that people tend to have to agree to disagree on.

My personal take is that the second doesn't really count as a user
defined conversion because it's not a conversion producing a temporary;
it's like plugging a char const* into a std::string constructor with
direct initialization syntax (see below); no conversion has to be found
by the compiler, it's a direct match.

But that is just a convenient shovel-it-under-the-carpet-and-wave-
yer-hands-frantically explanation, because if you do

class Base {};
class Derived: public Base {};

std::auto_ptr<B ase> x = std::auto_ptr<D erived>( new Derived );

then you _are_ up against the single conversion rule, and the only thing
different seems to be use of a templated constructor.

On the other hand (or is it the third, now), if you write the
initialization as a direct initialization,

std::auto_ptr<B ase> x( std::auto_ptr<D erived>( new Derived ) );

then with a standard-conforming compiler all is a good (note here: MSVC
7.1 is not a standard-conforming compiler in this respect).

Perhaps someone who Really Really Knows could be kind enough to comment
on the formal "why" your point (2) isn't counted in the number of
user-defined conversions involved -- or perhaps that it is but that
the standard library is allowed to do anything, whichever is the case.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Neelesh Bodas]

Alf P. Steinbach wrote:

then you _are_ up against the single conversion rule, and the only thing
different seems to be use of a templated constructor.

I observed a similar behaviour with a non-templated constructor also -

class Y { } ;
class X {
public:
X() { }
X (X&) { } // copy constuctor takes non-const reference
operator Y();
X(Y) { }
} ;

X foo() { X p; return p; }

int main()
{
X k = foo();
}

Here -
1) foo returns an object of type X by value. This is a temporary.
2) since this temporary cannot be passed as a reference-to-non-const,
hence the copy constructor is of no use here
3) So operator Y() is called on this temporary, and it returns another
object of type Y.
4) Now again the converting constructor X(Y) will be called and the
resulting value is put into k.

Since this is a copy initialization (and not a direct initialization) ,
I was thinking that this involved _two_ calls to user defined
conversion operators. But still this compiles (Comeau online, g++
3.4.2)

[Aleksey Loginov]

Neelesh Bodas wrote:

Hello All,
My question is regarding the implementation of auto pointers - How
does the class auto_ptr_ref work?

eg: suppose I have :

auto_ptr<int> foo();

int bar()
{
auto_ptr<int*> k = foo();
}

as you know, it's not possible to pass RHS "foo()" as non const
reference "auto_ptr &".
but you can call it's not const methods "foo().nonconst ()".
so, "auto_ptr" use that fact to allow constructor modify RHS.

as illustration
#include<iostre am>

struct auto_ptr {
int n;
static int next () { static int i; return ++i; }

struct auto_ptr_ref {
auto_ptr * ptr;
auto_ptr_ref ( auto_ptr * p ) : ptr (p) {}
};

auto_ptr () : n (next()) { std::cout << this << ":auto_ptr():ne w(" <<
n << ")" << std::endl; }
~auto_ptr () { std::cout << this << ":auto_ptr():de lete(" << n << ")"
<< std::endl; }
auto_ptr ( auto_ptr & );
auto_ptr & operator = ( auto_ptr & );

auto_ptr ( auto_ptr_ref /*by value*/ r ) {
this->n = r.ptr->n;
r.ptr->n = 0; // update RHS
std::cout << this << ":auto_ptr(auto _ptr_ref):" << r.ptr <<
std::endl;
}
operator auto_ptr_ref () {
std::cout << this << ":operator auto_ptr_ref(): " << std::endl;
return auto_ptr_ref(th is);
}

};

auto_ptr foo () { auto_ptr ptr; return ptr; }

int main(){
auto_ptr ptr = foo ();
}

[Neelesh Bodas]

Hi Aleksey,
thanks for the reply.

Aleksey Loginov wrote:

auto_ptr ( auto_ptr_ref /*by value*/ r ) {
this->n = r.ptr->n;
r.ptr->n = 0; // update RHS
std::cout << this << ":auto_ptr(auto _ptr_ref):" << r.ptr <<
std::endl;
}
operator auto_ptr_ref () {
std::cout << this << ":operator auto_ptr_ref(): " << std::endl;
return auto_ptr_ref(th is);
}

};

auto_ptr foo () { auto_ptr ptr; return ptr; }

int main(){
auto_ptr ptr = foo ();
}

The basic reason why I am not able to understand why this works is that
I observe _two_ user defined conversions applied here -
1) conversion from auto_ptr to auto_ptr_ref using operator auto_ptr_ref
() : applied on return value of foo
2) conversion from auto_ptr_ref to auto_ptr using the constructor
auto_ptr ( auto_ptr_ref) applied on the result of 1.

The reason why I am considering (2) as a conversion is that the
initialization of ptr is done as a copy initialization - not a direct
initialization.

Or may be it is the case that (2) above is _not_ considered as a
conversion by the compiler somehow. Not sure.

Hence the confusion.

[mlimber]

Neelesh Bodas wrote:

Hello All,
My question is regarding the implementation of auto pointers - How
does the class auto_ptr_ref work?

[snip]

See these links by N. Josuttis and S. Meyers, respectively:

http://www.josuttis.com/libbook/auto_ptr.html

http://www.awprofessional.com/conten...tr_update.html

Cheers! --M