<div dir="rtl"><div dir="ltr">A very common code pattern in LLVM is</div><div dir="ltr"><br></div><div dir="ltr"><font face="monospace, monospace"> SmallString<128> S;</font></div><div dir="ltr"><font face="monospace, monospace"> raw_svector_ostream OS(S);<br></font></div><div dir="ltr"><font face="monospace, monospace"> OS<< ...</font></div><div dir="ltr"><font face="monospace, monospace"> Use OS.str()</font></div><div dir="ltr"><br></div><div dir="ltr">While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer:</div><div dir="ltr"><br></div><div dir="ltr"> In SmallString: void *BeginX, *EndX, *CapacityX<br></div><div dir="ltr"> In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur<br></div><div dir="ltr"><br></div><div dir="ltr">Moreover, at runtime the two sets of pointers need to be coordinated between the SmallString and raw_svector_ostream using raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync and raw_svector_ostream::write_impl.</div><div dir="ltr">All these functions have non-inlined implementations in raw_ostream.cpp. </div><div dir="ltr"><br></div><div dir="ltr">Finally, this may cause subtle bugs if S is modified without calling OS::resync(). This is too easy to do by mistake.</div><div dir="ltr"><br></div><div dir="ltr">In this frequent case usage the client does not really care about S being a SmallString with its many useful string helper function. It's just boilerplate code for raw_svector_ostream. But it does cost three extra pointers, some runtime performance and possible bugs.</div><div dir="ltr"><br></div><div dir="ltr">To solve all three issues, would it make sense to have raw_ostream-derived container with a its own SmallString like templated-size built-in buffer?</div><div dir="ltr"><br></div></div>