On Fri, Aug 11, 2017 at 10:43 PM, Jonathan Wakely <jwak...@redhat.com> 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+...@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). > > 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. > > >> 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::". > > 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. > > 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 :-)
If it should be short use g::. We can also use gnu:: I guess and I agree gnutools:: is a little long (similar to libiberty::). Maybe gt:: as a short-hand for gnutools. Richard. >
