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 <sean.c.r...@gmail.com> wrote:

> 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_and_sharable(__len);
>  }
> }
>
> See the code for basic_string::append, for example.  Given that, it
> shouldn't be too ugly to do it from outside, but these things are
> always easy to mess up.
>
> Sean
>
>
>
> On Thu, Mar 4, 2010 at 1:09 PM, Jason Hsueh <jas...@google.com> wrote:
> > 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.
> >
> > On Thu, Mar 4, 2010 at 9:25 AM, Sean Rhea <sean.c.r...@gmail.com> wrote:
> >>
> >> 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.  Unfortunately,
> >> it isn't worth as much without STLStringResizeUninitialized, since you
> >> still end-up zero-filling the array (via resize) before writing into
> >> it.
> >>
> >> I understand why Google wouldn't want to include their version by
> >> default, as until the standard catches up it will by necessity be an
> >> ugly hack, but it would be great to have an implementation for my own
> >> use.
> >>
> >> As far as I can tell, vector<char> suffers from the same problem (no
> >> way to resize without zero-filling the array).
> >>
> >> Sean
> >> --
> >> "I refuse to accept the idea that the ‘isness’ of man’s present nature
> >> makes him morally incapable of reaching up for the eternal ‘oughtness’
> >> that forever confronts him." --MLK
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Protocol Buffers" group.
> >> To post to this group, send email to proto...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/protobuf?hl=en.
> >>
> >
> >
>
>
>
> --
> "I refuse to accept the idea that the ‘isness’ of man’s present nature
> makes him morally incapable of reaching up for the eternal ‘oughtness’
> that forever confronts him." --MLK
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to