On 08/04/2017 07:52 PM, Jonathan Wakely wrote:
> On 31/07/17 19:46 -0400, tbsaunde+...@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
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:
> 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.
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.
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
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.