This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] std::tr1::array


On Fri, Oct 08, 2004 at 11:33:58AM -0500, Benjamin Kosnik wrote:

> 
> >Yeah, I planned on comparing them _carefully_. Licence shouldn't be a
> >problem, but once I've seen if they're suitable candidates to turn into
> >the TR1 I'll check that on the Boost list (I've been helping fix issues
> >with Boost versus GCC 3.4 anyway). As long as the Boost licence text is
> >left in the headers we should be able to use 'em.
> 
> FYI the last boost bit that was added to libstdc++, the concept checking
> bits, was licensed with the GPL. Personally, I think this is a good
> idea. However, this requires the consent of the orignal author. 

I've done a preliminary <tr1/memory> defining shared_ptr, weak_ptr and
bad_weak_ptr in std::tr1.

These were based on the Boost implementations, so I'll mail
the authors and the Boost list now and ask about the possibility of
licensing them as GPL+exception for v3.

All components not mentioned in TR1 (such as shared_count, weak_count)
are uglified and in __gnu_cxx. All uses of boost::lightweight_mutex have
been replaced with (I hope) equivalent atomic operations using
bits/atomicity.h

I deleted members not mentioned in TR1, I'll be doing a thorough review
before I'm finished.  There are still a few places that don't conform to
C++STYLE, and I have a few questions:

Should I have put helpers in __gnu_cxx, or in e.g. __gnu_tr1 ?

What's the proper policy on uglification? Do *all* non-standard names
have to be uglified?
e.g. std::tr1::shared_ptr uses a __gnu_cxx::__shared_count,
shared_ptr::use_count() calls __shared_count::use_count(),
shared_ptr::unique() calls __shared_count::unique(),
shared_ptr::release() calls __shared_count::release() etc.

Do I need to uglify the __shared_count members, so e.g.
shared_ptr::unique() calls __shared_count::_M_unique() ?
(I have done so, but can easily undo it)

What about the helper shared_ptr_traits, which I've defined like so:

    namespace __gnu_cxx
    {
        template<class _Tp> struct __shared_ptr_traits
        {
            typedef _Tp& _M_reference;
        };
    }

And then std::tr1::shared_ptr contains:
    typedef typename __gnu_cxx::__shared_ptr_traits<_Tp>::_M_reference reference;

Is that more uglification than necessary?

> I don't know what the official policy is on this stuff, quite frankly.

If the original authors don't want to allow their code to be used with
the GPL then I'll start a rewrite. That'll take me much longer, but mean
I get to know the classes even more intimately.

jon

-- 
I eat my peas with honey, I've done it all my life
It makes them taste quite funny, but it keeps them on the knife
	- The Orb


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]