Re: [lmi] Danger of fatal_error()

[Vadim Zeitlin]

On Thu, 25 Feb 2016 07:37:39 +0000 Greg Chicares <address@hidden> wrote:

GC> I wanted to allow this:
GC> 
GC>     std::vector<std::string> v;
GC>     ...
GC>     fatal_error() << " list: ";
GC>     std::copy
GC>         (v.begin()
GC>         ,v.end()
GC>         ,std::ostream_iterator<std::string>(fatal_error(), " ")
GC>         );
GC>     fatal_error() << LMI_FLUSH;

 Yes, I see how this could be useful. But it could be done in other ways,
so it doesn't look like a critical advantage to me. Forgetting to flush the
fatal error is a critical bug however.

GC> If there's a natural and non-intrusive way to signal an error when
GC> leaving a scope with an unflushed stream:
GC> 
GC>   if(condition)
GC>     {
GC>     fatal_error() << "Not flushed...";
GC>     }
GC> 
GC> then we could talk about that; but I don't think it can work because
GC>   std::ostream& LMI_SO fatal_error();
GC> it's a reference, not an object on the stack.

 I think this could work using Alexandrescu's and Marginean's scope guard
trick: if fatal_error() were a macro expanding into something like this:

        fatal_error_guard const& guard = fatal_error_impl() << "Not flushed...";

then we could verify that the stream was flushed in fatal_error_guard dtor
because the temporary object returned by fatal_error_impl() would be only
destroyed on scope exit. However it would still be only a run-time check
and I'd much prefer to do it at compile-time...

 Regards,
VZ