Maarten Hilferink wrote:
> I think that the Note of D 9.1, paragraph 3 needs a rewrite. I know,
> auto_ptr is depreciated, but that doesn't imply that its definition
> can become incomplete [...]

Just in case you haven't yet read your h**mail, Howard Hinnant just
mailed you, asking if you want to make an official LWG issue out of your
proposal regarding auto_ptr.  :-)  The issue on the term "Assignable" is
already on Howard's LWG preview page:
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#972


> So, I propose to REPLACE:
>
> [ 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 ]
>
> WITH
>
> [ 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. Instances of auto_ptr shall meet the MoveConstructible and
> MoveAssignable requirements,
> but do not meet the CopyConstructible and CopyAssignable requirements.
>   end note ]
>
> OR (since the use of auto_ptr is depreciated anyway):
>
> [ Note: Instances of auto_ptr shall meet the MoveConstructible and
> MoveAssignable requirements,
> but do not meet the CopyConstructible and CopyAssignable requirements.
>   end note ]

Hope to see you at the LWG list  :-)

    Kind regards, Niels

--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Previous versions of the Draft had a table, defining the Assignable
requirement.  For example
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
Table 79, "Assignable requirements". But I guess the term "Assignable"
is outdated by now, because the current Committee Draft provides
MoveAssignable, CopyAssignable, and TriviallyCopyAssignable concepts
instead. And as far as I can see, it no longer has a definition of
Assignable. (Please correct me if I'm wrong.) Still the word
"Assignable" is used in eight places in the Draft,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf

18.7.5 Exception Propagation [propagation] says:
 exception_ptr shall be DefaultConstructible, CopyConstructible,
Assignable and EqualityComparable.

20.6.5 Class template reference_wrapper [refwrap] says:
 reference_wrapper<T> is a CopyConstructible and Assignable wrapper
around a reference to an object of type T.

20.6.12.1.4 Placeholders [func.bind.place] says:
 It is implementation defined whether placeholder types are
Assignable. Assignable placeholders' copy assignment operators shall
not throw exceptions.

20.7.13.2 Class template shared_ptr [util.smartptr.shared] says:
 Specializations of shared_ptr shall be CopyConstructible, Assignable,
and LessThanComparable...

20.7.13.3 Class template weak_ptr [util.smartptr.weak] says:
 Specializations of weak_ptr shall be CopyConstructible, Assignable,
and LessThanComparable...

21.1.2 traits typedefs [char.traits.typedefs] says:
 Requires: state_type shall meet the requirements of Assignable
(23.1), CopyConstructible (20.1.8), and DefaultConstructible types.

26.4.7.1 Class seed_seq [rand.util.seedseq] says:
 In addition to the requirements set forth below, instances of
seed_seq shall meet the requirements of CopyConstructible (20.1.8) and
of Assignable (23.1).

D.9.1 Class template auto_ptr [auto.ptr] says:
 auto_ptr does not meet the CopyConstructible and Assignable
requirements for standard library container elements...


Are all of those instances of "Assignable" to be replaced by "CopyAssignable"?

Wishing you all a happy 0X...

 Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 6 jan, 08:08, "Niels Dekker - no return address"
<unkn...@this.is.invalid> wrote:
> D.9.1 Class template auto_ptr [auto.ptr] says:
>  auto_ptr does not meet the CopyConstructible and Assignable
> requirements for standard library container elements...

I think that the Note of D 9.1, paragraph 3 needs a rewrite. I know,
auto_ptr is depreciated, but that doesn't imply that its definition
can become
incomplete nor that the notes can be wrong and I doubt that the
standard should
still emphasize that auto_ptr instances aren't valid standard
container elements.

So, I propose to REPLACE:

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

WITH

[ 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. Instances of auto_ptr shall meet the MoveConstructible and
MoveAssignable requirements,
but do not meet the CopyConstructible and CopyAssignable requirements.
  end note ]

OR (since the use of auto_ptr is depreciated anyway):

[ Note: Instances of auto_ptr shall meet the MoveConstructible and
MoveAssignable requirements,
but do not meet the CopyConstructible and CopyAssignable requirements.
  end note ]


Happy 0X..


Maarten Hilferink



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]