This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 1/5] Remove some ui_out-related cleanups from Python
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Tom Tromey <tom at tromey dot com>, gdb-patches at sourceware dot org
- Date: Fri, 10 Feb 2017 01:58:07 -0500
- Subject: Re: [RFA 1/5] Remove some ui_out-related cleanups from Python
- Authentication-results: sourceware.org; auth=none
- References: <20170115134253.24018-1-tom@tromey.com> <20170115134253.24018-2-tom@tromey.com> <20170116113021.sar3yh5ivykpqmbw@ball> <c0a70339-49c3-a087-bebf-ecfdd2cc32ca@redhat.com>
On Wed, Feb 08, 2017 at 05:28:11PM +0000, Pedro Alves wrote:
> On 01/16/2017 11:30 AM, Trevor Saunders wrote:
> >> +++ b/gdb/common/gdb_option.h
> >
> > might be nice to put it in include/ but fine to do that later when
> > something else actually wants it.
>
> I've been thinking about putting all these utilities and
> later-standards replacements we're coming up with in its own
> directory/namespace. I had thought of "gtl", for "gdb template
> library", or "gnu template library" if other projects want to
> reuse it. (I think "gnu" is kind of taken by gnulib / libgnu.a)
> One difficulty with putting such a thing at the top level is that
> gdb relies on gnulib headers (that exist under gdb/) while
> other toolchain components don't, yet, at least.
yeah. I've been meaning to get to that too. I think for some of these
things that may not matter, but for some I'm sure it does.
> >> > + /* These aren't deleted in std::optional, but it was simpler to
> >> > + delete them here, because currently the users of this class don't
> >> > + need them, and making them depend on the definition of T is
> >> > + somewhat complicated. */
> > I think you can make <type_traits> do most of it, but fair enough.
> >
>
> Back around <https://sourceware.org/ml/gdb-patches/2016-11/msg00368.html>
> I backported C++17's optional to C++11. I still have that branch
> somewhere locally... /me finds it and pushes to github. Here:
>
> https://github.com/palves/gdb/commits/palves/gdb-import-gcc-optional
>
> This <https://github.com/palves/gdb/commit/880ab485c5873eb0a8ab1dca75e624ec2a064fe8>
> contains the local changes I had made to to port it to C++11. I was surprised
> that other than portable type traits stuff that's missing in C++11, the
> only thing that C++11 loses is constexpr-ness in some cases. Now,
> the result is of course much more code than what Tromey is proposing.
> It probably does make sense to start with something simpler and
> upgrade when/if we find a need. OTOH, looks like the current patch
> doesn't have accessors for the wrapped value, so it seems like we'll
> at least need to be extend it in that direction in no time.
yeah, I think start small is a very reasonable approach, though I'd
agree you'll want to get at the wrapped value pretty soon.
Trev