[llvm-dev] SmallString + raw_svector_ostream combination should be more efficient

Yaron Keren via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 13 07:03:51 PDT 2015

Ok, one more issue. I've removed the no-op resync() method and now getting
rid of numerous raw_ostream::flush() calls. These were required before but
now will never do anything but will waste runtime discovering that.
To find raw_svector_ostream::flush() calls speficially I locally shadowed
raw_ostream:flush() with a deleted flush():

class raw_svector_ostream {
  void flush() = delete;

so any direct use of raw_svector_ostream::flush() fails compilation.
Calling raw_ostream:flush() itself would never reach the deleted function
as it's not virtual, it will continue to function as before.

To explicitly prevent calling raw_svector_ostream::flush(), is that a good
solution to commit?

2015-08-13 16:53 GMT+03:00 Rafael EspĂ­ndola <rafael.espindola at gmail.com>:

> On 13 August 2015 at 04:17, Yaron Keren <yaron.keren at gmail.com> wrote:
> > r244870 (with the change you requested), thanks!
> >
> > I initially placed the virtual function in header since they were
> > one-liners.
> > The coding standards say that an anchor() function should be supplied,
> which
> > was indeed missing.  Other than required anchor function, why should the
> > virtual functions go in the .cpp?
> Just because there is no advantage for most virtual methods to be in the
> .h.
> > Should I move the empty raw_svector_ostream destructor to the .cpp file
> too
> > as well?
> Maybe. Destructors are the one exception since base class destructors
> call them non-virtually. If the class is final we can move them.
> Cheers,
> Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/18664a1f/attachment.html>

More information about the llvm-dev mailing list