On Sun, Jan 30, 2011 at 1:00 AM, Ivan Le Lann <ivan.lelann@free.fr> wrote:
No matter the way you put it, you have one unnecessary allocation, because std::string has no move constructor from chain (yet). For people eventually throwing their boost::chain into std::string, we're basically killing all move/RVO optimizations.
That can be an issue that can also be mitigated by interning linearized strings. But that only amortizes the cost of linearization -- basically having a pointer to the linearized string part of the root or metadata block for each immutable string. I don't think though there's a way to get around the extra allocation to convert to std::string unfortunately. But the linearization can definitely be made amortized constant time. However, consider that the cost of copying a string is typically the same -- an extra allocation and an element-wise of memcpy.
Am I missing something?
Nope, the extra allocation will happen regardless, you're right. This is exacerbated when you have a huge chain that you want to linearize to a string and is then copied. For short <1 page's worth of strings, well I'm not too worried about the cost of an additional allocation. But when you want a string instead of a chain, you pay the price of conversion. Maybe someone else has a good idea how to address this? -- Dean Michael Berris about.me/deanberris