"Ian Darling" <ian@pure-virtual.co.uk> wrote in message
news:8mnc8h$l1$1@newsg2.svr.pol.co.uk...
>
> "Sean Kelly" <kensai@bellatlantic.net> wrote in message
> >
> > VC++ 6.0 indeed forbids the use of STL containers of auto_ptrs.
>
> Err, it doesn't (VC++6 SP3)
>
> A bit of (admittedly rushed) code ripped out of a simple compiler I wrote
> for my degree:
>
> // msl is a namespace for program objects relating to the "mini systems
> // language" this compiles
> // also had 'using std::list' etc done
> void getprocedure( list<auto_ptr<msl::procedure_dec> > &procs )
> {

You're right.  I had forgotten that I'm using the Dinkum C++ library for
VC++, which indeed forbids containers of auto_ptrs, as should be the case.
I wrote a test program without the Dinkum library and, as you say, VC++
compiled and ran it without any complaints or errors.  For reference, this
is the error I get when compiling with the Dinkum library:

"error C2558: class 'std::auto_ptr<class AuIvQ no copy constructor
available"

Sorry for the confusion.

Sean

---
[ 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 <581k5.42$nT.6643@typhoon1.ba-dsg.net>,
  "Sean Kelly" <kensai@bellatlantic.net> wrote:
> "Ian Darling" <ian@pure-virtual.co.uk> wrote in message
> news:8mnc8h$l1$1@newsg2.svr.pol.co.uk...
> >
> > "Sean Kelly" <kensai@bellatlantic.net> wrote in message
> > >
> > > VC++ 6.0 indeed forbids the use of STL containers of auto_ptrs.
> >
> > Err, it doesn't (VC++6 SP3)
> >
> > A bit of (admittedly rushed) code ripped out of a simple compiler I
wrote
> > for my degree:
> >
> > // msl is a namespace for program objects relating to the "mini
systems
> > // language" this compiles
> > // also had 'using std::list' etc done
> > void getprocedure( list<auto_ptr<msl::procedure_dec> > &procs )
> > {
>
> You're right.  I had forgotten that I'm using the Dinkum C++ library
for
> VC++, which indeed forbids containers of auto_ptrs, as should be the
case.
> I wrote a test program without the Dinkum library and, as you say,
VC++
> compiled and ran it without any complaints or errors.  For reference,
this
> is the error I get when compiling with the Dinkum library:
>
> "error C2558: class 'std::auto_ptr<class AuIvQ no copy constructor
> available"
>
> Sorry for the confusion.

Just to clear up even more confusion ;).

The VC++ compiler comes with the Dinkumware library.  What you have is
the latest version of the Dinkumware library which is much more
compliant with the standard.  The later versions are not included with
VC++ 6 (it actually has the exact same version as was shipped with VC++
5 from day one) because of release policies/dates and legal
entanglements that were out of the control of either Dinkumware or MS.

--
William E. Kempf
Software Engineer, MS Windows Programmer


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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              ]

"Sean Kelly" <kensai@bellatlantic.net> wrote in message
news:guKi5.516$031.17271@typhoon2.ba-dsg.net...
>
> "Edward Diener" <eddielee@abraxis.com> wrote in message
> news:3989BCE8.F2BF9CB4@abraxis.com...
> > You can not use standard containers of auto_ptrs in standard C++, but
then
> > again MSVC5 does not implement standard C++ in this area. I believe
MSVC6
> will
> > forbid its use and certainly Borland's BCB5, which is more standard C++
> > compliant than MSVC, will forbid its use.
>
> VC++ 6.0 indeed forbids the use of STL containers of auto_ptrs.

Err, it doesn't (VC++6 SP3)

A bit of (admittedly rushed) code ripped out of a simple compiler I wrote
for my degree:

// msl is a namespace for program objects relating to the "mini systems
// language" this compiles
// also had 'using std::list' etc done
void getprocedure( list<auto_ptr<msl::procedure_dec> > &procs )
{

---
[ 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              ]

The problem with testing code on a specific complier as opposed to respec=
ting
the standard and understanding the reasons for such restrictions is easil=
y
demonstrated with your example. The latest version of MSVC std::auto_ptr =
is not
standard compliant in the way it treats ownership of the pointer (and man=
y
other ways ;). This is because the C++ standard auto_ptr spec has changed=
 since
the implementation was released. Even if you tested and made sure your
container of auto_ptr works for all possible cases you could imagine,
everything could just break down in the next release (when VC fixes
std::auto_ptr or when it enhances or modifies std::vector for example). S=
o the
answer to your question most probably "no" unless you plan on working wit=
h
MSVC5 standard library for the rest of you life. For fun, you can try thi=
s with
your std::auto_ptr:

struct A {
 int m_int;
};

// ...
 std::auto_ptr<A> pInt1(new A); // ok
 std::auto_ptr<A> pInt2 =3D pInt1; // ok
 pInt1->m_int =3D 0; // does this line fail?


It fails on all standard conforming implementations of std::auto_ptr. It
succeeds (fails to fail) with MSVC6.0.

Claude

Hicham BOUHMADI wrote:

> Hi
> I instanciated a std vector with an auto_ptr<int> on MSVC5. I tried to
> manipulate it several ways, and it seams to works fine. At no time I
> accessed an invalid auto_ptr...
> My question is: Is this always the case?
> I mean, on other implementation of the standard library, can I be sure =
that
> it will works fine and for all possible "valid" manipulation of the vec=
tor.
> It seams to me that the answer is Yes.
>
> Can any one give me a counter-exemple...
> any idea is welcomed.
> Thanks.
> Hicham BOUHMADI                hicham@citeweb.net
>
> ---
> [ 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             =
 ]



--

Claude Qu=E9zel (claude_quezel@syntell.corba)
anti-spam: replace corba by com in private replies


---
[ 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              ]

You can not use standard containers of auto_ptrs in standard C++, but then
again MSVC5 does not implement standard C++ in this area. I believe MSVC6 will
forbid its use and certainly Borland's BCB5, which is more standard C++
compliant than MSVC, will forbid its use.

Hicham BOUHMADI wrote:

> Hi
> I instanciated a std vector with an auto_ptr<int> on MSVC5. I tried to
> manipulate it several ways, and it seams to works fine. At no time I
> accessed an invalid auto_ptr...
> My question is: Is this always the case?
> I mean, on other implementation of the standard library, can I be sure that
> it will works fine and for all possible "valid" manipulation of the vector.
> It seams to me that the answer is Yes.

---
[ 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              ]

I agree with all what you say.
Your example actually should fail. I did not test it but if you say that it
does not fail with MSVC6 so it is a non compliance with the standard, which
is in my opinion a shame.
BUT
I don't think the vector implementation make such computation. My question
was related more to the vector implementation rather than auto_ptr by
itself. for instance, let's imagine a member function of vector implemented
like this
T foo(T _t)
{
    T t1(_t);
    return _t;
}
if T== auto_ptr<X>. and I (a client of the vector) manipulate the returned
value of foo, I am almost sure that it is not safe!!!
The question is: "Is such code can be met in the vector implementation?". I
can answer this question for MSVC5 or MSVC6 by looking to the implementation
of ::std::vector. But a more important question raisses: "does the standard
discuss about such implementation limitation?"

Hicham BOUHMADI                hicham@citeweb.net


Claude Qu   zel <Claude_Quezel@Syntell.corba> a    crit dans le message :
3989DD67.47AB3FE4@Syntell.corba...

The problem with testing code on a specific complier as opposed to
respecting
the standard and understanding the reasons for such restrictions is easily
demonstrated with your example. The latest version of MSVC std::auto_ptr is
not
standard compliant in the way it treats ownership of the pointer (and many
other ways ;). This is because the C++ standard auto_ptr spec has changed
since
the implementation was released. Even if you tested and made sure your
container of auto_ptr works for all possible cases you could imagine,
everything could just break down in the next release (when VC fixes
std::auto_ptr or when it enhances or modifies std::vector for example). So
the
answer to your question most probably "no" unless you plan on working with
MSVC5 standard library for the rest of you life. For fun, you can try this
with
your std::auto_ptr:

struct A {
 int m_int;
};

// ...
 std::auto_ptr<A> pInt1(new A); // ok
 std::auto_ptr<A> pInt2 = pInt1; // ok
 pInt1->m_int = 0; // does this line fail?


It fails on all standard conforming implementations of std::auto_ptr. It
succeeds (fails to fail) with MSVC6.0.

Claude

Hicham BOUHMADI wrote:

> Hi
> I instanciated a std vector with an auto_ptr<int> on MSVC5. I tried to
> manipulate it several ways, and it seams to works fine. At no time I
> accessed an invalid auto_ptr...
> My question is: Is this always the case?
> I mean, on other implementation of the standard library, can I be sure
that
> it will works fine and for all possible "valid" manipulation of the
vector.
> It seams to me that the answer is Yes.
>
> Can any one give me a counter-exemple...
> any idea is welcomed.
> Thanks.
> Hicham BOUHMADI                hicham@citeweb.net
>
> ---
> [ 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              ]



--

Claude Qu   zel (claude_quezel@syntell.corba)
anti-spam: replace corba by com in private replies


---
[ 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              ]



---
[ 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              ]

> You can not use standard containers of auto_ptrs in standard C++
Is it said clearly, and where? or is it just a personal feeling?

>, but then
> again MSVC5 does not implement standard C++ in this area. I believe MSVC6
will
> forbid its use and certainly Borland's BCB5, which is more standard C++
> compliant than MSVC, will forbid its use.
>
May be, and may be not!! :-)



---
[ 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              ]

Hicham BOUHMADI wrote:
>
> I agree with all what you say.
> Your example actually should fail. I did not test it but if you say that it
> does not fail with MSVC6 so it is a non compliance with the standard, which
> is in my opinion a shame.
> BUT
> I don't think the vector implementation make such computation. My question
> was related more to the vector implementation rather than auto_ptr by
> itself. for instance, let's imagine a member function of vector implemented
> like this
> T foo(T _t)
> {
>     T t1(_t);
>     return _t;
> }
> if T== auto_ptr<X>. and I (a client of the vector) manipulate the returned
> value of foo, I am almost sure that it is not safe!!!
> The question is: "Is such code can be met in the vector implementation?". I

Yes, such code can exist in the the implementation of std::vector<>.

> can answer this question for MSVC5 or MSVC6 by looking to the implementation
> of ::std::vector. But a more important question raisses: "does the standard
> discuss about such implementation limitation?"

Yes. Section 23p3 says "The type of objects stored in these components
must meet the requirements of CopyConstructible types (20.1.3) ..."

Section 20.1.3 requires that "T(t) is equivalent to t".

Section 20.4.5.1 p2 says that the copy constructor for auto_ptr<T>
"calls a.release()".

Section 20.4.5.2 p2 says that a post-condition of a.release() is that
"*this holds a null pointer".

Therefore, a copy-constructed auto_ptr is not equivalent to the auto_ptr
it was constructed from, unless that auto_ptr already contained a null
pointer. auto_ptr<T> is therefore not CopyConstructible, and therefore
cannot be legally stored in a standard container. Therefore, a standard
container's implementation may legally contain code that would fail if
an attempt were made to store an auto_ptr in it. Most standard
containers do in fact copy construct the stored objects at one point or
another, relying on the assumption that the copy is equivalent to the
original, so such a failure is not merely possible, but likely.

---
[ 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              ]

Hicham BOUHMADI wrote:

> > You can not use standard containers of auto_ptrs in standard C++
> Is it said clearly, and where? or is it just a personal feeling?

No it is not a personal feeling. The semantics of copy and assignment in C++
containers does not work correctly with std::auto_ptrs, and a C++ compliant
compiler will give you errors if you try to use instantiate a container of
std::auto_ptrs.

---
[ 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              ]

I think the standard prohibits the use of auto_ptr in standard containers=
 for
exactly that reason: implementations are not bound to write code that wil=
l not
fail for std::auto_ptr or classes like it. Note that conformant standard =
library
do not allow standard containers of auto_ptr to compile.This has already =
been
discused in this forum See thread subject: "auto_ptr in standard containe=
rs" in
this newsgroup. Siemel B. Naran wrote in that thread:

<Siemel B. Naran quote starts here>
The standard containers use std::allocator<T>::construct to copy objects =
from
the outside world into the container.  Here is that function:

  std::allocator<T>::construct(T * place, const T& obj) {       new (plac=
e)
T(obj);
  }

As you can see, the default allocator requires the existence of
T::T(const T&).  An object with a copy constructor T::T(T&) doesn't work.=
  Hence
we can't use T=3D=3Dstd::auto_ptr<U> objects inside the container.

<Siemel B. Naran quote end here>

 Hope this convinces you.

Claude



Hicham BOUHMADI wrote:

<text snipped>

> BUT
>
> The question is: "Is such code can be met in the vector implementation?=
". I
> can answer this question for MSVC5 or MSVC6 by looking to the implement=
ation
> of ::std::vector. But a more important question raisses: "does the stan=
dard
> discuss about such implementation limitation?"

 <text snipped>


--

Claude Qu=E9zel (claude_quezel@syntell.corba)
anti-spam: replace corba by com in private replies


---
[ 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 <8me0io$q3e$1@reader1.imaginet.fr>, Hicham BOUHMADI
<hicham@citeweb.net> writes
>> You can not use standard containers of auto_ptrs in standard C++
>Is it said clearly, and where? or is it just a personal feeling?

Cannot is too strong a word, if you use them the consequences are
entirely your responsibility. It is clearly said because auto_ptr does
not meet the pre-requisites for copy assignment and copy construction
(it uses a non-const reference parameter in each)

>
>>, but then
>> again MSVC5 does not implement standard C++ in this area. I believe MSVC6
>will
>> forbid its use and certainly Borland's BCB5, which is more standard C++
>> compliant than MSVC, will forbid its use.
>>
>May be, and may be not!! :-)

I am doubtful that they can forbid its use, though it would be helpful
if they would warn about it (and any other class that the compiler can
spot as having the wrong copy semantics)


Francis Glassborow      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              ]

In article <8me0io$q3e$1@reader1.imaginet.fr>,
Hicham BOUHMADI <hicham@citeweb.net> wrote:
>> You can not use standard containers of auto_ptrs in standard C++
>Is it said clearly, and where? or is it just a personal feeling?


It is in the standard, 20.4.5p3:
The auto_ptr provides a semantics of strict ownership. An auto_ptr
owns the object it holds a pointer to. Copying an auto_ptr copies the
pointer and transfers ownership to the destination. If more than one
auto_ptr owns the same object at the same time the behavior of the
program is undefined.
[Note: The uses of auto_ptr include providing temporary
exception-safety for dynamically allocated memory, passing ownership
of dynamically allocated memory to a function, and returning
dynamically allocated memory from a function. auto_ptr does not meet
the CopyConstructible and Assignable requirements for Standard Library
container elements and thus instantiating a Standard Library container
with an auto_ptr results in undefined behavior.  -end note]
--
                              |  "If hard data were the filtering criterion
Mark Ping                     |   you could fit the entire contents of the
emarkp@soda.CSUA.Berkeley.EDU |   Internet on a floppy disk."
                              | - Cecil Adams, The Straight Dope Tells All

---
[ 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              ]

"Edward Diener" <eddielee@abraxis.com> wrote in message
news:3989BCE8.F2BF9CB4@abraxis.com...
> You can not use standard containers of auto_ptrs in standard C++, but then
> again MSVC5 does not implement standard C++ in this area. I believe MSVC6
will
> forbid its use and certainly Borland's BCB5, which is more standard C++
> compliant than MSVC, will forbid its use.

VC++ 6.0 indeed forbids the use of STL containers of auto_ptrs.

Sean

---
[ 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              ]

Hi
I instanciated a std vector with an auto_ptr<int> on MSVC5. I tried to
manipulate it several ways, and it seams to works fine. At no time I
accessed an invalid auto_ptr...
My question is: Is this always the case?
I mean, on other implementation of the standard library, can I be sure that
it will works fine and for all possible "valid" manipulation of the vector.
It seams to me that the answer is Yes.

Can any one give me a counter-exemple...
any idea is welcomed.
Thanks.
Hicham BOUHMADI                hicham@citeweb.net


---
[ 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              ]