On 30 Jan 99 04:17:29 GMT, Lisa Lippincott

>This is correct.  I don't have any idea how I became so confused about
>the Metrowerks code.  So I'll rephrase my question, without reference to
>Metrowerks:
>
>1) Should this code compile:
>        auto_ptr<int> f();
>        auto_ptr<int> p;
>        void Foo()   { p = f(); }
>   1a) in the best of all possible C++ languages?
>   1b) according to the current standard?

1a) Yes, an a function auto_ptr<T>::operator=(auto_ptr_ref<U>) would
    have been good for parallel structure.  The absence of such a
    function has one advantage, though: it forces us to declare and
    initialize the auto_ptr at the same time,
       auto_ptr<int> p=f();
    The practice of initializing a variable when we declare it is
    preferrable in C++.
       [X] First, it makes the types of variable easier to track when
           reading a large function, and this help with maintainance.
       [X] Second, it allows us to declare the object as const.
       [X] Third, it avoids the overhead of default initializing a
           variable and then really initializing it.  This makes the
           runtime program (slightly) shorter and (slightly) faster.

1b) No, the standard defines only auto_ptr<T>::auto_ptr(auto_ptr_ref<T>).
    A templated constructor auto_ptr<T>::auto_ptr(auto_ptr_ref<U>) would
    be good, though.


>2) Assuming the answer to (1a) is yes, and (1b) is no, can the
>   problem be corrected by:
>   2a) changing the declaration to
>            auto_ptr& operator=(auto_ptr a) throw();
>   2b) adding the declaration
>            auto_ptr& operator=(auto_ptr_ref r) throw();
>   (templating omitted for clarity.)

2a) yes
2b) yes


>3) Would either of the changes suggested in (2) cause problems?

In view of the fact that the one-arg constructor of auto_ptr is
explicit, I can't think of any problems.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn7bp6vo.k2v.sbnaran@localhost.localdomain>, Siemel Naran
<sbnaran@localhost.localdomain> writes
>>3) Would either of the changes suggested in (2) cause problems?
>
>In view of the fact that the one-arg constructor of auto_ptr is
>explicit, I can't think of any problems.

However the history of auto_ptr is fraught with well intentioned changes
that had 'surprising' results.  Getting consensus on the final form was
a major achievement for which Bill Gibbons et al. should be
congratulated.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ Sorry about reopening a dead thread, but I've been out with the flu. ]

I wrote, regarding the Metrowerks C++ auto_ptr<T>::operator=:

> auto_ptr<int> f();
> auto_ptr<int> p;
> void Foo()   { p = f(); }
[...]
> Theirs, contrary to the standard,  takes its parameter by value,
> rather than reference.  This seems appropriate, since operator=
> is a sink, and it makes the code above work the way I would expect.


Howard Hinnant <hinnant@_anti-spam_lightlink.com> wrote:

> Just to clear this up a little, Metrowerk's auto_ptr has two operator=
> methods:
>
>   auto_ptr& operator=(auto_ptr& a) throw();
>   auto_ptr& operator=(auto_ptr_ref r) throw();
>
> The first one is standard.  I added the second one with a comment about
> its being non-standard just for the reason Lisa describes.

This is correct.  I don't have any idea how I became so confused about
the Metrowerks code.  So I'll rephrase my question, without reference to
Metrowerks:

1) Should this code compile:
        auto_ptr<int> f();
        auto_ptr<int> p;
        void Foo()   { p = f(); }
   1a) in the best of all possible C++ languages?
   1b) according to the current standard?

2) Assuming the answer to (1a) is yes, and (1b) is no, can the
   problem be corrected by:
   2a) changing the declaration to
            auto_ptr& operator=(auto_ptr a) throw();
   2b) adding the declaration
            auto_ptr& operator=(auto_ptr_ref r) throw();
   (templating omitted for clarity.)

3) Would either of the changes suggested in (2) cause problems?

                                                    --Lisa Lippincott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <lisa_lippincott-1301991900180001@38.168.253.3>,
lisa_lippincott@advisories.com (Lisa Lippincott) wrote:

> Recently, I wrote a class with auto_ptr-style copy semantics.  Because
> auto_ptr is rather tricky, I carefully copied the interface from the
> C++ standard.  Later, I was surprised to find that this assignment
> wouldn't compile:
>
> MyClass f();
> MyClass p;
> void Foo()   { p = f(); }
>
> I thought that making this sort of thing work was what auto_ptr_ref
> was all about.  But on closer examination, it doesn't cover this case.
> MyClass::operator= takes a non-const reference as a parameter, and that
> won't bind to the return value of f().
>
> So now the question arose: why haven't I had this problem with auto_ptr?
> It turns out that Metrowerks C++ compiles this just fine:
>
> auto_ptr<int> f();
> auto_ptr<int> p;
> void Foo()   { p = f(); }
>
> The difference lies in the assignment operator for auto_ptr.  Theirs,
> contrary to the standard,  takes its parameter by value, rather than
> reference.  This seems appropriate, since operator= is a sink, and
> it makes the code above work the way I would expect.  I can't
> think of any problems this change causes.

Just to clear this up a little, Metrowerk's auto_ptr has two operator= methods:

  auto_ptr& operator=(auto_ptr& a) throw();
  auto_ptr& operator=(auto_ptr_ref r) throw();

The first one is standard.  I added the second one with a comment about
its being non-standard just for the reason Lisa describes.

There is no debate that auto_ptr should function as described above.
There is some debate as to whether or not the non-standard method I added
is necessary to achieve this functionality.

Note that auto_ptr_ref is not templated.  This reflects a current
limitation in our compiler, and is not meant to imply that we don't think
it should be.  So the second method really ought to look like:

  auto_ptr& operator=(auto_ptr_ref<X> r) throw();

Howard Hinnant
Senior Library and Performance Engineer
Metrowerks
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 14 Jan 99 09:47:11 GMT, Lisa Lippincott

>Recently, I wrote a class with auto_ptr-style copy semantics.  Because
>auto_ptr is rather tricky, I carefully copied the interface from the
>C++ standard.  Later, I was surprised to find that this assignment
>wouldn't compile:
>
>MyClass f();
>MyClass p;
>void Foo()   { p = f(); }
>
>I thought that making this sort of thing work was what auto_ptr_ref
>was all about.  But on closer examination, it doesn't cover this case.
>MyClass::operator= takes a non-const reference as a parameter, and that
>won't bind to the return value of f().
>
>So now the question arose: why haven't I had this problem with auto_ptr?
>It turns out that Metrowerks C++ compiles this just fine:

>auto_ptr<int> f();
>auto_ptr<int> p;
>void Foo()   { p = f(); }
>
>The difference lies in the assignment operator for auto_ptr.  Theirs,
>contrary to the standard,  takes its parameter by value, rather than
>reference.  This seems appropriate, since operator= is a sink, and
>it makes the code above work the way I would expect.  I can't
>think of any problems this change causes.

I don't think class std::auto_ptr is supposed to have an assignment
operator.  But I ran out of RAM on my computer so I can't look at
the standard now.

The assignment "p=f()" looks for
   auto_ptr<int>::operator=(const auto_ptr<int>&);
Failing to find this operator, it looks for conversions of the RHS.
There is the following constructor:
   auto_ptr::auto_ptr(auto_ptr_ref);
So the compiler converts the return of f() into an auto_ptr.  Then
it calls the above operator= function to assign one auto_ptr to
the other.


>Do other people agree that it's an improvement to have auto_ptr's
>assignment operator take a value as it's parameter?

Yes.  But it is not necessary in view of the conversion sequence
above.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
....
> I don't think class std::auto_ptr is supposed to have an assignment
> operator.  But I ran out of RAM on my computer so I can't look at
> the standard now.

It is definitely supposed to have (20.4.5.1):

 auto_ptr& operator=(auto_ptr&) throw();


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Recently, I wrote a class with auto_ptr-style copy semantics.  Because
auto_ptr is rather tricky, I carefully copied the interface from the
C++ standard.  Later, I was surprised to find that this assignment
wouldn't compile:

MyClass f();
MyClass p;
void Foo()   { p = f(); }

I thought that making this sort of thing work was what auto_ptr_ref
was all about.  But on closer examination, it doesn't cover this case.
MyClass::operator= takes a non-const reference as a parameter, and that
won't bind to the return value of f().

So now the question arose: why haven't I had this problem with auto_ptr?
It turns out that Metrowerks C++ compiles this just fine:

auto_ptr<int> f();
auto_ptr<int> p;
void Foo()   { p = f(); }

The difference lies in the assignment operator for auto_ptr.  Theirs,
contrary to the standard,  takes its parameter by value, rather than
reference.  This seems appropriate, since operator= is a sink, and
it makes the code above work the way I would expect.  I can't
think of any problems this change causes.

Do other people agree that it's an improvement to have auto_ptr's
assignment operator take a value as it's parameter?

                                                --Lisa Lippincott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]