brangdon@cix.compulink.co.uk (Dave Harris) writes:

In-Reply-To: <200408061504.i76F4EW20044@entwistle.systems.susq.com> stewart@sig.com (Rob Stewart) wrote (abridged):

...

Note, however, that "rawptr" is rather terse for something you're trying to call attention to.

I liked the terseness. To be honest I am less likely to use new features if they are verbose. "boost::raw_ptr()" is already 16 characters. Surely the main benefit comes from being able to search for raw_ptr with tools like grep, rather than with eyeballs?

The later suggestion of writing:

boost::shared_ptr<Widget> p = boost::shared_ptr_cast<Widget>(new Widget);

is even more verbose and repetitive, the word "Widget" occurring 3 times. The original proposal:

boost::shared_ptr<Widget> wp2 = boost::raw_ptr(new Widget(a, b));

at least fits into 80 columns.

This is a bit similar to the borrowed( ... ) and null_ok( ... ) operators from Boost.Python

Is it time to wrap operator new()? For example:

boost::shared_ptr<Widget> wp2 = boost::make<Widget>(a, b);

with something like:

template <typename R, typename A, typename B> inline raw_ptr_t<R> make( A &a, B &b ) { return raw_ptr_t<R>( new R( a, b ) ); }

Users being allowed to specialise make<> with their own factory code if desired.

Yeah, except #define raw_ptr_t std::auto_ptr ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

From: brangdon@cix.compulink.co.uk (Dave Harris)

In-Reply-To: <200408061504.i76F4EW20044@entwistle.systems.susq.com> stewart@sig.com (Rob Stewart) wrote (abridged):

...

Note, however, that "rawptr" is rather terse for something you're trying to call attention to.

I liked the terseness. To be honest I am less likely to use new features if they are verbose. "boost::raw_ptr()" is already 16 characters. Surely the main benefit comes from being able to search for raw_ptr with tools like grep, rather than with eyeballs?

The whole point behind the names selected for the new-style casts was to make things more verbose. Other casts in Boost are similarly long-winded to follow suit. "raw_ptr" doesn't fit. Certainly, the lack of "_cast" is inconsistent, and precludes searching for "_cast" to find all casts in one's code. Also, Boost is not known to shy away from long names. Finally, one can add "using boost" to reduce the 22 characters to 15 ([boost::]shared_ptr_cast).

The later suggestion of writing:

boost::shared_ptr<Widget> p = boost::shared_ptr_cast<Widget>(new Widget);

is even more verbose and repetitive, the word "Widget" occurring 3 times.

Nevertheless, it is consistent with other casts. Note that it can be written as follows when not casting to a different pointer type: boost::shared_ptr<Widget> p(boost::shared_ptr_cast(new Widget)); That is, if the new expression results in the same type as the shared_ptr you're trying to create, you don't have to specify the shared_ptr type in the shared_ptr_cast. Moreover, since shared_ptr<T> can be copy constructed from shared_ptr<U>, provided U * converts implicitly and unambiguously to T * (usually because T is an unambiguous base of U), that syntax is permissible in all use cases.

The original proposal:

boost::shared_ptr<Widget> wp2 = boost::raw_ptr(new Widget(a, b));

at least fits into 80 columns.

There are a tremendous number of common expressions that result from using Boost that don't fit within 80 columns on a single line. Should this one be restricted when others aren't? That's not a particularly compelling argument against it. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;