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

[Ted Kremenek]

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.

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

+  if (OS.capacity() - OS.size() < 128)
+    llvm_report_error("Invalid argument, must have at least 128 bytes  
free!");