replace libiberty with gnulib (was: Re: [PATCH 0/2] add unique_ptr class)

[Manuel López-Ibáñez]

On 05/09/17 18:40, Pedro Alves wrote:

On 09/05/2017 05:52 PM, Manuel López-Ibáñez wrote:
Yeah, ISTR it was close, though there were a couple things
that needed addressing still.

The wiki seems to miss a pointer to following iterations/review
of that patch (mailing list archives don't cross month
boundaries...).  You can find it starting here:
  https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01208.html
I think this was the latest version posted:
  https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01554.html


Thanks, I have updated the hyperlinks in the wiki.

Unfortunately, Ayush left and there is no one else to finish the work. While 
converting individuals functions from libiberty to gnulib is more or less 
straightforward, the build system of GCC is far too complex for any new or 
less-experienced contributor to finish the job.


I have also updated https://gcc.gnu.org/wiki/SummerOfCode
I don't believe that this was the only project accepted in 2016, but I cannot 
remember the others. Didn't GCC apply this year?


Cheers,

Manuel.

Re: [PATCH 0/2] add unique_ptr class

[Pedro Alves]

On 09/05/2017 05:52 PM, Manuel López-Ibáñez wrote:
> On 05/08/17 20:05, Pedro Alves wrote:
>> 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.
> 
> Unfortunately, that work was never committed, although there are parts
> that are ready to be committed and the rest of the conversion could be
> done incrementally:
> 
> https://gcc.gnu.org/wiki/replacelibibertywithgnulib

Yeah, ISTR it was close, though there were a couple things
that needed addressing still.

The wiki seems to miss a pointer to following iterations/review
of that patch (mailing list archives don't cross month
boundaries...).  You can find it starting here:
 https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01208.html
I think this was the latest version posted:
 https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01554.html

Thanks,
Pedro Alves

Re: [PATCH 0/2] add unique_ptr class

[Manuel López-Ibáñez]

On 05/08/17 20:05, Pedro Alves wrote:

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.


Unfortunately, that work was never committed, although there are parts that are 
ready to be committed and the rest of the conversion could be done incrementally:


https://gcc.gnu.org/wiki/replacelibibertywithgnulib

Cheers,

Manuel.

Re: [PATCH 0/2] add unique_ptr class

[Pedro Alves]

On 09/04/2017 11:31 AM, Richard Biener wrote:
> On Fri, Aug 11, 2017 at 10:43 PM, 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+...@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.

Exactly 3 letters has the nice property of making s/gtl::foo/std::foo/ super
trivial down the road; you don't have to care about reindenting stuff
[1].  Also makes gdb->gtl and gcc->gtl renamings trivial in the same way.
Really a minor thing in the grand scheme of things, but just a FYI that that
factored in a bit in the original motivation for the "gtl" naming back when
I proposed it on the gdb list.

[1] - [PATCH] gdb::{unique_ptr,move} -> std::{unique_ptr,move}:

Re: [PATCH 0/2] add unique_ptr class

[Richard Biener]

On Fri, Aug 11, 2017 at 10:43 PM, 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+...@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.

>

Re: [PATCH 0/2] add unique_ptr class

[Trevor Saunders]

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+...@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

> 
> 

Re: [PATCH 0/2] add unique_ptr class

[Ville Voutilainen]

>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 :-)

I wonder why such things wouldn't live in a namespace called 'gcc'.

Re: [PATCH 0/2] add unique_ptr class

[Jonathan Wakely]

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 :-)

Re: [PATCH 0/2] add unique_ptr class

[Jonathan Wakely]

On 05/08/17 01:36 -0400, Trevor Saunders wrote:

On Fri, Aug 04, 2017 at 07:52:18PM +0100, 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.  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.

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.


ok then I forgot or never knew that sorry.  It *is* std::unique_ptr in
C++11 or newer, so I think it would be odd to name it something else.


I was only objecting to "gtl" not to "unique_ptr". I agree that
calling it unique_ptr is the logical choice.

Re: [PATCH 0/2] add unique_ptr class

[Pedro Alves]

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.

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.

Thanks,
Pedro Alves

Re: [PATCH 0/2] add unique_ptr class

[Trevor Saunders]

On Fri, Aug 04, 2017 at 07:52:18PM +0100, 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.  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.
> 
> 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.

ok then I forgot or never knew that sorry.  It *is* std::unique_ptr in
C++11 or newer, so I think it would be odd to name it something else.

> STL != C++ Standard Library

Will try to remember that, sorry.

> If we want a namespace for GNU utilities, what's wrong with "gnu"?

I'm fine with s/gtl/gnu/g if that's what people want.

Trev

Re: [PATCH 0/2] add unique_ptr class

[Trevor Saunders]

On Fri, Aug 04, 2017 at 04:43:32PM -0600, Martin Sebor wrote:
> On 07/31/2017 05:46 PM, tbsaunde+...@tbsaunde.org wrote:
> > From: Trevor Saunders 
> > 
> > Hi,
> > 
> > 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.  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.  I'm not 
> > sure
> > at the moment what outside of gcc may want to use this, but putting it 
> > include/
> > at least allows us to use it in libcpp which may be useful.  I didn't 
> > include
> > too much usage in this series, but I believe other people have wanted this 
> > too,
> > so I'm reasonably confident it will get a fair amount of usage.
> > 
> > patches individually bootstrapped + regtested on ppc64-linux-gnu, ok?
> 
> FWIW, I'm a big fan of RAII and I like the idea being able to
> rely on a smart pointer in GCC quite a bit.  Although I haven't
> reviewed the C++ 03 implementation in any detail I like how the
> new API is just transitional until GCC switches from C++ 98 to
> C++ 11 when it will be possible to drop it, presumably with no
> changes to client code.  (If there's any risk that clients might
> come to depend on the C++ 03 "features" or limitations in the
> meantime and thus jeopardize this goal I would only suggest to
> put some effort into making this harder.)

Given that stage 2 / 3 of a bootstrap is as C++14 I expect that it would
be pretty hard to put in code that works with the shim, but not real
unique_ptr, since in a bootstrap situation both would be used.

> Other than that, thank you for this nice enhancement!

your welcome

Trev

> 
> Martin
> 

Re: [PATCH 0/2] add unique_ptr class

[Martin Sebor]

On 07/31/2017 05:46 PM, tbsaunde+...@tbsaunde.org wrote:

From: Trevor Saunders 

Hi,

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.  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.  I'm not sure
at the moment what outside of gcc may want to use this, but putting it include/
at least allows us to use it in libcpp which may be useful.  I didn't include
too much usage in this series, but I believe other people have wanted this too,
so I'm reasonably confident it will get a fair amount of usage.

patches individually bootstrapped + regtested on ppc64-linux-gnu, ok?


FWIW, I'm a big fan of RAII and I like the idea being able to
rely on a smart pointer in GCC quite a bit.  Although I haven't
reviewed the C++ 03 implementation in any detail I like how the
new API is just transitional until GCC switches from C++ 98 to
C++ 11 when it will be possible to drop it, presumably with no
changes to client code.  (If there's any risk that clients might
come to depend on the C++ 03 "features" or limitations in the
meantime and thus jeopardize this goal I would only suggest to
put some effort into making this harder.)

Other than that, thank you for this nice enhancement!

Martin

Re: [PATCH 0/2] add unique_ptr class

[Jonathan Wakely]

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.  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.


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

If we want a namespace for GNU utilities, what's wrong with "gnu"?

Re: [PATCH 0/2] add unique_ptr class

[David Malcolm]

On Mon, 2017-07-31 at 19:46 -0400, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders 
> 
> Hi,
> 
> 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.  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.  I'm not sure
> at the moment what outside of gcc may want to use this, but putting
> it include/
> at least allows us to use it in libcpp which may be useful.  I didn't
> include
> too much usage in this series, but I believe other people have wanted
> this too,

Thanks for posting this.

For example, I could use this in:

  [PATCH 1/3] c-family: add name_hint/deferred_diagnostic
  https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00439.html

e.g. as discussed here:

https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00123.html

Dave

> so I'm reasonably confident it will get a fair amount of usage.
> 
> patches individually bootstrapped + regtested on ppc64-linux-gnu, ok?
> 
> Trev
> 
> 

[PATCH 0/2] add unique_ptr class

[tbsaunde+gcc]

From: Trevor Saunders 

Hi,

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.  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.  I'm not sure
at the moment what outside of gcc may want to use this, but putting it include/
at least allows us to use it in libcpp which may be useful.  I didn't include
too much usage in this series, but I believe other people have wanted this too,
so I'm reasonably confident it will get a fair amount of usage.

patches individually bootstrapped + regtested on ppc64-linux-gnu, ok?

Trev