"Jonathan Turkanis" <technews@kangaroologic.com> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Jonathan Turkanis wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
> BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > T * px; // contained pointer > detail::shared_count pn; // reference counter
This doesn't look any better to me than the original, sorry. ;-)
I agree with Peter. In fact, to me it looks significantly worse.
Well, there's no accounting for taste. ;-) I use similar macros a lot in the Preboost Interfaces library.
This has nothing to do with taste. The original version of the code can be understood immediately as it only relies on general C++ knowledge. The macro-based version adds a level of indirection; you now need to look at the documentation or the definition of the macros.
Right. It would be different if the macros significantly raised the abstraction level, but they don't.
The reason I like the macros is that you only need one version of the code,
I consider the #ifdef idiom to be only "one version of the code", when I look at it. I generally don't need protected members, so I put the friends right between the public and private stuff, where it belongs: class fu { public: . . . #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: // template friends template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif private: // data members T* px; detail::shared_count pn; }; Clean and quiet.
and -- if you find the macro names intuitive -- the version with the macros reads like the version for conforming compilers.
Just wait till you start needing nontype template parameters.
It's basically the same idea as BOOST_USE_FACET.
Never had to use that one. -- Dave Abrahams Boost Consulting www.boost-consulting.com