stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
Date Mon, 30 Jun 2008 16:37:53 GMT
 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in 
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> 
...
> > @@ -45,10 +45,11 @@
> >  
> >  
> >  #include <rw/_funcbase.h>
> > +#include <rw/_ref_wrap.h>
> 
> The #include directive should be guarded by #ifndef
> _RWSTD_NO_EXT_CXX_0X. That way non-C++ 0x users won't be penalized
> by #including the header and we won't have to worry about wrapping
> the whole contents of <rw/_ref_wrap.h> in a pair of these #ifdef/
> #endif directives.

I don't have a problem with this really but are you certain this
"penalty" is really worth adding redundant compile guards, considering
that the header already contains guards, albeit within the header?  I'm
not sure the perceived penalty is really worth the trouble.

> 
...
> >  
> >  template <class _Type>
> > -class __rw_ref_wrap
> > +class reference_wrapper
> >  {
> > +    _Type* _C_ptr;
> > +
> > +public:
> > +
> > +    typedef _Type type;
> > +
> > +    reference_wrapper (_Type& __x)
> > +        : _C_ptr (&__x) { /* empty */ }
> > +
> > +    reference_wrapper (const reference_wrapper<_Type>& __x)
> > +        : _C_ptr (__x._C_ptr) { /* empty */ }
> > +
> > +    reference_wrapper& operator= (const 
> reference_wrapper<_Type>& __x) {
> > +        _C_ptr = __x._C_ptr;
> > +        return *this;
> 
>    1. We prefer to use the public types in favor of those of template
>       parameters in definitions of standard templates. This is in
>       contrast to the spec which prefers the template paramaters for
>       some unknown reason. Our rationale is that the public names are
>       more stable and more familiar to users and maintainers alike.

Hmm.  I have no problem with that either.  I'd like to have a more
convincing
rationale (for either case) though.

Does the compiler treat a typedef and a template parameter the same or
are
there actually slight differences?

> 
>    2. We omit redundant template arguments in the definition of
>       a template class. The rationale is simplicity.
>       Thus, the declaration of the assignment operator should look
>       like so:
> 
>       reference_wrapper& operator= (const reference_wrapper& __x)

Oh right.  I usually do it that way myself.  Not sure why I explicitly
named them here.

> 
>    3. We omit definitions of special member functions (ctors, non
>       virtual dtors, and assignment operators) that are normally
>       implicitly generated by the compiler (provided the effects
>       are right, of course). The rationale is efficiency and
>       simplicity.

Simplicity, yes.  Not sure its any less efficient.

But there should be a comment explicitly stating that the
compiler-generated members are expected/acceptable?  If for example
another ctor were added, the comment would remind the developer that the
compiler-generate members are no longer there and must be added.

>       In reference_wrapper, we can safely omit the definition of
>       not just the dtor but also that of the copy ctor and the
>       copy assignment operator.
> 
> > +    }
> >  
> > +    operator _Type& () const { return *_C_ptr; }
> > +
> > +    _Type& get() const { return *_C_ptr; }
> 
>    4. Function invariants should be asserted wherever possible.

Yep, good point.

> 
>    5. The definitions of even trivial non-empty functions should
>       never appear on the same line as the function signature. I.e.,
>       the above should be:
> 
>       type& get() const {
>           _RWSTD_ASSERT (0 != _C_ptr);
>           return *_C_ptr;
>       }

No problem.

Good suggestions.  :)

Brad.

Mime
View raw message