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


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

Wow. That's a good question.  Do you think the helpers are generally
useful? If so, I'd say __gnu_cxx. If not, I'd say __gnu_tr1.

This kind of thing we can always change as we get more experience with
this.

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

Man, do the uglification rules ever need to be explained. I find myself
wondering about this issue a lot as well.

My general rule of thumb is: if you take an instance of something that
is a standard name, and then, using that instance, can get to something
that is non-standard (say a typename or a function call),  you need to
uglify it.

In your specific case, I'm guessing things look like:

struct shared_ptr 
{
  __gnu_cxx::__shared_count _M_count;

  void
  use_count() {  _M_count.use_count() } ;
};

I don't think this instance warrants uglification. However, if this was
inheritance not containment then the MF's would have to be uglified.

Hopefully somebody else (Nathan? Gaby? Paolo?) can set us both on the
path to enlightenment with some simple rules that we can always
apply.... C++STYLE has some of the hows, but not the whys on this stuff.

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

 (IMHO _M_ is unwarranted, this should be __reference or _Reference,
since this is not a member.). I prefer __reference.

Sorry, as I look over this response, this wasn't too helpful.


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