Re: [RFA] C++-ify parse_format_string

[Tom Tromey <tom@tromey.com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> I call it a step backwards because simplification is done at the
Pedro> cost of efficiency (individual heap allocations, changing the
Pedro> ownership model), when the original code avoided that.

I agree with this principle in general, but I think that in this
particular case, the efficiency and/or allocation argument is not very
strong -- I just doubt this code is space- or time-sensitive.

So on the whole I think in this case it would be fine to use Simon's
patch.

Pedro> [1] - I've thought several times because that something like a zstring_view
Pedro> (like string_view, but guarantees null-termination) would be handy in
Pedro> a lot of places.  string_view isn't mutable, though, hence the
Pedro> alternative name instead.  could be mut_string_view too, for example.

In gdb I've often wanted something like "std::string API but
unique_xmalloc_ptr allocation policy".  That way one could get the handy
string methods but allow nicer interfacing to things already using
xmalloc (I guess primarily libiberty but also readline and sometimes
BFD).

The main danger I see of views is that then one must reason about
lifetimes in order to use them.  But in gdb maybe this can be handled
via some relatively simple rules, like "never store a view on the heap".

Tom