[llvm-commits] PATCH: Add raw_svector_ostream direct vector output

[Daniel Dunbar]

On Tue, Aug 18, 2009 at 11:06 PM, Ted Kremenek<kremenek at apple.com> wrote:
> On Aug 18, 2009, at 10:27 PM, Daniel Dunbar wrote:
>
>> I'm proposing as a patch because it has two downsides:
>> 1. It exposes some bits of SmallVector; namely it adds a capacity()
>> method, which gives the allocated size of the current buffer, and a
>> set_size() method, which clients can use to forcibly set the vector
>> size (without doing any construction or destruction). The use case is
>> basically that clients will intentionally write past the end() of the
>> vector (but not past the capacity() of the buffer), and then at some
>> point call set_size() to update the vector size.
>
> Although there may be some aesthetic disagreement on this, I'm fine with
> 'set_size()' being private and having raw_svector_ostream being a friend of
> SmallVector.  Exposing 'set_size()' as part of SmallVector's general
> interface seems like a bad idea.

I'm not really sure. Its not really an "unreasonable" API to expose,
and there are definitely other places that I have wanted it. And I
don't think it really constraints the SmallVector implementation,
since there is more or less only one sensible implementation. But I
agree it is non-standard; however I marginally treating it as part of
the API instead of keeping it private.

>> 2. It forces clients of raw_svector_ostream to provide a SmallVector
>> with at least 128 bytes free. This is probably a good thing, but it
>> isn't enforced by the API (it is enforced by a runtime check, of
>> course).
>
> I certainly am probably missing something here, but since you're doing a
> dynamic check anyway, why not just have raw_svector_ostream increase the
> capacity on its own?
>
> For example, instead of using 'llvm_report_error', can we just grow the
> small vector?

We could, yes, but that would necessarily require an allocation, which
we don't want. Instead we want to force clients to pass in a large
enough buffer that the common case will be no allocation occurs.

 - Daniel