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<std::unique_ptr<MyPolymorphicClass>>.<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 <class T, class Container=
, class Comparer></div><div> class priority_queue</div><div> {=
</div><div> ...</div><div> value_type move_top()</div><di=
v> {</div><div> value_type v;</div><div>&nb=
sp; pop(v);</div><div> return v; </=
div><div> }</div><div><br></div><div> void pop(valu=
e_type& v)</div><div> {</div><div> std::=
pop_heap(c.begin(), c.end(), comp); </div><div> v =
=3D std::move(c.back());</div><div> c.pop_back();</div><=
div> }</div><div> </div><div> };</div><div><br></div>=
<div><div>template <class T, class Container></div><div> class s=
tack</div><div> {</div><div> ...</div><div> value_ty=
pe move_top()</div><div> {</div><div> value=
_type v;</div><div> pop(v);</div><div> &nb=
sp; return v; </div><div> }</div><div><br></div><div>&nbs=
p; void pop(value_type& v)</div><div> { </div><d=
iv> v =3D std::move(c.back());</div><div> &=
nbsp;c.pop_back();</div><div> }</div><div> </div><div>&nbs=
p;};</div></div><div><br></div><div><div>template <class T, class Contai=
ner></div><div> class queue</div><div> {</div><div> ...<=
/div><div> value_type move_front()</div><div> {</di=
v><div> value_type v;</div><div> po=
p(v);</div><div> return v; </div><div> &nbs=
p;}</div><div><br></div><div> void pop(value_type& v)</div>=
<div> { </div><div> v =3D std::move(c.f=
ront());</div><div> c.pop_front();</div><div> &nbs=
p;}</div><div> </div><div> };</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<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<std::unique_<wbr>ptr<MyPolymorph=
icClass>>.<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 <class T, class Container, class Comparer></div><div> cla=
ss priority_queue</div><div> {</div><div> ...</div><div> &=
nbsp;value_type move_top()</div><div> {</div><div> =
value_type v;</div><div> pop(v);</div><div>&nbs=
p; return v; </div><div> }</div><div><br></=
div><div> void pop(value_type& v)</div><div> {<=
/div><div> std::pop_heap(c.begin(), c.end(), comp); =
;</div><div> v =3D std::move(c.back());</div><div> =
c.pop_back();</div><div> }</div><div> </div>=
<div> };</div><div><br></div><div><div>template <class T, class Con=
tainer></div><div> class stack</div><div> {</div><div> .=
...</div><div> value_type move_top()</div><div> {</d=
iv><div> value_type v;</div><div> p=
op(v);</div><div> return v; </div><div> &nb=
sp;}</div><div><br></div><div> void pop(value_type& v)</div=
><div> { </div><div> v =3D std::move(c.=
back());</div><div> c.pop_back();</div><div>  =
;}</div><div> </div><div> };</div></div><div><br></div><div><div>=
template <class T, class Container></div><div> class queue</div>=
<div> {</div><div> ...</div><div> value_type move_fr=
ont()</div><div> {</div><div> value_type v;=
</div><div> pop(v);</div><div> retu=
rn v; </div><div> }</div><div><br></div><div>  =
;void pop(value_type& v)</div><div> { </div><div> =
; v =3D std::move(c.front());</div><div> c.=
pop_front();</div><div> }</div><div> </div><div> };</=
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 />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<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;">>
<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> </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> </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. 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. My preference would be pop_valu=
e() instead of move_top(), however ...<br><br> </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<MoveOnly>. 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. 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&) overload and nothing else would be enough to solve the Mo=
veOnly case.<br><br>I'd prefer to write:<br><br> au=
to x =3D pq.move_top();<br><br>rather than:<br><br> PQ::v=
alue_type x;<br> pq.pop(x);<br><br>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&am=
p;) or during the return in move_top(), so the container is in an unspecifi=
ed 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_typ=
e> as a precondition for the strong exception safety guarantee.<br><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<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
écrit :<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;">>
<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>
</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> </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. 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
...<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&) overload and
nothing else would be enough to solve the MoveOnly case.<br>
<br>
I'd prefer to write:<br>
<br>
auto x = pq.move_top();<br>
<br>
rather than:<br>
<br>
PQ::value_type x;<br>
pq.pop(x);<br>
<br>
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.<br>
<br>
</blockquote>
Agreed.<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
<br />
<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 />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" 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 />
<br />
<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> value_type pull()</div><div> =
{</div><div> std::pop_heap(c.begin(),c.end(),com=
p);</div><div> value_type tmp =3D std::move(c.bac=
k());</div><div> c.pop_back();</div><div> &=
nbsp; return tmp;</div><div> }</div></div><div><b=
r></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
<br />
<br />
------=_Part_422_23058727.1369982052962--
.