Topic: Move semantics in stringstream
Author: Christof Meerwald <cmeerw@cmeerw.org>
Date: Mon, 5 Aug 2013 12:00:35 +0200
Raw View
I am resurrecting an old thread from comp.std.c++ as I was wondering
the other day why I couldn't move a string into an istringstream. Has
this been discussed any further in the meantime?
Christof
On Sun, 4 Mar 2012 14:23:21 -0800 (PST), Daniel Kr=FCgler wrote:
> Am 26.02.2012 17:04, schrieb Jason McKesson:
> [..]
>>
>> In C++11, we have move semantics. So the copying is completely
>> unnecessary from a language point of view. Sadly, the API was not
>> properly updated to match.
>>
>> What we need is for std::stringbuf and the corresponding functions in
>> the stringstream classes to be able to have a string moved into them.
>> Also, they should be able to have their contents removed without a copy.
>
>
> I agree.
>
>> So it would look something like this:
>>
>> std::stringstream out_data{std::move(some_string)};
>
>
> Presumably this is a function that implementors could easy provide
> (and probably will).
>
>> out_data<< ...;
>> std::string my_data =3D out_data.move_str();
>
>
> I generally agree with the usefulness of that.
>
>> Where move_str() will actually steal the string from the stream. No
>> string data is ever copied here. move_str should properly invalidate the
>> stream, as if the user had moved from the stream itself.
>
>
> My initial reaction was that this may be too strong (because the
> function name may indicate a less harmful operation), but after some
> further reflections I tend to agree.
>
>> The current constructor of std::stringbuf, and the associated
>> stringstream classes, take a `const&` to a basic_string. They should
>> take their string argument by value (thus copying when movement is not
>> allowed) and simply move it to where it needs to go. If that is not
>> possible due to backwards compatibility issues, then it can take an
>> r-value reference instead of a value.
>
>
> There is no reason to enforce implementations to break their ABI. IMO
> adding constructors that accept a basic_string<>&& should suffice. We
> may want the same for the str() setter function. There are similar
> examples in the standard that follow this signature "strategy", e.g.
> the container adaptors.
>
> Related to that one could argue that basic_regex should provide
> similar string-based move operations.
>
> Greetings from Bremen,
>
> Daniel Kr=FCgler
--=20
http://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Aug 2013 09:13:04 +0300
Raw View
--001a11c2c6bc6f127304e3ba04ad
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 5 August 2013 13:00, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> I am resurrecting an old thread from comp.std.c++ as I was wondering
> the other day why I couldn't move a string into an istringstream. Has
> this been discussed any further in the meantime?
>
The idea is probably straightforward and uncontroversial enough that someon=
e
should just write a proposal. It pains me to notice that I failed to have
this
as an NB comment, it's been on my laundry list for quite some time but
managed
to fall between the cracks.
>
>
> Christof
>
> On Sun, 4 Mar 2012 14:23:21 -0800 (PST), Daniel Kr=FCgler wrote:
> > Am 26.02.2012 17:04, schrieb Jason McKesson:
> > [..]
> >>
> >> In C++11, we have move semantics. So the copying is completely
> >> unnecessary from a language point of view. Sadly, the API was not
> >> properly updated to match.
> >>
> >> What we need is for std::stringbuf and the corresponding functions in
> >> the stringstream classes to be able to have a string moved into them.
> >> Also, they should be able to have their contents removed without a cop=
y.
> >
> >
> > I agree.
> >
> >> So it would look something like this:
> >>
> >> std::stringstream out_data{std::move(some_string)};
> >
> >
> > Presumably this is a function that implementors could easy provide
> > (and probably will).
> >
> >> out_data<< ...;
> >> std::string my_data =3D out_data.move_str();
> >
> >
> > I generally agree with the usefulness of that.
> >
> >> Where move_str() will actually steal the string from the stream. No
> >> string data is ever copied here. move_str should properly invalidate t=
he
> >> stream, as if the user had moved from the stream itself.
> >
> >
> > My initial reaction was that this may be too strong (because the
> > function name may indicate a less harmful operation), but after some
> > further reflections I tend to agree.
> >
> >> The current constructor of std::stringbuf, and the associated
> >> stringstream classes, take a `const&` to a basic_string. They should
> >> take their string argument by value (thus copying when movement is not
> >> allowed) and simply move it to where it needs to go. If that is not
> >> possible due to backwards compatibility issues, then it can take an
> >> r-value reference instead of a value.
> >
> >
> > There is no reason to enforce implementations to break their ABI. IMO
> > adding constructors that accept a basic_string<>&& should suffice. We
> > may want the same for the str() setter function. There are similar
> > examples in the standard that follow this signature "strategy", e.g.
> > the container adaptors.
> >
> > Related to that one could argue that basic_regex should provide
> > similar string-based move operations.
> >
> > Greetings from Bremen,
> >
> > Daniel Kr=FCgler
>
> --
>
> http://cmeerw.org sip:cmeerw at cmeerw.org
> mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org
>
> --
>
> ---
> 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/.
>
--=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/.
--001a11c2c6bc6f127304e3ba04ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 August 2013 13:00, Christof Meerwald <span dir=3D"ltr"><<a =
href=3D"mailto:cmeerw@cmeerw.org" target=3D"_blank">cmeerw@cmeerw.org</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I am resurrecting an old thread from comp.st=
d.c++ as I was wondering<br>
the other day why I couldn't move a string into an istringstream. Has<b=
r>
this been discussed any further in the meantime?<br></blockquote><div><br><=
/div><div>The idea is probably straightforward and uncontroversial enough t=
hat someone<br>should just write a proposal. It pains me to notice that I f=
ailed to have this<br>
as an NB comment, it's been on my laundry list for quite some time but =
managed<br>to fall between the cracks.<br>=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<br>
<br>
Christof<br>
<br>
On Sun, =A04 Mar 2012 14:23:21 -0800 (PST), Daniel Kr=FCgler wrote:<br>
> Am 26.02.2012 17:04, schrieb Jason McKesson:<br>
> [..]<br>
>><br>
>> In C++11, we have move semantics. So the copying is completely<br>
>> unnecessary from a language point of view. Sadly, the API was not<=
br>
>> properly updated to match.<br>
>><br>
>> What we need is for std::stringbuf and the corresponding functions=
in<br>
>> the stringstream classes to be able to have a string moved into th=
em.<br>
>> Also, they should be able to have their contents removed without a=
copy.<br>
><br>
><br>
> I agree.<br>
><br>
>> So it would look something like this:<br>
>><br>
>> std::stringstream out_data{std::move(some_string)};<br>
><br>
><br>
> Presumably this is a function that implementors could easy provide<br>
> (and probably will).<br>
><br>
>> out_data<< ...;<br>
>> std::string my_data =3D out_data.move_str();<br>
><br>
><br>
> I generally agree with the usefulness of that.<br>
><br>
>> Where move_str() will actually steal the string from the stream. N=
o<br>
>> string data is ever copied here. move_str should properly invalida=
te the<br>
>> stream, as if the user had moved from the stream itself.<br>
><br>
><br>
> My initial reaction was that this may be too strong (because the<br>
> function name may indicate a less harmful operation), but after some<b=
r>
> further reflections I tend to agree.<br>
><br>
>> The current constructor of std::stringbuf, and the associated<br>
>> stringstream classes, take a `const&` to a basic_string. They =
should<br>
>> take their string argument by value (thus copying when movement is=
not<br>
>> allowed) and simply move it to where it needs to go. If that is no=
t<br>
>> possible due to backwards compatibility issues, then it can take a=
n<br>
>> r-value reference instead of a value.<br>
><br>
><br>
> There is no reason to enforce implementations to break their ABI. IMO<=
br>
> adding constructors that accept a basic_string<>&& shoul=
d suffice. We<br>
> may want the same for the str() setter function. There are similar<br>
> examples in the standard that follow this signature "strategy&quo=
t;, e.g.<br>
> the container adaptors.<br>
><br>
> Related to that one could argue that basic_regex should provide<br>
> similar string-based move operations.<br>
><br>
> Greetings from Bremen,<br>
><br>
> Daniel Kr=FCgler<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
<a href=3D"http://cmeerw.org" target=3D"_blank">http://cmeerw.org</a> =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sip:cmeerw at <a hre=
f=3D"http://cmeerw.org" target=3D"_blank">cmeerw.org</a><br>
mailto:<a href=3D"mailto:cmeerw">cmeerw</a> at <a href=3D"http://cmeerw.org=
" target=3D"_blank">cmeerw.org</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xmpp=
:cmeerw at <a href=3D"http://cmeerw.org" target=3D"_blank">cmeerw.org</a><b=
r>
<br>
--<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2c6bc6f127304e3ba04ad--
.
Author: Bo Persson <bop@gmb.dk>
Date: Mon, 12 Aug 2013 11:06:59 +0200
Raw View
Ville Voutilainen skrev 2013-08-12 08:13:
>
>
>
> On 5 August 2013 13:00, Christof Meerwald <cmeerw@cmeerw.org
> <mailto:cmeerw@cmeerw.org>> wrote:
>
> I am resurrecting an old thread from comp.std.c++ as I was wondering
> the other day why I couldn't move a string into an istringstream. Has
> this been discussed any further in the meantime?
>
>
> The idea is probably straightforward and uncontroversial enough that someone
> should just write a proposal. It pains me to notice that I failed to
> have this
> as an NB comment, it's been on my laundry list for quite some time but
> managed
> to fall between the cracks.
>
>
I believe this might open up a whole new can of worms. :-)
If moving to the stream is supposed to be an O(1) operation the stream
will be required to store a string, or at least use the string's
(possibly stateful) allocator to manage storage.
How is this interacting with the allocator_traits? Does it make
stringstream a container (affected by propagate_on_container_*)? In that
case, can I also have an operator[] and a data() member function?
Bo Persson
--
---
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/.
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Mon, 12 Aug 2013 11:32:42 +0100
Raw View
On 12/08/13 10:06, Bo Persson wrote:
> Ville Voutilainen skrev 2013-08-12 08:13:
>>
>>
>>
>> On 5 August 2013 13:00, Christof Meerwald <cmeerw@cmeerw.org
>> <mailto:cmeerw@cmeerw.org>> wrote:
>>
>> I am resurrecting an old thread from comp.std.c++ as I was wondering
>> the other day why I couldn't move a string into an istringstream.
>> Has
>> this been discussed any further in the meantime?
>>
>>
>> The idea is probably straightforward and uncontroversial enough that
>> someone
>> should just write a proposal. It pains me to notice that I failed to
>> have this
>> as an NB comment, it's been on my laundry list for quite some time but
>> managed
>> to fall between the cracks.
>>
>>
>
> I believe this might open up a whole new can of worms. :-)
>
> If moving to the stream is supposed to be an O(1) operation the stream
> will be required to store a string, or at least use the string's
> (possibly stateful) allocator to manage storage.
I don't think we should put restrictions on like O(1), just provide the
operation. Implementations can choose to optimise based on their
internal understanding of a std::string, or not.
Chris
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Aug 2013 15:05:48 +0300
Raw View
--047d7b33d374ea5bf104e3bef1e5
Content-Type: text/plain; charset=ISO-8859-1
On 12 August 2013 13:32, Chris Jefferson <chris@bubblescope.net> wrote:
> On 12/08/13 10:06, Bo Persson wrote:
>
>> Ville Voutilainen skrev 2013-08-12 08:13:
>>
>>>
>>>
>>>
>>> On 5 August 2013 13:00, Christof Meerwald <cmeerw@cmeerw.org
>>> <mailto:cmeerw@cmeerw.org>> wrote:
>>>
>>> I am resurrecting an old thread from comp.std.c++ as I was wondering
>>> the other day why I couldn't move a string into an istringstream. Has
>>> this been discussed any further in the meantime?
>>>
>>>
>>> The idea is probably straightforward and uncontroversial enough that
>>> someone
>>> should just write a proposal. It pains me to notice that I failed to
>>> have this
>>> as an NB comment, it's been on my laundry list for quite some time but
>>> managed
>>> to fall between the cracks.
>>>
>>>
>>>
>> I believe this might open up a whole new can of worms. :-)
>>
>> If moving to the stream is supposed to be an O(1) operation the stream
>> will be required to store a string, or at least use the string's (possibly
>> stateful) allocator to manage storage.
>>
> I don't think we should put restrictions on like O(1), just provide the
> operation. Implementations can choose to optimise based on their internal
> understanding of a std::string, or not.
>
>
>
Containers already place limitations on what can be done if allocators
don't match, so I wouldn't think it far-fetched
to have similar limitations for stringstreams and strings. Be that as it
may, perhaps we should indeed focus
on providing the functionality, rather than having the usual decision
between having something that's perfect
and optimized for corner cases, and having nothing at all, in which case we
will likely not have the move because
someone found some mystical case where it's sub-optimal.
--
---
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/.
--047d7b33d374ea5bf104e3bef1e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 August 2013 13:32, Chris Jefferson <span dir=3D"ltr"><<a h=
ref=3D"mailto:chris@bubblescope.net" target=3D"_blank">chris@bubblescope.ne=
t</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 12/08/13 10:06, Bo Pers=
son wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Ville Voutilainen skrev 2013-08-12 08:13:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On 5 August 2013 13:00, Christof Meerwald <<a href=3D"mailto:cmeerw@cmee=
rw.org" target=3D"_blank">cmeerw@cmeerw.org</a><br>
<mailto:<a href=3D"mailto:cmeerw@cmeerw.org" target=3D"_blank">cmeerw@cm=
eerw.org</a>>> wrote:<br>
<br>
=A0 =A0 I am resurrecting an old thread from comp.std.c++ as I was wonderin=
g<br>
=A0 =A0 the other day why I couldn't move a string into an istringstrea=
m. Has<br>
=A0 =A0 this been discussed any further in the meantime?<br>
<br>
<br>
The idea is probably straightforward and uncontroversial enough that someon=
e<br>
should just write a proposal. It pains me to notice that I failed to<br>
have this<br>
as an NB comment, it's been on my laundry list for quite some time but<=
br>
managed<br>
to fall between the cracks.<br>
<br>
<br>
</blockquote>
<br>
I believe this might open up a whole new can of worms. :-)<br>
<br>
If moving to the stream is supposed to be an O(1) operation the stream will=
be required to store a string, or at least use the string's (possibly =
stateful) allocator to manage storage.<br>
</blockquote></div>
I don't think we should put restrictions on like O(1), just provide the=
operation. Implementations can choose to optimise based on their internal =
understanding of a std::string, or not.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br>
<br><br></font></span></blockquote><div><br></div><div>Containers already p=
lace limitations on what can be done if allocators don't match, so I wo=
uldn't think it far-fetched<br></div><div>to have similar limitations f=
or stringstreams and strings. Be that as it may, perhaps we should indeed f=
ocus<br>
on providing the functionality, rather than having the usual decision betwe=
en having something that's perfect<br>and optimized for corner cases, a=
nd having nothing at all, in which case we will likely not have the move be=
cause<br>
</div><div>someone found some mystical case where it's sub-optimal. <br=
></div></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b33d374ea5bf104e3bef1e5--
.
Author: Bo Persson <bop@gmb.dk>
Date: Mon, 12 Aug 2013 14:58:16 +0200
Raw View
Chris Jefferson wrote 2013-08-12 12:32:
> On 12/08/13 10:06, Bo Persson wrote:
>> Ville Voutilainen skrev 2013-08-12 08:13:
>>>
>>>
>>>
>>> On 5 August 2013 13:00, Christof Meerwald <cmeerw@cmeerw.org
>>> <mailto:cmeerw@cmeerw.org>> wrote:
>>>
>>> I am resurrecting an old thread from comp.std.c++ as I was wondering
>>> the other day why I couldn't move a string into an istringstream.
>>> Has
>>> this been discussed any further in the meantime?
>>>
>>>
>>> The idea is probably straightforward and uncontroversial enough that
>>> someone
>>> should just write a proposal. It pains me to notice that I failed to
>>> have this
>>> as an NB comment, it's been on my laundry list for quite some time but
>>> managed
>>> to fall between the cracks.
>>>
>>>
>>
>> I believe this might open up a whole new can of worms. :-)
>>
>> If moving to the stream is supposed to be an O(1) operation the stream
>> will be required to store a string, or at least use the string's
>> (possibly stateful) allocator to manage storage.
> I don't think we should put restrictions on like O(1), just provide the
> operation. Implementations can choose to optimise based on their
> internal understanding of a std::string, or not.
>
Then how useful is a function that isn't guaranteed to be an optimization?
If I need the speed of moving the string, the code will only be portable
to implementations actually supporting this.
Bo Persson
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Aug 2013 16:08:50 +0300
Raw View
--047d7bd7572853128c04e3bfd39f
Content-Type: text/plain; charset=ISO-8859-1
On 12 August 2013 15:58, Bo Persson <bop@gmb.dk> wrote:
> If moving to the stream is supposed to be an O(1) operation the stream
>
>> will be required to store a string, or at least use the string's
>>> (possibly stateful) allocator to manage storage.
>>>
>> I don't think we should put restrictions on like O(1), just provide the
>> operation. Implementations can choose to optimise based on their
>> internal understanding of a std::string, or not.
>>
>>
> Then how useful is a function that isn't guaranteed to be an optimization?
>
> If I need the speed of moving the string, the code will only be portable
> to implementations actually supporting this.
>
>
>
Let's see. If we have default-allocated stringstream and string, why
wouldn't it be an O(1) operation?
Does that place some hitherto unknown string storage requirements on
stringstream? Or more specifically,
on stringbuf? basic_stringbuf already knows how to copy a string with a
certain allocator
into whatever never-neverland it actually uses for storing the string, why
couldn't it move from a string
into the same never-neverland? What is this alleged "can of worms" here? As
with containers, if allocators
match, we can move, if allocators don't match, perhaps the move operation
needs to be ill-formed, or
fall back on copying and users failing to understand be damned. The
ill-formed solution would seemingly
be quite simple, without many worms in the can.
--
---
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/.
--047d7bd7572853128c04e3bfd39f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 August 2013 15:58, Bo Persson <span dir=3D"ltr"><<a href=
=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
If moving to the stream is supposed to be an O(1) operation the stream<br><=
div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
will be required to store a string, or at least use the string's<br>
(possibly stateful) allocator to manage storage.<br>
</blockquote>
I don't think we should put restrictions on like O(1), just provide the=
<br>
operation. Implementations can choose to optimise based on their<br>
internal understanding of a std::string, or not.<br>
<br>
</blockquote>
<br></div>
Then how useful is a function that isn't guaranteed to be an optimizati=
on?<br>
<br>
If I need the speed of moving the string, the code will only be portable to=
implementations actually supporting this.<span class=3D"HOEnZb"><font colo=
r=3D"#888888"><br>
<br><br></font></span></blockquote><div><br></div><div>Let's see. If we=
have default-allocated stringstream and string, why wouldn't it be an =
O(1) operation?<br></div><div>Does that place some hitherto unknown string =
storage requirements on stringstream? Or more specifically,<br>
on stringbuf? basic_stringbuf already knows how to copy a string with a cer=
tain allocator<br></div><div>into whatever never-neverland it actually uses=
for storing the string, why couldn't it move from a string<br>into the=
same never-neverland? What is this alleged "can of worms" here? =
As with containers, if allocators<br>
</div><div>match, we can move, if allocators don't match, perhaps the m=
ove operation needs to be ill-formed, or<br>fall back on copying and users =
failing to understand be damned. The ill-formed solution would seemingly<br=
>
</div><div>be quite simple, without many worms in the can. <br></div></div>=
<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd7572853128c04e3bfd39f--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Mon, 12 Aug 2013 15:51:10 +0100
Raw View
This is a multi-part message in MIME format.
--------------090407080808050105070203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/08/13 14:08, Ville Voutilainen wrote:
>
>
>
> On 12 August 2013 15:58, Bo Persson <bop@gmb.dk <mailto:bop@gmb.dk>>
> wrote:
>
> If moving to the stream is supposed to be an O(1) operation the stream
>
> will be required to store a string, or at least use the
> string's
> (possibly stateful) allocator to manage storage.
>
> I don't think we should put restrictions on like O(1), just
> provide the
> operation. Implementations can choose to optimise based on their
> internal understanding of a std::string, or not.
>
>
> Then how useful is a function that isn't guaranteed to be an
> optimization?
>
> If I need the speed of moving the string, the code will only be
> portable to implementations actually supporting this.
>
>
>
> Let's see. If we have default-allocated stringstream and string, why
> wouldn't it be an O(1) operation?
> Does that place some hitherto unknown string storage requirements on
> stringstream? Or more specifically,
> on stringbuf? basic_stringbuf already knows how to copy a string with
> a certain allocator
> into whatever never-neverland it actually uses for storing the string,
> why couldn't it move from a string
> into the same never-neverland? What is this alleged "can of worms"
> here? As with containers, if allocators
> match, we can move, if allocators don't match, perhaps the move
> operation needs to be ill-formed, or
> fall back on copying and users failing to understand be damned. The
> ill-formed solution would seemingly
> be quite simple, without many worms in the can.
There may well no can of worms at all. But (for example) perhaps some
implementations of streambuf use a memory layout which is not identical
to std::string. I'd personally love to see an implementation just to
check however. My only worry is if some implementations do not use the
same memory layout for std::string and std::stringbuf.
Also, rather than just hacking this onto stringstream, as you mention
the changes should probably go down to stringbuf.
Having a quick glance at libc++'s basic_streambuf it looks like moving a
string in efficiently will be easy, moving it back out is slightly less
trivial but still not too hard.
Chris
--
---
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/.
--------------090407080808050105070203
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">On 12/08/13 14:08, Ville Voutilainen
wrote:<br>
</div>
<blockquote
cite="mid:CAFk2RUbTOJ5vq54PHr91S7O4vGZO+WNf=wWJP9nA_K4nJK38Zg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 12 August 2013 15:58, Bo Persson <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:bop@gmb.dk" target="_blank">bop@gmb.dk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
If moving to the stream is supposed to be an O(1)
operation the stream<br>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
will be required to store a string, or at least use
the string's<br>
(possibly stateful) allocator to manage storage.<br>
</blockquote>
I don't think we should put restrictions on like O(1),
just provide the<br>
operation. Implementations can choose to optimise
based on their<br>
internal understanding of a std::string, or not.<br>
<br>
</blockquote>
<br>
</div>
Then how useful is a function that isn't guaranteed to be
an optimization?<br>
<br>
If I need the speed of moving the string, the code will
only be portable to implementations actually supporting
this.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
</font></span></blockquote>
<div><br>
</div>
<div>Let's see. If we have default-allocated stringstream
and string, why wouldn't it be an O(1) operation?<br>
</div>
<div>Does that place some hitherto unknown string storage
requirements on stringstream? Or more specifically,<br>
on stringbuf? basic_stringbuf already knows how to copy a
string with a certain allocator<br>
</div>
<div>into whatever never-neverland it actually uses for
storing the string, why couldn't it move from a string<br>
into the same never-neverland? What is this alleged "can
of worms" here? As with containers, if allocators<br>
</div>
<div>match, we can move, if allocators don't match, perhaps
the move operation needs to be ill-formed, or<br>
fall back on copying and users failing to understand be
damned. The ill-formed solution would seemingly<br>
</div>
<div>be quite simple, without many worms in the can. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
There may well no can of worms at all. But (for example) perhaps
some implementations of streambuf use a memory layout which is not
identical to std::string. I'd personally love to see an
implementation just to check however. My only worry is if some
implementations do not use the same memory layout for std::string
and std::stringbuf.<br>
<br>
Also, rather than just hacking this onto stringstream, as you
mention the changes should probably go down to stringbuf.<br>
<br>
Having a quick glance at libc++'s basic_streambuf it looks like
moving a string in efficiently will be easy, moving it back out is
slightly less trivial but still not too hard.<br>
<br>
Chris<br>
<br>
<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090407080808050105070203--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 12 Aug 2013 07:52:37 -0700 (PDT)
Raw View
------=_Part_2403_22323894.1376319157698
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 12, 2013 5:58:16 AM UTC-7, Bo Persson wrote:
>
> Chris Jefferson wrote 2013-08-12 12:32:
> > On 12/08/13 10:06, Bo Persson wrote:
> >> Ville Voutilainen skrev 2013-08-12 08:13:
> >>>
> >>>
> >>>
> >>> On 5 August 2013 13:00, Christof Meerwald <cme...@cmeerw.org<javascript:>
> >>> <mailto:cme...@cmeerw.org <javascript:>>> wrote:
> >>>
> >>> I am resurrecting an old thread from comp.std.c++ as I was
> wondering
> >>> the other day why I couldn't move a string into an istringstream.
> >>> Has
> >>> this been discussed any further in the meantime?
> >>>
> >>>
> >>> The idea is probably straightforward and uncontroversial enough that
> >>> someone
> >>> should just write a proposal. It pains me to notice that I failed to
> >>> have this
> >>> as an NB comment, it's been on my laundry list for quite some time but
> >>> managed
> >>> to fall between the cracks.
> >>>
> >>>
> >>
> >> I believe this might open up a whole new can of worms. :-)
> >>
> >> If moving to the stream is supposed to be an O(1) operation the stream
> >> will be required to store a string, or at least use the string's
> >> (possibly stateful) allocator to manage storage.
> > I don't think we should put restrictions on like O(1), just provide the
> > operation. Implementations can choose to optimise based on their
> > internal understanding of a std::string, or not.
> >
>
> Then how useful is a function that isn't guaranteed to be an optimization?
>
> If I need the speed of moving the string, the code will only be portable
> to implementations actually supporting this.
>
That requires a very specific definition of "portable". Portability is
usually applied to *functioning*, not how fast it goes.
vector::shrink_to_fit has no specific requirements either; it can be a
complete no-op. The standard has plenty of places where an implementation
can be conforming yet not be as optimal as possible.
--
---
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/.
------=_Part_2403_22323894.1376319157698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 12, 2013 5:58:16 AM UTC-7, Bo Persson wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Chris Jefferson wrote 2013=
-08-12 12:32:
<br>> On 12/08/13 10:06, Bo Persson wrote:
<br>>> Ville Voutilainen skrev 2013-08-12 08:13:
<br>>>>
<br>>>>
<br>>>>
<br>>>> On 5 August 2013 13:00, Christof Meerwald <<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R-waGipgCxMJ">cme...=
@cmeerw.org</a>
<br>>>> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"R-waGipgCxMJ">cme...@cmeerw.org</a>>> wrote:
<br>>>>
<br>>>> I am resurrecting an old thread from comp.st=
d.c++ as I was wondering
<br>>>> the other day why I couldn't move a string i=
nto an istringstream.
<br>>>> Has
<br>>>> this been discussed any further in the meant=
ime?
<br>>>>
<br>>>>
<br>>>> The idea is probably straightforward and uncontroversial e=
nough that
<br>>>> someone
<br>>>> should just write a proposal. It pains me to notice that I=
failed to
<br>>>> have this
<br>>>> as an NB comment, it's been on my laundry list for quite s=
ome time but
<br>>>> managed
<br>>>> to fall between the cracks.
<br>>>>
<br>>>>
<br>>>
<br>>> I believe this might open up a whole new can of worms. :-)
<br>>>
<br>>> If moving to the stream is supposed to be an O(1) operation th=
e stream
<br>>> will be required to store a string, or at least use the string=
's
<br>>> (possibly stateful) allocator to manage storage.
<br>> I don't think we should put restrictions on like O(1), just provid=
e the
<br>> operation. Implementations can choose to optimise based on their
<br>> internal understanding of a std::string, or not.
<br>>
<br>
<br>Then how useful is a function that isn't guaranteed to be an optimizati=
on?
<br>
<br>If I need the speed of moving the string, the code will only be portabl=
e=20
<br>to implementations actually supporting this.
<br></blockquote><div><br>That requires a very specific definition of "port=
able". Portability is usually applied to <i>functioning</i>, not how fast i=
t goes.<br><br>vector::shrink_to_fit has no specific requirements either; i=
t can be a complete no-op. The standard has plenty of places where an imple=
mentation can be conforming yet not be as optimal as possible. <br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2403_22323894.1376319157698--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Aug 2013 18:57:56 +0300
Raw View
--e89a8f5029361802ae04e3c230de
Content-Type: text/plain; charset=ISO-8859-1
On 12 August 2013 17:52, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> If I need the speed of moving the string, the code will only be portable
>> to implementations actually supporting this.
>>
>
> That requires a very specific definition of "portable". Portability is
> usually applied to *functioning*, not how fast it goes.
>
>
In c++, it has for a very long time been a fundamental design principle
that performance is portable,
as far as possible. That's why the standard specifies the complexities of
eg. container operations
in such detail as it does. That's of course not completely equivalent to
"how fast it goes", and
we try to avoid limiting implementation freedom, but portable performance
has always been
a goal of c++.
--
---
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/.
--e89a8f5029361802ae04e3c230de
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 August 2013 17:52, Nicol Bolas <span dir="ltr"><<a href="mailto:jmckesson@gmail.com" target="_blank">jmckesson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">If I need the speed of moving the string, the code will only be portable
<br>to implementations actually supporting this.
<br></div></blockquote><div><br>That requires a very specific definition of "portable". Portability is usually applied to <i>functioning</i>, not how fast it goes.<br><br></div></div></blockquote><div><br></div>
<div>In c++, it has for a very long time been a fundamental design principle that performance is portable,<br>as far as possible. That's why the standard specifies the complexities of eg. container operations<br></div>
<div>in such detail as it does. That's of course not completely equivalent to "how fast it goes", and<br>we try to avoid limiting implementation freedom, but portable performance has always been<br>a goal of c++. <br>
</div></div><br></div></div>
<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
--e89a8f5029361802ae04e3c230de--
.
Author: Bo Persson <bop@gmb.dk>
Date: Mon, 12 Aug 2013 20:21:03 +0200
Raw View
Ville Voutilainen skrev 2013-08-12 15:08:
>
>
>
> On 12 August 2013 15:58, Bo Persson <bop@gmb.dk <mailto:bop@gmb.dk>> wrote:
>
> If moving to the stream is supposed to be an O(1) operation the stream
>
> will be required to store a string, or at least use the string's
> (possibly stateful) allocator to manage storage.
>
> I don't think we should put restrictions on like O(1), just
> provide the
> operation. Implementations can choose to optimise based on their
> internal understanding of a std::string, or not.
>
>
> Then how useful is a function that isn't guaranteed to be an
> optimization?
>
> If I need the speed of moving the string, the code will only be
> portable to implementations actually supporting this.
>
>
>
> Let's see. If we have default-allocated stringstream and string, why
> wouldn't it be an O(1) operation?
> Does that place some hitherto unknown string storage requirements on
> stringstream? Or more specifically,
> on stringbuf? basic_stringbuf already knows how to copy a string with a
> certain allocator
> into whatever never-neverland it actually uses for storing the string,
> why couldn't it move from a string
> into the same never-neverland? What is this alleged "can of worms" here?
> As with containers, if allocators
> match, we can move, if allocators don't match, perhaps the move
> operation needs to be ill-formed, or
> fall back on copying and users failing to understand be damned. The
> ill-formed solution would seemingly
> be quite simple, without many worms in the can.
>
One example is if you use a stateful allocator, its state will likely
move away with the string leaving the stringbuf. Then how do we allocate
space for any new content?
Copying is a lot simpler.
Bo Persson
--
---
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/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Mon, 12 Aug 2013 20:31:22 +0200
Raw View
Chris Jefferson skrev 2013-08-12 16:51:
> On 12/08/13 14:08, Ville Voutilainen wrote:
>>
>>
>>
>> On 12 August 2013 15:58, Bo Persson <bop@gmb.dk <mailto:bop@gmb.dk>>
>> wrote:
>>
>> If moving to the stream is supposed to be an O(1) operation the stream
>>
>> will be required to store a string, or at least use the
>> string's
>> (possibly stateful) allocator to manage storage.
>>
>> I don't think we should put restrictions on like O(1), just
>> provide the
>> operation. Implementations can choose to optimise based on their
>> internal understanding of a std::string, or not.
>>
>>
>> Then how useful is a function that isn't guaranteed to be an
>> optimization?
>>
>> If I need the speed of moving the string, the code will only be
>> portable to implementations actually supporting this.
>>
>>
>>
>> Let's see. If we have default-allocated stringstream and string, why
>> wouldn't it be an O(1) operation?
>> Does that place some hitherto unknown string storage requirements on
>> stringstream? Or more specifically,
>> on stringbuf? basic_stringbuf already knows how to copy a string with
>> a certain allocator
>> into whatever never-neverland it actually uses for storing the string,
>> why couldn't it move from a string
>> into the same never-neverland? What is this alleged "can of worms"
>> here? As with containers, if allocators
>> match, we can move, if allocators don't match, perhaps the move
>> operation needs to be ill-formed, or
>> fall back on copying and users failing to understand be damned. The
>> ill-formed solution would seemingly
>> be quite simple, without many worms in the can.
>
> There may well no can of worms at all. But (for example) perhaps some
> implementations of streambuf use a memory layout which is not identical
> to std::string. I'd personally love to see an implementation just to
> check however. My only worry is if some implementations do not use the
> same memory layout for std::string and std::stringbuf.
VC++ is one example where stringbuf stores an array of characters and
not a std::string.
>
> Also, rather than just hacking this onto stringstream, as you mention
> the changes should probably go down to stringbuf.
>
> Having a quick glance at libc++'s basic_streambuf it looks like moving a
> string in efficiently will be easy, moving it back out is slightly less
> trivial but still not too hard.
>
We still have to specify the state of a moved-from stringbuf. Is it
still useful when its allocator has move away or is it just in a
destructible state?
A std::string is in a "consistent but unspecified state" and cannot be
used until assigned a new value. How would that work with a
stringstream/stringbuf?
Bo Persson
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 12 Aug 2013 22:09:29 +0300
Raw View
--047d7bd766de1d7d3204e3c4dd2a
Content-Type: text/plain; charset=ISO-8859-1
On 12 August 2013 21:31, Bo Persson <bop@gmb.dk> wrote:
> We still have to specify the state of a moved-from stringbuf. Is it still
> useful when its allocator has move away or is it just in a destructible
> state?
>
Useful as in assignable? Assignable and destructible is what I expect.
>
> A std::string is in a "consistent but unspecified state" and cannot be
> used until assigned a new value. How would that work with a
> stringstream/stringbuf?
>
>
>
The same way? Assign to the stringbuf or call its str(), and it's again
alive and well?
--
---
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/.
--047d7bd766de1d7d3204e3c4dd2a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 August 2013 21:31, Bo Persson <span dir=3D"ltr"><<a href=
=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
We still have to specify the state of a moved-from stringbuf. Is it still u=
seful when its allocator has move away or is it just in a destructible stat=
e?<br></blockquote><div><br></div><div>Useful as in assignable? Assignable =
and destructible is what I expect.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>
A std::string is in a "consistent but unspecified state" and cann=
ot be used until assigned a new value. How would that work with a stringstr=
eam/stringbuf?<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br><br></font></span></blockquote><div><br></div><div>The same way? Assign=
to the stringbuf or call its str(), and it's again alive and well? <br=
></div></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd766de1d7d3204e3c4dd2a--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Mon, 12 Aug 2013 12:27:44 -0700
Raw View
On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <bop@gmb.dk> wrote:
> Chris Jefferson skrev 2013-08-12 16:51:
>>
>> On 12/08/13 14:08, Ville Voutilainen wrote:
>>>
>>>
>>>
>>>
>>> On 12 August 2013 15:58, Bo Persson <bop@gmb.dk <mailto:bop@gmb.dk>>
>>>
>>> wrote:
>>>
>>> If moving to the stream is supposed to be an O(1) operation the
>>> stream
>>>
>>> will be required to store a string, or at least use the
>>> string's
>>> (possibly stateful) allocator to manage storage.
>>>
>>> I don't think we should put restrictions on like O(1), just
>>> provide the
>>> operation. Implementations can choose to optimise based on their
>>> internal understanding of a std::string, or not.
>>>
>>>
>>> Then how useful is a function that isn't guaranteed to be an
>>> optimization?
>>>
>>> If I need the speed of moving the string, the code will only be
>>> portable to implementations actually supporting this.
>>>
>>>
>>>
>>> Let's see. If we have default-allocated stringstream and string, why
>>> wouldn't it be an O(1) operation?
>>> Does that place some hitherto unknown string storage requirements on
>>> stringstream? Or more specifically,
>>> on stringbuf? basic_stringbuf already knows how to copy a string with
>>> a certain allocator
>>> into whatever never-neverland it actually uses for storing the string,
>>> why couldn't it move from a string
>>> into the same never-neverland? What is this alleged "can of worms"
>>> here? As with containers, if allocators
>>> match, we can move, if allocators don't match, perhaps the move
>>> operation needs to be ill-formed, or
>>> fall back on copying and users failing to understand be damned. The
>>> ill-formed solution would seemingly
>>> be quite simple, without many worms in the can.
>>
>>
>> There may well no can of worms at all. But (for example) perhaps some
>> implementations of streambuf use a memory layout which is not identical
>> to std::string. I'd personally love to see an implementation just to
>> check however. My only worry is if some implementations do not use the
>> same memory layout for std::string and std::stringbuf.
>
>
> VC++ is one example where stringbuf stores an array of characters and not a
> std::string.
FWIW, since they're both part of the standard library, moving a string
into a stringbuf could pillage the string's internal char[] without
needing to store a string internally. Only chunked implementations
with the chunk length stored at the beginning of the chunk would have
a problem.
--
---
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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 12 Aug 2013 15:28:36 -0400
Raw View
On Aug 12, 2013, at 2:21 PM, Bo Persson <bop@gmb.dk> wrote:
> One example is if you use a stateful allocator, its state will likely move away with the string leaving the stringbuf. Then how do we allocate space for any new content?
I do not see any preconditions on allocate() in Table 28 -- Allocator requirements. Allocating from a moved-from allocator should not be a problem.
Howard
--
---
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/.
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Mon, 12 Aug 2013 15:34:29 -0400
Raw View
On Aug 12, 2013, at 2:31 PM, Bo Persson <bop@gmb.dk> wrote:
> We still have to specify the state of a moved-from stringbuf. Is it still=
useful when its allocator has move away or is it just in a destructible st=
ate?
>=20
> A std::string is in a "consistent but unspecified state" and cannot be us=
ed until assigned a new value. How would that work with a stringstream/stri=
ngbuf?
I recommend the same way as currently specified, which is slightly differen=
t than what you claim above. If we simply say that the basic_stringbuf is =
left in a valid but unspecified state, then the client will be able to do a=
ny operations on it that do not have preconditions. I just glanced through=
the basic_stringbuf specification and I'm not seeing preconditions or Requ=
ires clauses.
I imagine that after moving a string out of a basic_stringbuf, most clients=
would want to put it into a specified state with str(string-expression) if=
they are going to further use it.
Howard
--=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/.
.
Author: =?ISO-8859-1?Q?Ion_Gazta=F1aga?= <igaztanaga@gmail.com>
Date: Mon, 12 Aug 2013 23:52:01 +0200
Raw View
El 12/08/2013 21:28, Howard Hinnant escribi=F3:
> On Aug 12, 2013, at 2:21 PM, Bo Persson <bop@gmb.dk> wrote:
>
>> One example is if you use a stateful allocator, its state will
>> likely move away with the string leaving the stringbuf. Then how do
>> we allocate space for any new content?
>
> I do not see any preconditions on allocate() in Table 28 -- Allocator
> requirements. Allocating from a moved-from allocator should not be a
> problem.
That's interesting. Containers now take allocators by value so there is=20
no way to make a resource uniquely hold by an allocator (the copy=20
constructor is used to propagate the allocator into the internal=20
allocator instance).
In a future C++ revision a non-copyable allocator could be allowed to=20
take away its resources with a move constructor, and it could just fail=20
to allocate (e.g. the stateful allocator holds a reference to a=20
non-shared pool that's transferred using move-semantics) when used after=20
being moved.
A programmer using such special allocator can move a string with a=20
properly initialized allocator into the stringstream so that the string=20
can use the stateful resources of the outer string (a new constructor is=20
needed to move initialize the internal allocator of a container from an=20
outer allocator instance):
typedef basic_stringstream
< char
, nonshared_pool_allocator<char>
, char_traits<char>
>
mystringstream_t;
typedef basic_string
< char
, nonshared_pool_allocator<char>
, char_traits<char>
>
mystring_t;
//Throws when reallocating
nonshared_memory_pool pool;
nonshared_pool_allocator<char> al(pool);
//Declare them outside the loop to reuse memory
mystringstream_t stream;
mystring_t str;
//New constructor for C++2x
mystring_t str(move(al));
str.resize(pool.size());
while(/**/){
//Data and allocator moved into sstream
stream.str(std::move(str));
//throws if uncommented
//str +=3D ...
//Format
sstream.seekp(/**/);
sstream << a << b << c << ....
sstream << ends;
//Data and allocator extracted into str
//(extract returns a rvalue string)
str =3D sstream.extract();
//throws if uncommented
//sstream << ...
//Use it
std::cout << str;
}
Best,
Ion
--=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/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Tue, 13 Aug 2013 12:58:49 +0200
Raw View
Jeffrey Yasskin skrev 2013-08-12 21:27:
> On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <bop@gmb.dk> wrote:
>> Chris Jefferson skrev 2013-08-12 16:51:
>>>
>>>
>>> There may well no can of worms at all. But (for example) perhaps some
>>> implementations of streambuf use a memory layout which is not identical
>>> to std::string. I'd personally love to see an implementation just to
>>> check however. My only worry is if some implementations do not use the
>>> same memory layout for std::string and std::stringbuf.
>>
>>
>> VC++ is one example where stringbuf stores an array of characters and not a
>> std::string.
>
> FWIW, since they're both part of the standard library, moving a string
> into a stringbuf could pillage the string's internal char[] without
> needing to store a string internally. Only chunked implementations
> with the chunk length stored at the beginning of the chunk would have
> a problem.
>
The potential problem I see is that you have to keep track of how the
internal buffer was allocated, so it can be properly deallocated later.
That involves the allocator used (if any!) and possibly C++11
allocator_traits, if those apply to streambufs.
You can't just take the buffer and run. :-)
Bo Persson
--
---
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/.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 13 Aug 2013 05:45:51 -0700 (PDT)
Raw View
------=_Part_2147_17293820.1376397951795
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson wrote:
>
> Jeffrey Yasskin skrev 2013-08-12 21:27:
> > On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <b...@gmb.dk <javascript:>>
> wrote:
> >> Chris Jefferson skrev 2013-08-12 16:51:
> >>>
> >>>
> >>> There may well no can of worms at all. But (for example) perhaps some
> >>> implementations of streambuf use a memory layout which is not
> identical
> >>> to std::string. I'd personally love to see an implementation just to
> >>> check however. My only worry is if some implementations do not use the
> >>> same memory layout for std::string and std::stringbuf.
> >>
> >>
> >> VC++ is one example where stringbuf stores an array of characters and
> not a
> >> std::string.
> >
> > FWIW, since they're both part of the standard library, moving a string
> > into a stringbuf could pillage the string's internal char[] without
> > needing to store a string internally. Only chunked implementations
> > with the chunk length stored at the beginning of the chunk would have
> > a problem.
> >
>
> The potential problem I see is that you have to keep track of how the
> internal buffer was allocated, so it can be properly deallocated later.
> That involves the allocator used (if any!) and possibly C++11
> allocator_traits, if those apply to streambufs.
>
> You can't just take the buffer and run. :-)
>
>
> Bo Persson
>
I don't see the problem. std::stringstream already takes an allocator. And,
much like every other standard library container, you can only move from a
type that uses the same allocator type that you use, and the move
constructor will presumably copy that allocator in.
It's really no different than std::basic_string's move constructor. You
most certainly can "take the buffer and run".
--
---
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/.
------=_Part_2147_17293820.1376397951795
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Jeffrey Yasskin skrev 201=
3-08-12 21:27:
<br>> On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"q6d1eVEc94wJ">b...@gmb.dk=
</a>> wrote:
<br>>> Chris Jefferson skrev 2013-08-12 16:51:
<br>>>>
<br>>>>
<br>>>> There may well no can of worms at all. But (for example) p=
erhaps some
<br>>>> implementations of streambuf use a memory layout which is =
not identical
<br>>>> to std::string. I'd personally love to see an implementati=
on just to
<br>>>> check however. My only worry is if some implementations do=
not use the
<br>>>> same memory layout for std::string and std::stringbuf.
<br>>>
<br>>>
<br>>> VC++ is one example where stringbuf stores an array of charact=
ers and not a
<br>>> std::string.
<br>>
<br>> FWIW, since they're both part of the standard library, moving a st=
ring
<br>> into a stringbuf could pillage the string's internal char[] withou=
t
<br>> needing to store a string internally. Only chunked implementations
<br>> with the chunk length stored at the beginning of the chunk would h=
ave
<br>> a problem.
<br>>
<br>
<br>The potential problem I see is that you have to keep track of how the=
=20
<br>internal buffer was allocated, so it can be properly deallocated later.=
=20
<br>That involves the allocator used (if any!) and possibly C++11=20
<br>allocator_traits, if those apply to streambufs.
<br>
<br>You can't just take the buffer and run. :-)
<br>
<br>
<br>Bo Persson
<br></blockquote><div><br>I don't see the problem. std::stringstream alread=
y takes an allocator. And, much like every other standard library container=
, you can only move from a type that uses the same allocator type that you =
use, and the move constructor will presumably copy that allocator in.<br><b=
r>It's really no different than std::basic_string's move constructor. You m=
ost certainly can "take the buffer and run".<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_2147_17293820.1376397951795--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 13 Aug 2013 15:47:15 +0300
Raw View
--001a11c22780ff2b3704e3d3a3a3
Content-Type: text/plain; charset=ISO-8859-1
On 13 August 2013 15:45, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> I don't see the problem. std::stringstream already takes an allocator.
> And, much like every other standard library container, you can only move
> from a type that uses the same allocator type that you use, and the move
> constructor will presumably copy that allocator in.
>
The move constructor can also move the allocator in. ;)
--
---
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/.
--001a11c22780ff2b3704e3d3a3a3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 13 August 2013 15:45, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>I don't see th=
e problem. std::stringstream already takes an allocator. And, much like eve=
ry other standard library container, you can only move from a type that use=
s the same allocator type that you use, and the move constructor will presu=
mably copy that allocator in.<br>
</div></div></blockquote><div><br></div><div>The move constructor can also =
move the allocator in. ;)<br><br></div></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c22780ff2b3704e3d3a3a3--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 13 Aug 2013 05:50:00 -0700 (PDT)
Raw View
------=_Part_3093_20888838.1376398200999
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 12, 2013 8:57:56 AM UTC-7, Ville Voutilainen wrote:
>
> On 12 August 2013 17:52, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>> If I need the speed of moving the string, the code will only be portable
>>> to implementations actually supporting this.
>>>
>>
>> That requires a very specific definition of "portable". Portability is
>> usually applied to *functioning*, not how fast it goes.
>>
>>
> In c++, it has for a very long time been a fundamental design principle
> that performance is portable,
> as far as possible. That's why the standard specifies the complexities of
> eg. container operations
> in such detail as it does. That's of course not completely equivalent to
> "how fast it goes", and
> we try to avoid limiting implementation freedom, but portable performance
> has always been
> a goal of c++.
>
>
And yet, there are a lot of things around the implementaiton of
std::basic_string that are *not* portable.** For example, small string
optimization is quite common, and allowed by the spec, but you can't rely
on it.
Indeed, the fact that SSO exists basically means you can't *know* that
moving from a basic_string into a basic_stringbuf can move the data; it may
have to copy it. So it may be an O(N) operation (though only up to a fixed
N).
--
---
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/.
------=_Part_3093_20888838.1376398200999
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 12, 2013 8:57:56 AM UTC-7, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">On 12 August 2013 17:52, Nicol Bolas <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"6KsHH09mfrcJ">jmck...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div>If I need the speed of moving the string, the code will only be portab=
le=20
<br>to implementations actually supporting this.
<br></div></blockquote><div><br>That requires a very specific definition of=
"portable". Portability is usually applied to <i>functioning</i>, not how =
fast it goes.<br><br></div></div></blockquote><div><br></div>
<div>In c++, it has for a very long time been a fundamental design principl=
e that performance is portable,<br>as far as possible. That's why the stand=
ard specifies the complexities of eg. container operations<br></div>
<div>in such detail as it does. That's of course not completely equivalent =
to "how fast it goes", and<br>we try to avoid limiting implementation freed=
om, but portable performance has always been<br>a goal of c++. <br>
</div></div><br></div></div></blockquote><div><br>And yet, there are a lot =
of things around the implementaiton of std::basic_string that are <i>not</i=
> portable.<i></i> For example, small string optimization is quite common, =
and allowed by the spec, but you can't rely on it.<br><br>Indeed, the fact =
that SSO exists basically means you can't <i>know</i> that moving from a ba=
sic_string into a basic_stringbuf can move the data; it may have to copy it=
.. So it may be an O(N) operation (though only up to a fixed N).<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_3093_20888838.1376398200999--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 13 Aug 2013 15:54:16 +0300
Raw View
--047d7bd766de118ffa04e3d3bdae
Content-Type: text/plain; charset=ISO-8859-1
On 13 August 2013 15:50, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> And yet, there are a lot of things around the implementaiton of
> std::basic_string that are *not* portable.** For example, small string
> optimization is quite common, and allowed by the spec, but you can't rely
> on it.
>
> Indeed, the fact that SSO exists basically means you can't *know* that
> moving from a basic_string into a basic_stringbuf can move the data; it may
> have to copy it. So it may be an O(N) operation (though only up to a fixed
> N).
>
>
>
>
Well, that certainly sounds like we can't guarantee the
string<->stringstream move to be anything but O(N).
We can say that it's less complex than that in optimal cases, but that
doesn't serve much purpose since
implementations are already allowed to do things with less complexity than
required, if they can.
--
---
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/.
--047d7bd766de118ffa04e3d3bdae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 13 August 2013 15:50, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br>And yet, there=
are a lot of things around the implementaiton of std::basic_string that ar=
e <i>not</i> portable.<i></i> For example, small string optimization is qui=
te common, and allowed by the spec, but you can't rely on it.<br>
<br>Indeed, the fact that SSO exists basically means you can't <i>know<=
/i> that moving from a basic_string into a basic_stringbuf can move the dat=
a; it may have to copy it. So it may be an O(N) operation (though only up t=
o a fixed N).<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Well, that certainly s=
ounds like we can't guarantee the string<->stringstream move to b=
e anything but O(N).<br></div><div>We can say that it's less complex th=
an that in optimal cases, but that doesn't serve much purpose since<br>
implementations are already allowed to do things with less complexity than =
required, if they can.<br></div></div><br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bd766de118ffa04e3d3bdae--
.
Author: Bo Persson <bop@gmb.dk>
Date: Tue, 13 Aug 2013 15:19:00 +0200
Raw View
--Apple-Mail-6ADF6ACA-8477-4C74-BE8E-8198385EC2B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
13 aug 2013 kl. 14:45 skrev Nicol Bolas <jmckesson@gmail.com>:
> On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson wrote:
> Jeffrey Yasskin skrev 2013-08-12 21:27:=20
> > On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <b...@gmb.dk> wrote:=20
> >> Chris Jefferson skrev 2013-08-12 16:51:=20
> >>>=20
> >>>=20
> >>> There may well no can of worms at all. But (for example) perhaps some=
=20
> >>> implementations of streambuf use a memory layout which is not identic=
al=20
> >>> to std::string. I'd personally love to see an implementation just to=
=20
> >>> check however. My only worry is if some implementations do not use th=
e=20
> >>> same memory layout for std::string and std::stringbuf.=20
> >>=20
> >>=20
> >> VC++ is one example where stringbuf stores an array of characters and =
not a=20
> >> std::string.=20
> >=20
> > FWIW, since they're both part of the standard library, moving a string=
=20
> > into a stringbuf could pillage the string's internal char[] without=20
> > needing to store a string internally. Only chunked implementations=20
> > with the chunk length stored at the beginning of the chunk would have=
=20
> > a problem.=20
> >=20
>=20
> The potential problem I see is that you have to keep track of how the=20
> internal buffer was allocated, so it can be properly deallocated later.=
=20
> That involves the allocator used (if any!) and possibly C++11=20
> allocator_traits, if those apply to streambufs.=20
>=20
> You can't just take the buffer and run. :-)=20
>=20
>=20
> Bo Persson=20
>=20
> I don't see the problem. std::stringstream already takes an allocator. An=
d, much like every other standard library container, you can only move from=
a type that uses the same allocator type that you use, and the move constr=
uctor will presumably copy that allocator in.
>=20
> It's really no different than std::basic_string's move constructor. You m=
ost certainly can "take the buffer and run".
But it IS different in that the stringbuf currently isn't required to use t=
he allocator (or to store a std::string internally).=20
And currently the stringbuf isn't a container. We would have to change that=
, not just add a new member function.
Bo Persson
--=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/.
--Apple-Mail-6ADF6ACA-8477-4C74-BE8E-8198385EC2B0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head></head><body bgcolor=3D"#FFFFFF"><div><br><br>13 aug 2013 kl. 1=
4:45 skrev Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckesson=
@gmail.com</a>>:<br><br></div><div></div><blockquote type=3D"cite"><div>=
<div dir=3D"ltr">On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Jeffrey Yasskin skrev 201=
3-08-12 21:27:
<br>> On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"q6d1eVEc94wJ">b...@gmb.dk=
</a>> wrote:
<br>>> Chris Jefferson skrev 2013-08-12 16:51:
<br>>>>
<br>>>>
<br>>>> There may well no can of worms at all. But (for example) p=
erhaps some
<br>>>> implementations of streambuf use a memory layout which is =
not identical
<br>>>> to std::string. I'd personally love to see an implementati=
on just to
<br>>>> check however. My only worry is if some implementations do=
not use the
<br>>>> same memory layout for std::string and std::stringbuf.
<br>>>
<br>>>
<br>>> VC++ is one example where stringbuf stores an array of charact=
ers and not a
<br>>> std::string.
<br>>
<br>> FWIW, since they're both part of the standard library, moving a st=
ring
<br>> into a stringbuf could pillage the string's internal char[] withou=
t
<br>> needing to store a string internally. Only chunked implementations
<br>> with the chunk length stored at the beginning of the chunk would h=
ave
<br>> a problem.
<br>>
<br>
<br>The potential problem I see is that you have to keep track of how the=
=20
<br>internal buffer was allocated, so it can be properly deallocated later.=
=20
<br>That involves the allocator used (if any!) and possibly C++11=20
<br>allocator_traits, if those apply to streambufs.
<br>
<br>You can't just take the buffer and run. :-)
<br>
<br>
<br>Bo Persson
<br></blockquote><div><br>I don't see the problem. std::stringstream alread=
y takes an allocator. And, much like every other standard library container=
, you can only move from a type that uses the same allocator type that you =
use, and the move constructor will presumably copy that allocator in.<br><b=
r>It's really no different than std::basic_string's move constructor. You m=
ost certainly can "take the buffer and run".<br></div></div></div></blockqu=
ote><br><div>But it IS different in that the stringbuf currently isn't requ=
ired to use the allocator (or to store a std::string internally). </di=
v><div><br></div><div>And currently the stringbuf isn't a container. We wou=
ld have to change that, not just add a new member function.</div><div><br><=
/div><div><br></div><div>Bo Persson</div></body></html>
<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--Apple-Mail-6ADF6ACA-8477-4C74-BE8E-8198385EC2B0--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 13 Aug 2013 11:18:59 -0400
Raw View
On Aug 13, 2013, at 9:19 AM, Bo Persson <bop@gmb.dk> wrote:
> But it IS different in that the stringbuf currently isn't required to use=
the allocator (or to store a std::string internally).=20
>=20
Yeah, I was noticing this too. Technically the allocator parameter on basi=
c_stringbuf is "semantics free" according to the current standard. We all =
know what it is supposed to do. But in the standard it is just decoration =
right now. It has apparently been that way ever since C++98.
At the very least we should specify what that template parameter is suppose=
d to do.
Howard
--=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/.
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Tue, 13 Aug 2013 20:41:57 +0200
Raw View
On Tue, Aug 13, 2013 at 03:19:00PM +0200, Bo Persson wrote:
>
>
> 13 aug 2013 kl. 14:45 skrev Nicol Bolas <jmckesson@gmail.com>:
>
> > On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson wrote:
> > Jeffrey Yasskin skrev 2013-08-12 21:27:
> > > On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <b...@gmb.dk> wrote:
> > >> Chris Jefferson skrev 2013-08-12 16:51:
> > >>>
> > >>>
> >
> > It's really no different than std::basic_string's move constructor. You most certainly can "take the buffer and run".
>
> But it IS different in that the stringbuf currently isn't required to use the allocator (or to store a std::string internally).
>
> And currently the stringbuf isn't a container. We would have to change that, not just add a new member function.
>
This debate have made me wonder if an istream decorator that you can put on any
sequence of characters is a useful idea?
/MF
--
---
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/.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Tue, 13 Aug 2013 16:06:05 -0700 (PDT)
Raw View
------=_Part_1341_14225481.1376435165906
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. augusztus 13., kedd 14:50:00 UTC+2 id=F5pontban Nicol Bolas a=20
k=F6vetkez=F5t =EDrta:
>
> On Monday, August 12, 2013 8:57:56 AM UTC-7, Ville Voutilainen wrote:
>>
>> On 12 August 2013 17:52, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>>
>>> If I need the speed of moving the string, the code will only be portabl=
e=20
>>>> to implementations actually supporting this.=20
>>>>
>>>
>>> That requires a very specific definition of "portable". Portability is=
=20
>>> usually applied to *functioning*, not how fast it goes.
>>>
>>>
>> In c++, it has for a very long time been a fundamental design principle=
=20
>> that performance is portable,
>> as far as possible. That's why the standard specifies the complexities o=
f=20
>> eg. container operations
>> in such detail as it does. That's of course not completely equivalent to=
=20
>> "how fast it goes", and
>> we try to avoid limiting implementation freedom, but portable performanc=
e=20
>> has always been
>> a goal of c++.=20
>>
>>
> And yet, there are a lot of things around the implementaiton of=20
> std::basic_string that are *not* portable.** For example, small string=20
> optimization is quite common, and allowed by the spec, but you can't rely=
=20
> on it.
>
> Indeed, the fact that SSO exists basically means you can't *know* that=20
> moving from a basic_string into a basic_stringbuf can move the data; it m=
ay=20
> have to copy it. So it may be an O(N) operation (though only up to a fixe=
d=20
> N).
>
By definition, "O(N) up to a fixed N, O(1) after" is O(1)...
Sure, moving out of a SSO-string is more operation than just setting some=
=20
pointers correctly, but you do have a constant worst case for it, copy on=
=20
the other hand will never have.
Regards, Robert
--=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/.
------=_Part_1341_14225481.1376435165906
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2013. augusztus 13., kedd 14:50:00 UTC+2 id=F5pont=
ban Nicol Bolas a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">On Monday, August 12, 2013 8:57:56 AM UTC-7, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On 12 August 2013 17:52, Nicol Bolas <sp=
an dir=3D"ltr"><<a>jmck...@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div>If I need the speed of moving the string, the code will only be portab=
le=20
<br>to implementations actually supporting this.
<br></div></blockquote><div><br>That requires a very specific definition of=
"portable". Portability is usually applied to <i>functioning</i>, not how =
fast it goes.<br><br></div></div></blockquote><div><br></div>
<div>In c++, it has for a very long time been a fundamental design principl=
e that performance is portable,<br>as far as possible. That's why the stand=
ard specifies the complexities of eg. container operations<br></div>
<div>in such detail as it does. That's of course not completely equivalent =
to "how fast it goes", and<br>we try to avoid limiting implementation freed=
om, but portable performance has always been<br>a goal of c++. <br>
</div></div><br></div></div></blockquote><div><br>And yet, there are a lot =
of things around the implementaiton of std::basic_string that are <i>not</i=
> portable.<i></i> For example, small string optimization is quite common, =
and allowed by the spec, but you can't rely on it.<br><br>Indeed, the fact =
that SSO exists basically means you can't <i>know</i> that moving from a ba=
sic_string into a basic_stringbuf can move the data; it may have to copy it=
.. So it may be an O(N) operation (though only up to a fixed N).<br></div></=
div></blockquote><div><br>By definition, "O(N) up to a fixed N, O(1) after"=
is O(1)...<br>Sure, moving out of a SSO-string is more operation than just=
setting some pointers correctly, but you do have a constant worst case for=
it, copy on the other hand will never have.<br><br>Regards, Robert<br></di=
v></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1341_14225481.1376435165906--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 13 Aug 2013 18:04:35 -0700 (PDT)
Raw View
------=_Part_3855_29057342.1376442275409
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 13, 2013 6:19:00 AM UTC-7, Bo Persson wrote:
>
> 13 aug 2013 kl. 14:45 skrev Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
> On Tuesday, August 13, 2013 3:58:49 AM UTC-7, Bo Persson wrote:
>>
>> Jeffrey Yasskin skrev 2013-08-12 21:27:
>> > On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <b...@gmb.dk> wrote:
>> >> Chris Jefferson skrev 2013-08-12 16:51:
>> >>>
>> >>>
>> >>> There may well no can of worms at all. But (for example) perhaps some
>> >>> implementations of streambuf use a memory layout which is not
>> identical
>> >>> to std::string. I'd personally love to see an implementation just to
>> >>> check however. My only worry is if some implementations do not use
>> the
>> >>> same memory layout for std::string and std::stringbuf.
>> >>
>> >>
>> >> VC++ is one example where stringbuf stores an array of characters and
>> not a
>> >> std::string.
>> >
>> > FWIW, since they're both part of the standard library, moving a string
>> > into a stringbuf could pillage the string's internal char[] without
>> > needing to store a string internally. Only chunked implementations
>> > with the chunk length stored at the beginning of the chunk would have
>> > a problem.
>> >
>>
>> The potential problem I see is that you have to keep track of how the
>> internal buffer was allocated, so it can be properly deallocated later.
>> That involves the allocator used (if any!) and possibly C++11
>> allocator_traits, if those apply to streambufs.
>>
>> You can't just take the buffer and run. :-)
>>
>>
>> Bo Persson
>>
>
> I don't see the problem. std::stringstream already takes an allocator.
> And, much like every other standard library container, you can only move
> from a type that uses the same allocator type that you use, and the move
> constructor will presumably copy that allocator in.
>
> It's really no different than std::basic_string's move constructor. You
> most certainly can "take the buffer and run".
>
>
> But it IS different in that the stringbuf currently isn't required to use
> the allocator (or to store a std::string internally).
>
Wait, *what?* What's the point of having an allocator if it's allowed to
ignore it?
> And currently the stringbuf isn't a container. We would have to change
> that, not just add a new member function.
>
It doesn't need to be a container. It just needs to be able to have a
basic_string moved into it and moved out of it. It needs to respect the
allocator and so forth.
I don't see the implementation burden on requiring something that quite
frankly should have been required all along (using the allocator).
--
---
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/.
------=_Part_3855_29057342.1376442275409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 13, 2013 6:19:00 AM UTC-7, Bo Persson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF">=
<div>13 aug 2013 kl. 14:45 skrev Nicol Bolas <<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"DL7rw-fJbq0J">jmck...@gmail.com</a=
>>:<br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">On Tuesday,=
August 13, 2013 3:58:49 AM UTC-7, Bo Persson wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Jeffrey Yasskin skrev 2013-08-12 21:27:
<br>> On Mon, Aug 12, 2013 at 11:31 AM, Bo Persson <<a>b...@gmb.dk</a=
>> wrote:
<br>>> Chris Jefferson skrev 2013-08-12 16:51:
<br>>>>
<br>>>>
<br>>>> There may well no can of worms at all. But (for example) p=
erhaps some
<br>>>> implementations of streambuf use a memory layout which is =
not identical
<br>>>> to std::string. I'd personally love to see an implementati=
on just to
<br>>>> check however. My only worry is if some implementations do=
not use the
<br>>>> same memory layout for std::string and std::stringbuf.
<br>>>
<br>>>
<br>>> VC++ is one example where stringbuf stores an array of charact=
ers and not a
<br>>> std::string.
<br>>
<br>> FWIW, since they're both part of the standard library, moving a st=
ring
<br>> into a stringbuf could pillage the string's internal char[] withou=
t
<br>> needing to store a string internally. Only chunked implementations
<br>> with the chunk length stored at the beginning of the chunk would h=
ave
<br>> a problem.
<br>>
<br>
<br>The potential problem I see is that you have to keep track of how the=
=20
<br>internal buffer was allocated, so it can be properly deallocated later.=
=20
<br>That involves the allocator used (if any!) and possibly C++11=20
<br>allocator_traits, if those apply to streambufs.
<br>
<br>You can't just take the buffer and run. :-)
<br>
<br>
<br>Bo Persson
<br></blockquote><div><br>I don't see the problem. std::stringstream alread=
y takes an allocator. And, much like every other standard library container=
, you can only move from a type that uses the same allocator type that you =
use, and the move constructor will presumably copy that allocator in.<br><b=
r>It's really no different than std::basic_string's move constructor. You m=
ost certainly can "take the buffer and run".<br></div></div></div></blockqu=
ote><br><div>But it IS different in that the stringbuf currently isn't requ=
ired to use the allocator (or to store a std::string internally).</div></di=
v></blockquote><div><br>Wait, <i>what?</i> What's the point of having an al=
locator if it's allowed to ignore it?<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;"><div bgcolor=3D"#FFFFFF"><div>And currently the=
stringbuf isn't a container. We would have to change that, not just add a =
new member function.</div></div></blockquote><div><br>It doesn't need to be=
a container. It just needs to be able to have a basic_string moved into it=
and moved out of it. It needs to respect the allocator and so forth.<br><b=
r>I don't see the implementation burden on requiring something that quite f=
rankly should have been required all along (using the allocator).<br></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_3855_29057342.1376442275409--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 13 Aug 2013 20:05:05 -0700
Raw View
--nextPart2952518.u3V3DlJktT
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
On ter=E7a-feira, 13 de agosto de 2013 16:06:05, R=F3bert D=E1vid wrote=
:
> By definition, "O(N) up to a fixed N, O(1) after" is O(1)...
> Sure, moving out of a SSO-string is more operation than just setting =
some=20
> pointers correctly, but you do have a constant worst case for it, cop=
y on=20
> the other hand will never have.
Moving an SSO will involve copying roughly as many bytes as you'd have =
to copy=20
anyway to set the pointers during the move operation, and resetting rou=
ghly as=20
many bytes in the moved-from string.
I've just looked at the libc++ implementation and it isn't "roughly": i=
t's=20
exactly as many.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart2952518.u3V3DlJktT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSCvPwM/XwBW70U1gRAiDuAKCZerVqGGNelNAKispcykkpWa1jDgCgwYLA
p05+hmLOzxzS1pYPL+KC7NU=
=dbAX
-----END PGP SIGNATURE-----
--nextPart2952518.u3V3DlJktT--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Tue, 13 Aug 2013 23:13:48 -0400
Raw View
On Aug 13, 2013, at 11:05 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On ter=E7a-feira, 13 de agosto de 2013 16:06:05, R=F3bert D=E1vid wrote:
>> By definition, "O(N) up to a fixed N, O(1) after" is O(1)...
>> Sure, moving out of a SSO-string is more operation than just setting som=
e=20
>> pointers correctly, but you do have a constant worst case for it, copy o=
n=20
>> the other hand will never have.
>=20
> Moving an SSO will involve copying roughly as many bytes as you'd have to=
copy=20
> anyway to set the pointers during the move operation, and resetting rough=
ly as=20
> many bytes in the moved-from string.
>=20
> I've just looked at the libc++ implementation and it isn't "roughly": it'=
s=20
> exactly as many.
<nod> Designed with move semantics in mind, optimizing the move constructor=
over most everything else. Terrified of a large SSO buffer. Ymmv. :-)
Howard
--=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/.
.
Author: Bo Persson <bop@gmb.dk>
Date: Wed, 14 Aug 2013 08:28:43 +0200
Raw View
Nicol Bolas skrev 2013-08-14 03:04:
> On Tuesday, August 13, 2013 6:19:00 AM UTC-7, Bo Persson wrote:
>
> 13 aug 2013 kl. 14:45 skrev Nicol Bolas <jmck...@gmail.com
>>
>> I don't see the problem. std::stringstream already takes an
>> allocator. And, much like every other standard library container,
>> you can only move from a type that uses the same allocator type
>> that you use, and the move constructor will presumably copy that
>> allocator in.
>>
>> It's really no different than std::basic_string's move
>> constructor. You most certainly can "take the buffer and run".
>
> But it IS different in that the stringbuf currently isn't required
> to use the allocator (or to store a std::string internally).
>
>
> Wait, /what?/ What's the point of having an allocator if it's allowed to
> ignore it?
>
I didn't write the standard (just reading it :-), but can't find
anywhere that the stringbuf is given an allocator. It just *could* be
that the template parameter is used to give the correct string type for
passing data in and out.
Or it could have be so obvious that nobody thought it should been
spelled out?
> And currently the stringbuf isn't a container. We would have to
> change that, not just add a new member function.
>
>
> It doesn't need to be a container. It just needs to be able to have a
> basic_string moved into it and moved out of it. It needs to respect the
> allocator and so forth.
>
Being a container (or not) affects how allocators are handled for things
like move assignment and swap. The allocator_traits member
propagate_on_container_swap would likely only have an effect if the
stringbuf is a container (or holds one).
Bo Persson
--
---
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/.
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Wed, 14 Aug 2013 15:51:59 -0700 (PDT)
Raw View
------=_Part_2855_2986412.1376520719538
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. augusztus 14., szerda 5:05:05 UTC+2 id=F5pontban Thiago Macieira a=20
k=F6vetkez=F5t =EDrta:
>
> Moving an SSO will involve copying roughly as many bytes as you'd have to=
=20
> copy=20
> anyway to set the pointers during the move operation, and resetting=20
> roughly as=20
> many bytes in the moved-from string.=20
>
> I've just looked at the libc++ implementation and it isn't "roughly": it'=
s=20
> exactly as many.=20
>
You still have to check first if it's small, thus the "more operation than=
=20
just setting pointers".
Anyway, my point is that SSO does not stop O(1) moves between=20
string<->stringbuf/stringstream. Go take the buffer with the allocator and=
=20
run.
Regards, Robert
--=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/.
------=_Part_2855_2986412.1376520719538
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>2013. augusztus 14., szerda 5:05:05 UTC+2 id=F5pon=
tban Thiago Macieira a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">Moving an SSO will involve copying roughly as many bytes as =
you'd have to copy=20
<br>anyway to set the pointers during the move operation, and resetting rou=
ghly as=20
<br>many bytes in the moved-from string.
<br>
<br>I've just looked at the libc++ implementation and it isn't "roughly": i=
t's=20
<br>exactly as many.
<br></blockquote><div><br>You still have to check first if it's small, thus=
the "more operation than just setting pointers".<br>Anyway, my point is th=
at SSO does not stop O(1) moves between string<->stringbuf/stringstre=
am. Go take the buffer with the allocator and run.<br><br>Regards, Robert</=
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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2855_2986412.1376520719538--
.
Author: Howard Hinnant <howard.hinnant@gmail.com>
Date: Wed, 14 Aug 2013 19:40:58 -0400
Raw View
On Aug 14, 2013, at 6:51 PM, R=C3=B3bert D=C3=A1vid <lrdxgm@gmail.com> wrot=
e:
>=20
>=20
> 2013. augusztus 14., szerda 5:05:05 UTC+2 id=C5=91pontban Thiago Macieira=
a k=C3=B6vetkez=C5=91t =C3=ADrta:
>> Moving an SSO will involve copying roughly as many bytes as you'd have t=
o copy=20
>> anyway to set the pointers during the move operation, and resetting roug=
hly as=20
>> many bytes in the moved-from string.=20
>>=20
>> I've just looked at the libc++ implementation and it isn't "roughly": it=
's=20
>> exactly as many.=20
>>=20
> You still have to check first if it's small, thus the "more operation tha=
n just setting pointers".
> Anyway, my point is that SSO does not stop O(1) moves between string<->st=
ringbuf/stringstream. Go take the buffer with the allocator and run.
I agree with Robert's point.
But I can't help but point out some technical stuff in the libc++ implement=
ation of std::string. :-)
It depends on whether we are talking about the move constructor, or the mov=
e assignment operator as to whether or not the string has to test the short=
/long bit. The move assignment operator currently has to, mainly to clear(=
) the lhs prior to the move assignment.
But the move ctor is spectacularly efficient. It does no branching at all =
(unless in debug mode which we will ignore):
template <class _CharT, class _Traits, class _Allocator>
_LIBCPP_INLINE_VISIBILITY inline
basic_string<_CharT, _Traits, _Allocator>::basic_string(basic_string&& __st=
r)
_NOEXCEPT_(is_nothrow_move_constructible<allocator_type>::value)
: __r_(_VSTD::move(__str.__r_))
{
__str.__zero();
}
The construction of __r_ does 3 word-sized loads and 3 word-sized stores.
__str.__zero() does 3 word-sized stores.
That's it. 9 non-branching operations. Compiling this:
alignas (std::string) char global[sizeof(std::string)];
void
test_string_move_ctor(std::string& s)
{
::new(global) std::string(std::move(s));
};
at -O3 yields:
.globl __Z21test_string_move_ctorRNSt3__112basic_stringIcNS_11char_traitsI=
cEENS_9allocatorIcEEEE
.align 4, 0x90
__Z21test_string_move_ctorRNSt3__112basic_stringIcNS_11char_traitsIcEENS_9a=
llocatorIcEEEE: ## @_Z21test_string_move_ctorRNSt3__112basic_stringIcNS_11c=
har_traitsIcEENS_9allocatorIcEEEE
.cfi_startproc
## BB#0:
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
movq 16(%rdi), %rax
movq %rax, _global+16(%rip)
movq (%rdi), %rax
movq 8(%rdi), %rcx
movq %rcx, _global+8(%rip)
movq %rax, _global(%rip)
movq $0, 16(%rdi)
movq $0, 8(%rdi)
movq $0, (%rdi)
popq %rbp
ret
.cfi_endproc
Move assignment (assuming std::allocator) is roughly the above preceded by =
dancing around to get the lhs down to a default constructed state prior to =
doing these 3 loads and 6 stores. Move assignment can devolve into a full =
memcpy of the entire data buffer (short or long) for some allocators (but n=
ever for std::allocator).
Moving a string into a basic_stringbuf will involve a string move assignmen=
t. Moving a string out of a basic_stringbuf will involve a string move con=
struction.
Howard
--=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/.
.