Re: [PATCH 0/2] add unique_ptr class

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

HI,

figured I'd ping this to see if we can come to some concensus, I don't
care much what we choose as a namespace, I just want to get this in so
we can use it more.

On Fri, Aug 11, 2017 at 09:43:21PM +0100, Jonathan Wakely wrote:
> On 05/08/17 20:05 +0100, Pedro Alves wrote:
> > On 08/04/2017 07:52 PM, Jonathan Wakely wrote:
> > > On 31/07/17 19:46 -0400, tbsaunde+gcc@tbsaunde.org wrote:
> > > > I've been saying I'd do this for a long time, but I'm finally getting to
> > > > importing the C++98 compatable unique_ptr class Pedro wrote for gdb a
> > > > while
> > > > back.
> > 
> > Thanks a lot for doing this!
> > 
> > > I believe the gtl namespace also comes from Pedro, but GNU template
> > > library seems as reasonable as any other name I can come up with.
> > 
> > Yes, I had suggested it here:
> > 
> >  https://sourceware.org/ml/gdb-patches/2017-02/msg00197.html
> > 
> > > 
> > > If it's inspired by "STL" then can we call it something else?
> > > 
> > > std::unique_ptr is not part of the STL, because the STL is a library
> > > of containers and algorithms from the 1990s. std::unique_ptr is
> > > something much newer that doesn't originate in the STL.
> > > 
> > > STL != C++ Standard Library
> > 
> > That I knew, but gtl was not really a reference to the
> > C++ Standard Library, so I don't see the problem.  It was supposed to
> > be the name of a library which would contain other C++ utilities
> > that would be shared by different GNU toolchain components.
> > Some of those bits would be inspired by, or be straight backports of
> > more-recent standards, but it'd be more than that.
> > 
> > An option would be to keep "gtl" as acronym, but expand it
> > to "GNU Toolchain Library" instead.
> 
> OK, that raises my hackles less. What bothered me was an apparent
> analogy to "STL" when that isn't even the right name for the library
> that provides the original unique_ptr.
> 
> And "template library" assumes we'd never add non-templates to it,
> which is unlikely (you already mentioned offset_type, which isn't a
> template).

Well, "GNU Toolchain Library" doesn't include template anywhere in the
name ;)

> It seems odd to make up a completely new acronym for this though,
> rather than naming it after something that exists already in the
> toolchain codebases.

That's fair, I suppose we could use namespace libiberty, but that's kind
of long.

> > For example, gdb has been growing C++ utilities under gdb/common/
> > that might be handy for gcc and other projects too, for example:
> > 
> > - enum_flags (type-safe enum bit flags)
> > - function_view (non-owning reference to callables)
> > - offset_type (type safe / distinct integer types to represent offsets
> >                into anything addressable)
> > - optional (C++11 backport of libstdc++'s std::optional)
> > - refcounted_object.h (intrusively-refcounted types)
> > - scoped_restore (RAII save/restore of globals)
> > - an allocator that default-constructs using default-initialization
> >   instead of value-initialization.
> > 
> > and more.
> > 
> > GCC OTOH has code that might be handy for GDB as well, like for
> > example the open addressing hash tables (hash_map/hash_table/hash_set
> > etc.).
> > 
> > Maybe Gold could make use of some of this code too.  There
> > are some bits in Gold that might be useful for (at least) GDB
> > too.  For example, its Stringpool class.
> > 
> > I think there's a lot of scope for sharing more code between the
> > different components of the GNU toolchain, even beyond general
> > random utilities and data structures, and I'd love to see us
> > move more in that direction.
> > 
> > > If we want a namespace for GNU utilities, what's wrong with "gnu"?
> > 
> > That'd be an "obvious" choice, and I'm not terribly against it,
> > though I wonder whether it'd be taking over a name that has a wider
> > scope than intended?  I.e., GNU is a larger set of projects than the
> > GNU toolchain.  For example, there's Gnulib, which already compiles
> > as libgnu.a / -lgnu, which might be confusing.  GCC doesn't currently
> > use Gnulib, but GDB does, and, there was work going on a while ago to
> > make GCC use gnulib as well.
> 
> Good point. "gnutools" might be more accurate, but people might object
> to adding 10 extra characters for "gnutools::".

yeah, 3 or 4 characters seems to be the length of namespace names that
other people like, and its still fairly reasonable to use the fully
qualified name then.

> Naming is important, especially for a whole namespace (not just a
> single type) so I do think it's worth spending time getting it right.

True, though as far as I'm aware we wouldn't be promising any kind of
stability so would be free to rename it if we felt the need.

> But I could live with gtl as long as nobody ever says "GTL is the GNU
> STL" or mentions "gtl" and STL in the same breath :-)

heh, well feel free to be annoyed if I do it at least ;)

thanks

Trev

> 
>