Re: [boost] [string] proposal
----- "Nevin Liber" <nevin@eviloverlord.com> wrote :
On 21 January 2011 11:56, Dean Michael Berris <mikhailberis@gmail.com>wrote:
No changing arbitrary content in the string. Concatenation is a process of creating new strings.
Ultimately the underlying string should be efficient
Please describe how you are going to make this efficient, if concatenation effectively requires an allocation (once past the small string optimization) and a copy.
Isn't rope worth a try here ? Ivan.
On Fri, Jan 21, 2011 at 5:00 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
----- "Nevin Liber" <nevin@eviloverlord.com> wrote :
On 21 January 2011 11:56, Dean Michael Berris <mikhailberis@gmail.com>wrote:
No changing arbitrary content in the string. Concatenation is a process of creating new strings.
Ultimately the underlying string should be efficient
Please describe how you are going to make this efficient, if concatenation effectively requires an allocation (once past the small string optimization) and a copy.
Isn't rope worth a try here ?
Absolutely! <shameless plug> The author of rope is giving the keynote at BoostCon this year. </shamelses> -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Mon, Jan 24, 2011 at 7:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Fri, Jan 21, 2011 at 5:00 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
----- "Nevin Liber" <nevin@eviloverlord.com> wrote :
On 21 January 2011 11:56, Dean Michael Berris <mikhailberis@gmail.com>wrote:
No changing arbitrary content in the string. Concatenation is a process of creating new strings.
Ultimately the underlying string should be efficient
Please describe how you are going to make this efficient, if concatenation effectively requires an allocation (once past the small string optimization) and a copy.
Isn't rope worth a try here ?
Absolutely!
+1 -- now if there was just a rope class that is part of the standard (and not an SGI extension) then it should definitely be a good candidate for how a string can efficiently store data without requiring linear memory complexity to the length of the text. :)
<shameless plug> The author of rope is giving the keynote at BoostCon this year. </shamelses>
Coolness. :) -- Dean Michael Berris about.me/deanberris
On Tue, Jan 25, 2011 at 5:12 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Mon, Jan 24, 2011 at 7:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Fri, Jan 21, 2011 at 5:00 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
----- "Nevin Liber" <nevin@eviloverlord.com> wrote :
Isn't rope worth a try here ?
Absolutely!
+1 -- now if there was just a rope class that is part of the standard (and not an SGI extension) then it should definitely be a good candidate for how a string can efficiently store data without requiring linear memory complexity to the length of the text. :)
<shameless plug> The author of rope is giving the keynote at BoostCon this year. </shamelses>
Coolness. :)
Some years ago, when I first discovered the SGI's implementation of STL and its rope class my first thought was 'Cool'. Then I wrote a couple of (in the hindsight) rather synthetic simple programs exploiting those cool features of rope and it outperformed the std::string almost in every one of them. Then I tried to use it in a more real world scenarios, like for example passing them to WINAPI. Then I returned to std::string :) It would be awesome if for example (CryptoAPI's) CryptHashData accepted a rope or a pair of generic iterators and could exploit the coolness of its implementation but it does not. What it wants is a BYTE* and length, which pretty much disqualifies any innovative implementations of string, unless we want to dump all legacy APIs and re-implement them. I don't want to say that the rope is useless, but it is a very special case of string. I would like to see the new string that comes out of this effort to be adopted by new and is possible by existing libraries and use them in their APIs, not just in the plumbing. Matus
Le mercredi 26 janvier 2011 à 09:29 +0100, Matus Chochlik a écrit :
On Tue, Jan 25, 2011 at 5:12 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Mon, Jan 24, 2011 at 7:36 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Fri, Jan 21, 2011 at 5:00 PM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
----- "Nevin Liber" <nevin@eviloverlord.com> wrote :
Isn't rope worth a try here ?
Absolutely!
+1 -- now if there was just a rope class that is part of the standard (and not an SGI extension) then it should definitely be a good candidate for how a string can efficiently store data without requiring linear memory complexity to the length of the text. :)
<shameless plug> The author of rope is giving the keynote at BoostCon this year. </shamelses>
Coolness. :)
Some years ago, when I first discovered the SGI's implementation of STL and its rope class my first thought was 'Cool'. Then I wrote a couple of (in the hindsight) rather synthetic simple programs exploiting those cool features of rope and it outperformed the std::string almost in every one of them.
Then I tried to use it in a more real world scenarios, like for example passing them to WINAPI. Then I returned to std::string :)
[ disclaimer: extremely premature implementation detail :) ] I don't know about SGI's rope internals. My understanding of rope in the real world use case you mention is that it does lazy "c_str" evaluation. Now, if you only give verbatim back to the OS a string it gave you, there is no reason for c_str to be slow. If you did string manipulation, then you'll pay for this at c_str call, but you had to pay for this eventually. I see no penalty here. To illustrate this, I understand an immutable rope as roughly : boost::make_recursive_variant < boost::shared_ptr <const std::basic_string <code_unit_type>>, boost::shared_ptr <const std::list <boost::recursive_variant_>>
::type
Here c_str should be trivial in basic_string case. Ivan.
On Wed, Jan 26, 2011 at 11:24 AM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
Le mercredi 26 janvier 2011 à 09:29 +0100, Matus Chochlik a écrit :
On Tue, Jan 25, 2011 at 5:12 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:
Some years ago, when I first discovered the SGI's implementation of STL and its rope class my first thought was 'Cool'. Then I wrote a couple of (in the hindsight) rather synthetic simple programs exploiting those cool features of rope and it outperformed the std::string almost in every one of them.
Then I tried to use it in a more real world scenarios, like for example passing them to WINAPI. Then I returned to std::string :)
I didn't say that the rope has been visibly less efficient in this case, but the point is that it was not visibly more efficient than string and at the time it was not standard. I vaguely remember having some trouble getting it working on Windows.
[ disclaimer: extremely premature implementation detail :) ]
I don't know about SGI's rope internals. My understanding of rope in the real world use case you mention is that it does lazy "c_str" evaluation. Now, if you only give verbatim back to the OS a string it gave you, there is no reason for c_str to be slow. If you did string manipulation, then you'll pay for this at c_str call, but you had to pay for this eventually. I see no penalty here.
To illustrate this, I understand an immutable rope as roughly :
boost::make_recursive_variant < boost::shared_ptr <const std::basic_string <code_unit_type>>, boost::shared_ptr <const std::list <boost::recursive_variant_>>
::type
Here c_str should be trivial in basic_string case.
Matus
participants (4)
-
Dave Abrahams -
Dean Michael Berris -
Ivan Le Lann -
Matus Chochlik