incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
Date Mon, 30 Jun 2008 18:36:17 GMT
Eric Lemings wrote:
>  
> 
>> -----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.

There's no trouble. The _RWSTD_NO_EXT_CXX_0X conditionals
need to be somewhere, and the public header is the logical
place for them (see, for example, <type_traits>). Otherwise
they would have to be replicated in every C++ 0x
implementation header.

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

I don't have the time to produce an elaborate rationale for
every single one of our established conventions that will
satisfy everyone. Often, no such rationale even exists and
the only reason is historical practice. If you want to do
things differently you're certainly welcome to put forward
a proposal for a change. However, in such cases, it's up
to you to produce a rationale for it that the rest of us
will find convincing.

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

The better efficiency of compiler generated functions
is cited among the motivating reasons for the defaulted
functions enhancement in N2346:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm

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

A comment indicating that a class in intended to be default
or CopyConstructible, or CopyAssignable (or satisfies any
other common constraint) sounds like a fine idea.

Martin


Mime
View raw message