Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include:
 functional rw/_ref_wrap.h
Date: Mon, 30 Jun 2008 10:37:53 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901DB0606@exchmail01.Blue.Roguewave.Com>
Thread-Topic: svn commit: r672395 - in /stdcxx/branches/4.3.x/include:
 functional rw/_ref_wrap.h
Thread-Index: AcjZYN3V45LtwNglRp6HPBHblO97ZABbMn6A
References: <20080627211030.CA5CB2388A06@eris.apache.org>
 <4866A442.5080700@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

> -----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=20
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>=20
...
> > @@ -45,10 +45,11 @@
> > =20
> > =20
> >  #include <rw/_funcbase.h>
> > +#include <rw/_ref_wrap.h>
>=20
> 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.

>=20
...
> > =20
> >  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=3D (const=20
> reference_wrapper<_Type>& __x) {
> > +        _C_ptr =3D __x._C_ptr;
> > +        return *this;
>=20
>    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?

>=20
>    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:
>=20
>       reference_wrapper& operator=3D (const reference_wrapper& __x)

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

>=20
>    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.
>=20
> > +    }
> > =20
> > +    operator _Type& () const { return *_C_ptr; }
> > +
> > +    _Type& get() const { return *_C_ptr; }
>=20
>    4. Function invariants should be asserted wherever possible.

Yep, good point.

>=20
>    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:
>=20
>       type& get() const {
>           _RWSTD_ASSERT (0 !=3D _C_ptr);
>           return *_C_ptr;
>       }

No problem.

Good suggestions.  :)

Brad.