On Mon, 2016-08-08 at 13:39 -0400, Trevor Saunders wrote:
> First sizeof std::string is 32 on x86_64, a char *, a size_t for the > length, and a 16 byte union of a size_t for allocated size and a 16 > byte buffer for short strings. I suppose some of this is required by > the C++ standard, I recommend checking what others have figured regarding that matter https://github.com/elliotgoodrich/SSO-23 > but I doubt we really need to care about strings longer than 2^32 in > gcc. If we put the length and allocated size in the buffer, > and have a separate class for stack allocated buffers I think we can > have a string that is just sizeof void *. This idea has one flaw in that it does not allow having objects by value. It essentially *requires* one to *always* allocate them on the heap via new/delete. Being able to store objects by value is useful in many situations. So if you do the above, the next logical step that will follow is a smart-pointer-like wrapper that allows value semantics. Because eventually somebody will want that operator == or operator < e.g. for associative containers. > > Second it would be useful performance wise to have a std::string_view > type class, but that is c++14 or 17? only so we'd need to import it > into gcc or something. http://en.cppreference.com/w/cpp/experimental/basic_string_view http://en.cppreference.com/w/cpp/string/basic_string_view It's "funny" that GCC contains a C++ stdlib implementation and so little is actually used by GCC itself. Cheers, Oleg
