[llvm-commits] Twine/StringRef enhancements & usage

[Jordy Rose]

On Aug 25, 2011, at 11:20, David Blaikie wrote:

>> I think one of the reasons that I've seen SmallVectorImpl instead of
>> SmallVector or SmallString for a function parameter is in order to
>> avoid having the template parameter that specifies initial size, which
>> you would have to do otherwise.
>> 
> Yes - which is rather strange. Taking something that's not part of the type & binding it into the type... I don't really see the benefit there. In the case where you have a SmallString as a member I suppose it would be moderately inconvenient to override the default size in every ctor you have, compared to just specifying it as the template parameter, but that seems marginally beneficial over not having to specify the size whenever you refer to the type.

FWIW, the way Small* works is it allocates some initial number of elements directly inside the object, which means if it's stack-based, the entire object might live on the stack.

// Entirely stack-based until you grow past 32 elements.
SmallVector<E, 32> X
// Minimum stack size, initial 32-element heap allocation
SmallVectorImpl<E> X(32);

Without using alloca or VLAs there's no other way to do this besides specifying the size at compile-time.

Since TwineString is a sort of adapter class, it makes sense for it to use stack-based storage for small strings, at least to me.

Jordy