Re: [RFA 2/5] Introduce ui_file_up and use it to remove cleanups

[Pedro Alves <palves@redhat.com>]

On 01/15/2017 01:42 PM, Tom Tromey wrote:
> This introduces a new ui_file_up typedef, which is a specialization of
> unique_ptr that calls ui_file_delete.  This patch also changes
> mem_fileopen to return a ui_file_up, and fixes the users.  It also
> updates a few other spots in the Python code to use this rather than
> cleanups.
> 
> If at some point ui_file_delete is removed in favor of a destructor, I
> think the typedef could be changed and the default deletion policy
> used instead.

Urgh, guess you forgot/missed my 
palves/cxx-eliminate-cleanups branch ... :-(

The top commit does:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Eliminate make_cleanup_ui_file_delete

And now that ui_file_as_string is in, let's eliminate it.  :-)

Makes ui_file a real C++ hierarchy.  mem_fileopen is replaced with a
new string_file class that is treated as a value class created on the
stack.  This alone eliminates most make_cleanup_ui_file_delete calls,
and, simplifies code a whole lot (diffstat shows almost 1k loc
dropped.)

string_file has a string() method that gives you a direct reference to
the internal std::string.  This is what replaces old (well, new)
ui_file_as_string, which used to alway return a new copy of the same
data the stream had inside..  With direct access via a writable
reference, we can instead move the string out of the string_stream.

Note I needed a tweak on scoped_restore.  That one should probably be
split out to a separate patch.

This exposed the need to make use of gnulib namespace support.
Otherwise, making use of read/write/printf/puts/etc symbol names will
clash on systems where gnulib replaces those functions, due to
'#define foo rpl_foo'.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've been working on fixing that gnulib namespace issue since,
thinking that I'd fix it before posting that patch, but looks
like that was the wrong decision...  :-/  Simon's ui_out series
also had the same problem, but since common-defs.h includes
the system headers that might cause the problem before
any other header, it ends up not being such a bad problem
in practice...

Thanks,
Pedro Alves