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? > 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. > 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. > 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>>; 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. Cheers, Oleg