In article <8c8b368d.0304250457.45bbf29c@posting.google.com>, Randy
Maddox <rmaddox@isicns.com> wrote:

| Could you please explain how it would be possible to swap something
| that cannot be copy constructed nor assigned?  At the least it seems
| to me that you need one or the other, and for the easiest
| implementation both.  I can see how you might work around this using
| placement new, but that seems a hideous and error prone hack.  Perhaps
| you can provide an alternative swap algorithm?

See "Swappable Concept" in:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1289.html

--
Howard Hinnant
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://www.jamesd.demon.co.uk/csc/faq.html                       ]

rmaddox@isicns.com (Randy Maddox) wrote
> Could you please explain how it would be possible to swap something
> that cannot be copy constructed nor assigned?

You overload std::swap for that type, and/or provide a member function
named swap.

    class Foo {
        Foo(const&Foo);            // Not implemented
        Foo&operator=(const Foo&); // Not implemented
        int len;
        char*data;
    public:
        Foo(const char*text) : len(strlen(text))
           { strcpy(data=new char[len+1], text); }
        void swap(Foo&rhs) {
            std::swap(data, rhs.data);
            std::swap(len,  rhs.len);
        }
        // ... other members ...
    };
    void std::swap(Foo&lhs, Foo&rhs) { lhs.swap(rhs); }

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

   Proposal N1439 (Proposed Resolution to LWG issues 225, 226, 229) in the
pre-Oxford mailing defines a new requirement called "swappable", which is a
superset of copy-constructible and assignable. It then proposes that several
algorithms have their requirements restated in terms of  swappable instead
of copy-constructible and assignable, as was originally the case.

   For the most part this is a good idea.  However, stable_sort (and
stable_partition), currently allow an implementation to allocate extra
memory to speed up the algorithm.  If the algorithms have to assume that the
class is swappable they will no longer be able to do this, because it is
possible for a class to be swappable but not be copy-constructible and
assignable.

    Therefore, I think the proposal should be modified so that stable_sort
and stable_partition retain their old requirements.

Joe Gottman

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jgottman@carolina.rr.com ("Joe Gottman") wrote
> Proposal N1439 (Proposed Resolution to LWG issues 225, 226, 229) in the
> pre-Oxford mailing defines a new requirement called "swappable", which is a
> superset of copy-constructible and assignable.

I haven't read this proposal.

When you use the word "superset," do you mean this in the classical
sense? If A is a superset of B, then A can do anything that B can do,
and perhaps more.

> It then proposes that several
> algorithms have their requirements restated in terms of  swappable instead
> of copy-constructible and assignable, as was originally the case.
>
>    For the most part this is a good idea.  However, stable_sort (and
> stable_partition), currently allow an implementation to allocate extra
> memory to speed up the algorithm.  If the algorithms have to assume that the
> class is swappable they will no longer be able to do this, because it is
> possible for a class to be swappable but not be copy-constructible and
> assignable.

If swappable is indeed a "Superset" of copy-constructable and assignable,
then your last statement is not correct.

I can see that it would be possible to create a class that can be
swapped but not copied or assigned. However, we can differentiate
between a class which has some "swap" method, and a class which meets
all the requirements of "Swappable." If we specify that the requirement
"Swappable" also includes "Copy-constructible" and "Assignable," we
won't have this problem.

Alternatively, we can specify that stable_sort requires the class
to be not only Swappable, but also Copy-constructible and Assignable.
Or, we can specialize stable_sort for classes which are
Copy-constructible and Assignable, and for classes which are "merely"
Swappable.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jgottman@carolina.rr.com ("Joe Gottman") wrote in message news:<Jn0qa.37085$ij4.2529263@twister.southeast.rr.com>...
> Proposal N1439 (Proposed Resolution to LWG issues 225, 226, 229) in the
> pre-Oxford mailing defines a new requirement called "swappable", which is a
> superset of copy-constructible and assignable. It then proposes that several
> algorithms have their requirements restated in terms of  swappable instead
> of copy-constructible and assignable, as was originally the case.
>
>    For the most part this is a good idea.  However, stable_sort (and
> stable_partition), currently allow an implementation to allocate extra
> memory to speed up the algorithm.  If the algorithms have to assume that the
> class is swappable they will no longer be able to do this, because it is
> possible for a class to be swappable but not be copy-constructible and
> assignable.

Could you please explain how it would be possible to swap something
that cannot be copy constructed nor assigned?  At the least it seems
to me that you need one or the other, and for the easiest
implementation both.  I can see how you might work around this using
placement new, but that seems a hideous and error prone hack.  Perhaps
you can provide an alternative swap algorithm?

Thanks.

Randy.

>
>     Therefore, I think the proposal should be modified so that stable_sort
> and stable_partition retain their old requirements.
>
> Joe Gottman
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <Jn0qa.37085$ij4.2529263@twister.southeast.rr.com>, Joe
Gottman <jgottman@carolina.rr.com> wrote:

|    Proposal N1439 (Proposed Resolution to LWG issues 225, 226, 229) in the
| pre-Oxford mailing defines a new requirement called "swappable", which is a
| superset of copy-constructible and assignable. It then proposes that several
| algorithms have their requirements restated in terms of  swappable instead
| of copy-constructible and assignable, as was originally the case.
|
|    For the most part this is a good idea.  However, stable_sort (and
| stable_partition), currently allow an implementation to allocate extra
| memory to speed up the algorithm.  If the algorithms have to assume that the
| class is swappable they will no longer be able to do this, because it is
| possible for a class to be swappable but not be copy-constructible and
| assignable.
|
|     Therefore, I think the proposal should be modified so that stable_sort
| and stable_partition retain their old requirements.

The intent was to add requirements, not replace them.

Currently stable_sort and stable_partition do not have requirements,
except by implication.  The use of forward or better iterator implies
that the value_type is assignable.  As you note, the description of
these methods includes the possibility of using a temporary buffer.
This implies that the value_type is also copy constructible.

We certainly do not want to remove these implied requirements.

It is interesting to note the history of this paper:

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1439.htm
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1387.htm
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1289.html

The swappable requirement keeps getting added and taken away. :-)

One of these years I'm going to get it right.  I have comments from
Oxford and a directive to try yet once again (though there is agreement
on the general solution).  I will add your comments to my effort,
thanks.

--
Howard Hinnant
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://www.jamesd.demon.co.uk/csc/faq.html                       ]