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

[Yaron Keren via llvm-dev]

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 {
...
public:
...
  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>