[llvm-commits] Twine/StringRef enhancements & usage

[David Blaikie]

>
> 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.
>

I'd figured as much - which is why I was a bit surprised to see
SmallVectorImpl's ctor taking the size at runtime...


> // 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);
>

I /think/ that isn't the case. Line 68 of
SmallVector.h<http://llvm.org/docs/doxygen/html/SmallVector_8h_source.html>contains
SmallVector's ctor and it has:

"SmallVectorImpl<http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVectorImpl.html>
<T>(NumTsAvailable)"

SmallVector is telling SmallVectorImpl how far past its own memory space it
can walk...

So my use of SmallVectorImpl was probably entirely erroneous/unsafe/broken.

Perhaps SmallVectorImpl's ctor should be protected and/or it could use CRTP
to access the size as a compile-time constant (rather than a ctor argument)
from the derived type?
Hmm, it's using it to runtime initialize the capacity pointer anyway...
which only works because this thing never shrinks (so it doesn't have to
remember how big the reserved space is because it'll never try to fit back
into it if it outgrows it), so no real benefit to initializing the capacity
as a compile time constant unless shrinking was supported (it'd save
remembering the value as a runtime variable).

Fun times,

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110825/e66ae35e/attachment.html>