Eric Lemings wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Saturday, June 28, 2008 2:51 PM
To: [email protected]
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
