This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: protected alloca class for malloc fallback
On Thu, Aug 11, 2016 at 02:03:29AM +0900, Oleg Endo wrote:
> On Tue, 2016-08-09 at 13:41 -0400, Trevor Saunders wrote:
>
> > If what you want is the ability to put the buffer on the stack
> > instead of the heap then I think a stack_string class that
> > interoperates with your string class is the thing you want.
>
> I'd avoid a separate stack_string class. Instead use a linear
> allocator with storage allocated on the stack, e.g.:
>
> typedef std::basic_string<char, std::char_traits<char>,
> linear_allocator<char>
> my_tmp_string;
>
> void bleh (int foo)
> {
> linear_allocator<char> buffer (alloca (1024), 1024);
>
> tmp_string aaa (buffer);
> aaa += "test";
> aaa += "moon";
> ...
>
> // what happens when "buffer" runs out of space?
> // throw? switch to heap alloc? ...
> }
>
>
> >
> > I don't really see anything wrong with a string class being a really
> > fancy smart pointer that has a bunch of useful string stuff on it.
>
>
> That's what std::string basically is?
sure, but I'm saying it does that job baddly.
> > As for operator == I'd be fairly ok with that, other than it hiding
> > a O(N) operation in ==.
>
> Yes, it makes it more difficult to carry out algorithm complexity
> analysis using grep...
>
>
> > Regretably necessary sure, but I'm not sure its funny.
>
> Hence the quotes.
>
> > The first big problem with using the stl is that the subset available
> > in C++98 isn't that great, you could maybe hack up libstdc++ so that
> > you can use newer types just without the bits that use newer language
> > features, but that would take some work.
>
> Or just wait until people have agreed to switch to C++11 or C++14. I
> don't think in practice anybody uses an C++11-incapable GCC to build a
> newer GCC these days.
I'm pretty sure they do, I've seen patches for 4.1 and 4.3 go in this
cycle, and rval refs didn't work until 4.4 and that was to an older
version of the spec. Anyways people apparently use compilers other than
gcc to build gcc, and I'm prepared to believe some of the proprietery
compilers on ancient unix variants don't support C++11.
> > The other big problem is that the stl is often too general, and tries
> > to be too simple. std::string is actually a good example of both of
> > those problems. There's really no reason it should use size_t
> > instead of uint32_t for the string length / capacity.
>
> Yes, some of the things in the STL are collections of compromises for
> general-purpose usage. If you're doing something extra fancy, most
> likely you can outperform the generic STL implementation. But very
> often it's actually not needed.
Well, I'd say the compromises made in std::string make it pretty
terrible for general purpose use accept where perf and memory doesn't
matter at all.
std::vector isn't very great size wise either, imho the size / capacity
fields would be much better put in the buffer than in the struct itself,
to save 2 * sizeof (void *) in sizeof std::vector.
I haven't looked at other stl datastructures that much, but those two
examples don't fill me with confidence :/
> > It would also be a lot better if it had separate types for strings
> > where you want an internal buffer or don't.
>
> Using custom allocators is one way. For example ...
>
> template <unsigned int BufferSize> struct linear_allocator_with_buffer;
>
> template <unsigned int BufferSize>
> using stack_string =
> std::basic_string<char, std::char_traits<char>,
> linear_allocator_with_buffer<BufferSize>>;
that *is* a different type than std::string with the default template
arguments.
> But then ...
>
> stack_string<32> a = "a";
> stack_string<64> b = "b";
>
> b += a;
>
> ... will not work because they are different types.
>
> One drawback of using custom allocators for that kind of thing is being
> unable to pass the above stack_string to a function that takes a "const
> std::string&" because they differ in template parameters. But that's
> where std::string_view comes in.
or just having your stack_string type convert to the normal string type
so that you can pass mutable references.
Trev
>
>
> Cheers,
> Oleg