On Thu, Mar 4, 2010 at 5:40 PM, Kenton Varda wrote:
> Sean: The Google-internal version of this function wouldn't work for you
> because we actually use an alternate (non-COW) string class. Also, our
> resize function violates aliasing rules, which may be a problem if you don't
> use -fno-stric
Sean: The Google-internal version of this function wouldn't work for you
because we actually use an alternate (non-COW) string class. Also, our
resize function violates aliasing rules, which may be a problem if you don't
use -fno-strict-aliasing.
On Thu, Mar 4, 2010 at 10:09 AM, Jason Hsueh wro
Well, the ugly part is that you'd need to somehow make sure that you can
actually get at _M_rep() from the outside - I assume that's private in the
std::string class. Otherwise, yea, I guess it wouldn't be too bad.
On Thu, Mar 4, 2010 at 10:43 AM, Sean Rhea wrote:
> Well, it's frustrating, as I
Well, it's frustrating, as I think it would be a really short function
if you could just edit basic_string.h|tcc directly:
basic_string::resize_uninitialized(size_type __len) {
if (__len <= this->length())
this->resize(__len);
else {
this->reserve(__len);
_M_rep()->_M_set_length_an
I don't know about any other implementations, but a word of caution: I think
that this would be especially complicated/hacky for gcc 4.3, which as I
recall switched to a copy-on-write implementation for std::string. You'd
probably want to make sure that the performance difference is really worth
it
All,
Does anyone have an implementation of STLStringResizeUninitialized
(see stl_util-inl.h) for gcc version 4.3.2?
The inability to use std::string as a zero-copy buffer has been a
long-running annoyance of mine, and I'm really excited by the
string_as_array function provided in stl_util-inl.h.
