Topic: New member functions for standard container adapters


Author: "Diego R." <dieram3@gmail.com>
Date: Sat, 25 May 2013 23:42:44 -0700 (PDT)
Raw View
------=_Part_3_26331560.1369550564966
Content-Type: text/plain; charset=ISO-8859-1

Priority queues cannot be used with types non-copyable. Because top()
returns a constant reference. For example I can't create something like
priority_queue<std::unique_ptr<MyPolymorphicClass>>.

I propose that priority_queue have more support for move semantics by using
of new member functions. Additionaly I would add these new members
functions to stack and queue for simmetry.

Below I show an idea.

template <class T, class Container, class Comparer>
 class priority_queue
 {
  ...
   value_type move_top()
   {
      value_type v;
      pop(v);
      return v;
   }

   void pop(value_type& v)
   {
     std::pop_heap(c.begin(), c.end(), comp);
     v = std::move(c.back());
     c.pop_back();
   }

 };

template <class T, class Container>
 class stack
 {
  ...
   value_type move_top()
   {
      value_type v;
      pop(v);
      return v;
   }

   void pop(value_type& v)
   {
     v = std::move(c.back());
     c.pop_back();
   }

 };

template <class T, class Container>
 class queue
 {
  ...
   value_type move_front()
   {
      value_type v;
      pop(v);
      return v;
   }

   void pop(value_type& v)
   {
     v = std::move(c.front());
     c.pop_front();
   }

 };

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3_26331560.1369550564966
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Priority queues cannot be used with types non-copyable. Because top() retur=
ns a constant reference. For example I can't create something like priority=
_queue&lt;std::unique_ptr&lt;MyPolymorphicClass&gt;&gt;.<div><br></div><div=
>I propose that priority_queue have more support for move semantics by usin=
g of new member functions. Additionaly I would add these new members functi=
ons to stack and queue for simmetry.</div><div><br></div><div>Below I show =
an idea.<br></div><div><br></div><div>template &lt;class T, class Container=
, class Comparer&gt;</div><div>&nbsp;class priority_queue</div><div>&nbsp;{=
</div><div>&nbsp; ...</div><div>&nbsp; &nbsp;value_type move_top()</div><di=
v>&nbsp; &nbsp;{</div><div>&nbsp; &nbsp; &nbsp; value_type v;</div><div>&nb=
sp; &nbsp; &nbsp; pop(v);</div><div>&nbsp; &nbsp; &nbsp; return v; &nbsp;</=
div><div>&nbsp; &nbsp;}</div><div><br></div><div>&nbsp; &nbsp;void pop(valu=
e_type&amp; v)</div><div>&nbsp; &nbsp;{</div><div>&nbsp; &nbsp; &nbsp;std::=
pop_heap(c.begin(), c.end(), comp);&nbsp;</div><div>&nbsp; &nbsp; &nbsp;v =
=3D std::move(c.back());</div><div>&nbsp; &nbsp; &nbsp;c.pop_back();</div><=
div>&nbsp; &nbsp;}</div><div>&nbsp;</div><div>&nbsp;};</div><div><br></div>=
<div><div>template &lt;class T, class Container&gt;</div><div>&nbsp;class s=
tack</div><div>&nbsp;{</div><div>&nbsp; ...</div><div>&nbsp; &nbsp;value_ty=
pe move_top()</div><div>&nbsp; &nbsp;{</div><div>&nbsp; &nbsp; &nbsp; value=
_type v;</div><div>&nbsp; &nbsp; &nbsp; pop(v);</div><div>&nbsp; &nbsp; &nb=
sp; return v; &nbsp;</div><div>&nbsp; &nbsp;}</div><div><br></div><div>&nbs=
p; &nbsp;void pop(value_type&amp; v)</div><div>&nbsp; &nbsp;{&nbsp;</div><d=
iv>&nbsp; &nbsp; &nbsp;v =3D std::move(c.back());</div><div>&nbsp; &nbsp; &=
nbsp;c.pop_back();</div><div>&nbsp; &nbsp;}</div><div>&nbsp;</div><div>&nbs=
p;};</div></div><div><br></div><div><div>template &lt;class T, class Contai=
ner&gt;</div><div>&nbsp;class queue</div><div>&nbsp;{</div><div>&nbsp; ...<=
/div><div>&nbsp; &nbsp;value_type move_front()</div><div>&nbsp; &nbsp;{</di=
v><div>&nbsp; &nbsp; &nbsp; value_type v;</div><div>&nbsp; &nbsp; &nbsp; po=
p(v);</div><div>&nbsp; &nbsp; &nbsp; return v; &nbsp;</div><div>&nbsp; &nbs=
p;}</div><div><br></div><div>&nbsp; &nbsp;void pop(value_type&amp; v)</div>=
<div>&nbsp; &nbsp;{&nbsp;</div><div>&nbsp; &nbsp; &nbsp;v =3D std::move(c.f=
ront());</div><div>&nbsp; &nbsp; &nbsp;c.pop_front();</div><div>&nbsp; &nbs=
p;}</div><div>&nbsp;</div><div>&nbsp;};</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3_26331560.1369550564966--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 May 2013 03:21:12 -0700 (PDT)
Raw View
------=_Part_1769_23370631.1369563672704
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, May 25, 2013 11:42:44 PM UTC-7, Diego R. wrote:
>
> Priority queues cannot be used with types non-copyable. Because top()
> returns a constant reference. For example I can't create something like
> priority_queue<std::unique_ptr<MyPolymorphicClass>>.
>
> I propose that priority_queue have more support for move semantics by
> using of new member functions. Additionaly I would add these new members
> functions to stack and queue for simmetry.
>
> Below I show an idea.
>
> template <class T, class Container, class Comparer>
>  class priority_queue
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      std::pop_heap(c.begin(), c.end(), comp);
>      v = std::move(c.back());
>      c.pop_back();
>    }
>
>  };
>
> template <class T, class Container>
>  class stack
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v = std::move(c.back());
>      c.pop_back();
>    }
>
>  };
>
> template <class T, class Container>
>  class queue
>  {
>   ...
>    value_type move_front()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v = std::move(c.front());
>      c.pop_front();
>    }
>
>  };
>

I can't say I care much for the "pop-into-value" functions, but you should
write it up into a proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1769_23370631.1369563672704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, May 25, 2013 11:42:44 PM UTC-7, Diego R. wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">Priority queues cannot be used with types non=
-copyable. Because top() returns a constant reference. For example I can't =
create something like priority_queue&lt;std::unique_<wbr>ptr&lt;MyPolymorph=
icClass&gt;&gt;.<div><br></div><div>I propose that priority_queue have more=
 support for move semantics by using of new member functions. Additionaly I=
 would add these new members functions to stack and queue for simmetry.</di=
v><div><br></div><div>Below I show an idea.<br></div><div><br></div><div>te=
mplate &lt;class T, class Container, class Comparer&gt;</div><div>&nbsp;cla=
ss priority_queue</div><div>&nbsp;{</div><div>&nbsp; ...</div><div>&nbsp; &=
nbsp;value_type move_top()</div><div>&nbsp; &nbsp;{</div><div>&nbsp; &nbsp;=
 &nbsp; value_type v;</div><div>&nbsp; &nbsp; &nbsp; pop(v);</div><div>&nbs=
p; &nbsp; &nbsp; return v; &nbsp;</div><div>&nbsp; &nbsp;}</div><div><br></=
div><div>&nbsp; &nbsp;void pop(value_type&amp; v)</div><div>&nbsp; &nbsp;{<=
/div><div>&nbsp; &nbsp; &nbsp;std::pop_heap(c.begin(), c.end(), comp);&nbsp=
;</div><div>&nbsp; &nbsp; &nbsp;v =3D std::move(c.back());</div><div>&nbsp;=
 &nbsp; &nbsp;c.pop_back();</div><div>&nbsp; &nbsp;}</div><div>&nbsp;</div>=
<div>&nbsp;};</div><div><br></div><div><div>template &lt;class T, class Con=
tainer&gt;</div><div>&nbsp;class stack</div><div>&nbsp;{</div><div>&nbsp; .=
...</div><div>&nbsp; &nbsp;value_type move_top()</div><div>&nbsp; &nbsp;{</d=
iv><div>&nbsp; &nbsp; &nbsp; value_type v;</div><div>&nbsp; &nbsp; &nbsp; p=
op(v);</div><div>&nbsp; &nbsp; &nbsp; return v; &nbsp;</div><div>&nbsp; &nb=
sp;}</div><div><br></div><div>&nbsp; &nbsp;void pop(value_type&amp; v)</div=
><div>&nbsp; &nbsp;{&nbsp;</div><div>&nbsp; &nbsp; &nbsp;v =3D std::move(c.=
back());</div><div>&nbsp; &nbsp; &nbsp;c.pop_back();</div><div>&nbsp; &nbsp=
;}</div><div>&nbsp;</div><div>&nbsp;};</div></div><div><br></div><div><div>=
template &lt;class T, class Container&gt;</div><div>&nbsp;class queue</div>=
<div>&nbsp;{</div><div>&nbsp; ...</div><div>&nbsp; &nbsp;value_type move_fr=
ont()</div><div>&nbsp; &nbsp;{</div><div>&nbsp; &nbsp; &nbsp; value_type v;=
</div><div>&nbsp; &nbsp; &nbsp; pop(v);</div><div>&nbsp; &nbsp; &nbsp; retu=
rn v; &nbsp;</div><div>&nbsp; &nbsp;}</div><div><br></div><div>&nbsp; &nbsp=
;void pop(value_type&amp; v)</div><div>&nbsp; &nbsp;{&nbsp;</div><div>&nbsp=
; &nbsp; &nbsp;v =3D std::move(c.front());</div><div>&nbsp; &nbsp; &nbsp;c.=
pop_front();</div><div>&nbsp; &nbsp;}</div><div>&nbsp;</div><div>&nbsp;};</=
div></div></blockquote><div><br>I can't say I care much for the "pop-into-v=
alue" functions, but you should write it up into a proposal. <br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1769_23370631.1369563672704--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 26 May 2013 17:46:06 +0200
Raw View
Le 26/05/13 08:42, Diego R. a =E9crit :
> Priority queues cannot be used with types non-copyable. Because top()=20
> returns a constant reference. For example I can't create something=20
> like priority_queue<std::unique_ptr<MyPolymorphicClass>>.
>
> I propose that priority_queue have more support for move semantics by=20
> using of new member functions. Additionaly I would add these new=20
> members functions to stack and queue for simmetry.
>
> Below I show an idea.
>
> template <class T, class Container, class Comparer>
>  class priority_queue
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      std::pop_heap(c.begin(), c.end(), comp);
>      v =3D std::move(c.back());
>      c.pop_back();
>    }
>  };
>
Yes, there is an issue here. I guess top() returns a const_reference to=20
ensure the class invariants.
Maybe pull() could be used to name both operations.
> template <class T, class Container>
>  class stack
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v =3D std::move(c.back());
>      c.pop_back();
>    }
>  };
>
> template <class T, class Container>
>  class queue
>  {
>   ...
>    value_type move_front()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v =3D std::move(c.front());
>      c.pop_front();
>    }
>  };
>
I don't see the problem with stack and queue. stack top() returns a=20
reference and queue has no member top() and front() and back() returns a=20
reference.

Best,
Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.


Author: Jonathan Wakely <cxx@kayari.org>
Date: Tue, 28 May 2013 06:25:24 -0700 (PDT)
Raw View
------=_Part_1382_24096763.1369747524961
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, May 26, 2013 4:46:06 PM UTC+1, Vicente J. Botet Escriba wrote:
>
> >
> Yes, there is an issue here. I guess top() returns a const_reference to
> ensure the class invariants.
>

Yes, returning a const-reference prevents the queue's ordering being
invalidated, similar to set::iterator not being a mutable iterator.



> Maybe pull() could be used to name both operations.
>

I prefer that name to move_top(), because the name "move_top" doesn't
immediately tell me it combines the pop and top operations.  However we
already have push/pop as the names for the pair of operations throughout
Clause 23 so introducing push/pull in contrast to push/pop is a bit
confusing.  My preference would be pop_value() instead of move_top(),
however ...



> I don't see the problem with stack and queue. stack top() returns a
> reference and queue has no member top() and front() and back() returns a
> reference.
>
>
I agree, the only issue I see is priority_queue::top() to allow
std::priority_queue<MoveOnly>.  The other proposed changes allow a
different coding style when using the adaptors but don't add any new
functionality or allow anything that can't be done today.  I don't agree
with the symmetry argument for adding members to std::queue and std::stack,
the different adaptors serve different purposes and do not need to be
interchangeable in generic code.

Adding the priority_queue::pop(value_type&) overload and nothing else would
be enough to solve the MoveOnly case.

I'd prefer to write:

     auto x = pq.move_top();

rather than:

    PQ::value_type x;
    pq.pop(x);

but move_top() doesn't provide the strong exception safety guarantee.  If
move_top() throws I don't know if it happened during the move-assignment in
pop(value_type&) or during the return in move_top(), so the container is in
an unspecified state and I might have lost data.  Any proposal would need
to have wording to say that, and/or have
is_nothrow_move_constructible<value_type> as a precondition for the strong
exception safety guarantee.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1382_24096763.1369747524961
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, May 26, 2013 4:46:06 PM UTC+1, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
<br>Yes, there is an issue here. I guess top() returns a const_reference to=
=20
<br>ensure the class invariants.
<br></blockquote><div><br>Yes, returning a const-reference prevents the que=
ue's ordering being invalidated, similar to=20
set::iterator not being a mutable iterator.<br><br>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">Maybe pull() could be used to name both op=
erations.
<br></blockquote><div>&nbsp;</div><div>I prefer that name to move_top(), be=
cause the name "move_top" doesn't immediately tell me it combines the pop a=
nd top operations.&nbsp; However we already have push/pop as the names for =
the pair of operations throughout Clause 23 so introducing push/pull in con=
trast to push/pop is a bit confusing.&nbsp; My preference would be pop_valu=
e() instead of move_top(), however ...<br><br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I don't see the problem with stack and queue. s=
tack top() returns a=20
<br>reference and queue has no member top() and front() and back() returns =
a=20
<br>reference.
<br>
<br></blockquote><div><br>I agree, the only issue I see is priority_queue::=
top() to allow=20
std::priority_queue&lt;MoveOnly&gt;.&nbsp; The other proposed changes allow=
 a
 different coding style when using the adaptors but don't add any new=20
functionality or allow anything that can't be done today.&nbsp; I don't agr=
ee with the symmetry argument for adding members to std::queue and std::sta=
ck, the different adaptors serve different purposes and do not need to be i=
nterchangeable in generic code.<br><br></div>Adding the priority_queue::pop=
(value_type&amp;) overload and nothing else would be enough to solve the Mo=
veOnly case.<br><br>I'd prefer to write:<br><br>&nbsp;&nbsp;&nbsp;&nbsp; au=
to x =3D pq.move_top();<br><br>rather than:<br><br>&nbsp;&nbsp;&nbsp; PQ::v=
alue_type x;<br>&nbsp;&nbsp;&nbsp; pq.pop(x);<br><br>but move_top() doesn't=
 provide the strong exception safety guarantee.&nbsp; If move_top() throws =
I don't know if it happened during the move-assignment in pop(value_type&am=
p;) or during the return in move_top(), so the container is in an unspecifi=
ed state and I might have lost data.&nbsp; Any proposal would need to have =
wording to say that, and/or have is_nothrow_move_constructible&lt;value_typ=
e&gt; as a precondition for the strong exception safety guarantee.<br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1382_24096763.1369747524961--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 28 May 2013 22:51:10 +0200
Raw View
This is a multi-part message in MIME format.
--------------040200020800080506010604
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 28/05/13 15:25, Jonathan Wakely a =E9crit :
>
>
> On Sunday, May 26, 2013 4:46:06 PM UTC+1, Vicente J. Botet Escriba wrote:
>
>     >
>     Yes, there is an issue here. I guess top() returns a
>     const_reference to
>     ensure the class invariants.
>
>
> Yes, returning a const-reference prevents the queue's ordering being=20
> invalidated, similar to set::iterator not being a mutable iterator.
>
>     Maybe pull() could be used to name both operations.
>
> I prefer that name to move_top(), because the name "move_top" doesn't=20
> immediately tell me it combines the pop and top operations.  However=20
> we already have push/pop as the names for the pair of operations=20
> throughout Clause 23 so introducing push/pull in contrast to push/pop=20
> is a bit confusing.  My preference would be pop_value() instead of=20
> move_top(), however ...
My preference is for pull, but pop_value would be acceptable.
>
>
> Adding the priority_queue::pop(value_type&) overload and nothing else=20
> would be enough to solve the MoveOnly case.
>
> I'd prefer to write:
>
>      auto x =3D pq.move_top();
>
> rather than:
>
>     PQ::value_type x;
>     pq.pop(x);
>
> but move_top() doesn't provide the strong exception safety guarantee. =20
> If move_top() throws I don't know if it happened during the=20
> move-assignment in pop(value_type&) or during the return in=20
> move_top(), so the container is in an unspecified state and I might=20
> have lost data.  Any proposal would need to have wording to say that,=20
> and/or have is_nothrow_move_constructible<value_type> as a=20
> precondition for the strong exception safety guarantee.
>
Agreed.

Best,
Vicente

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



--------------040200020800080506010604
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 28/05/13 15:25, Jonathan Wakely a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:03276bd6-a1ef-4ed2-87e8-4772faad4449@isocpp.org"
      type="cite"><br>
      <br>
      On Sunday, May 26, 2013 4:46:06 PM UTC+1, Vicente J. Botet Escriba
      wrote:
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
        <br>
        Yes, there is an issue here. I guess top() returns a
        const_reference to <br>
        ensure the class invariants.
        <br>
      </blockquote>
      <div><br>
        Yes, returning a const-reference prevents the queue's ordering
        being invalidated, similar to set::iterator not being a mutable
        iterator.<br>
        <br>
        &nbsp;</div>
      <blockquote class="gmail_quote" style="margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Maybe
        pull() could be used to name both operations.
        <br>
      </blockquote>
      <div>&nbsp;</div>
      <div>I prefer that name to move_top(), because the name "move_top"
        doesn't immediately tell me it combines the pop and top
        operations.&nbsp; However we already have push/pop as the names for
        the pair of operations throughout Clause 23 so introducing
        push/pull in contrast to push/pop is a bit confusing.&nbsp; My
        preference would be pop_value() instead of move_top(), however
        ...<br>
      </div>
    </blockquote>
    My preference is for pull, but pop_value would be acceptable.<br>
    <blockquote
      cite="mid:03276bd6-a1ef-4ed2-87e8-4772faad4449@isocpp.org"
      type="cite">
      <div><br>
        <br>
      </div>
      Adding the priority_queue::pop(value_type&amp;) overload and
      nothing else would be enough to solve the MoveOnly case.<br>
      <br>
      I'd prefer to write:<br>
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; auto x = pq.move_top();<br>
      <br>
      rather than:<br>
      <br>
      &nbsp;&nbsp;&nbsp; PQ::value_type x;<br>
      &nbsp;&nbsp;&nbsp; pq.pop(x);<br>
      <br>
      but move_top() doesn't provide the strong exception safety
      guarantee.&nbsp; If move_top() throws I don't know if it happened
      during the move-assignment in pop(value_type&amp;) or during the
      return in move_top(), so the container is in an unspecified state
      and I might have lost data.&nbsp; Any proposal would need to have
      wording to say that, and/or have
      is_nothrow_move_constructible&lt;value_type&gt; as a precondition
      for the strong exception safety guarantee.<br>
      <br>
    </blockquote>
    Agreed.<br>
    <br>
    Best,<br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------040200020800080506010604--

.


Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 28 May 2013 14:17:20 -0700 (PDT)
Raw View
------=_Part_5214_29228764.1369775840120
Content-Type: text/plain; charset=ISO-8859-1

move_top() does provide strong exception guarantee if nothrow moves.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_5214_29228764.1369775840120
Content-Type: text/html; charset=ISO-8859-1

move_top() does provide strong exception guarantee if nothrow moves.

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5214_29228764.1369775840120--

.


Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 28 May 2013 16:47:22 -0700
Raw View
On 5/25/13, Diego R. <dieram3@gmail.com> wrote:
> Priority queues cannot be used with types non-copyable. Because top()
> returns a constant reference. For example I can't create something like
> priority_queue<std::unique_ptr<MyPolymorphicClass>>.
>
> I propose that priority_queue have more support for move semantics by using
>
> of new member functions. Additionaly I would add these new members
> functions to stack and queue for simmetry.
>
> Below I show an idea.
>
> template <class T, class Container, class Comparer>
>  class priority_queue
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      std::pop_heap(c.begin(), c.end(), comp);
>      v = std::move(c.back());
>      c.pop_back();
>    }
>
>  };
>
> template <class T, class Container>
>  class stack
>  {
>   ...
>    value_type move_top()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v = std::move(c.back());
>      c.pop_back();
>    }
>
>  };
>
> template <class T, class Container>
>  class queue
>  {
>   ...
>    value_type move_front()
>    {
>       value_type v;
>       pop(v);
>       return v;
>    }
>
>    void pop(value_type& v)
>    {
>      v = std::move(c.front());
>      c.pop_front();
>    }
>
>  };

There are similar issues and approaches in N3533 C++ Concurrent Queues.
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3533.html

--
Lawrence Crowl

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.


Author: "Diego R." <dieram3@gmail.com>
Date: Thu, 30 May 2013 23:34:12 -0700 (PDT)
Raw View
------=_Part_422_23058727.1369982052962
Content-Type: text/plain; charset=ISO-8859-1

I agree in most, but I don't understand why move_top() has to provide
strong exception guarantee since priority_queue use heap operations and
they are often swapping objects without any verification. For example an
exception could be thrown in middle of pop_heap and therefore to invalidate
the priority queue. Am I right?

I like the name pull(),

   value_type pull()
    {
       std::pop_heap(c.begin(),c.end(),comp);
       value_type tmp = std::move(c.back());
       c.pop_back();
       return tmp;
    }

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_422_23058727.1369982052962
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree in most, but I don't understand why move_top() has to provide stron=
g exception guarantee since priority_queue use heap operations and they are=
 often swapping objects without any verification. For example an exception =
could be thrown in middle of pop_heap and therefore to invalidate the prior=
ity queue. Am I right?<div><br></div><div>I like the name pull(),</div><div=
><br></div><div><div>&nbsp; &nbsp;value_type pull()</div><div>&nbsp; &nbsp;=
 {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;std::pop_heap(c.begin(),c.end(),com=
p);</div><div>&nbsp; &nbsp; &nbsp; &nbsp;value_type tmp =3D std::move(c.bac=
k());</div><div>&nbsp; &nbsp; &nbsp; &nbsp;c.pop_back();</div><div>&nbsp; &=
nbsp; &nbsp; &nbsp;return tmp;</div><div>&nbsp; &nbsp; }</div></div><div><b=
r></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_422_23058727.1369982052962--

.