From: Rob Stewart (stewart_at_[hidden])
Date: 2004-08-09 09:18:56
From: brangdon_at_[hidden] (Dave Harris)
> In-Reply-To: <200408061504.i76F4EW20044_at_[hidden]>
> stewart_at_[hidden] (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
> The later suggestion of writing:
> boost::shared_ptr<Widget> p = boost::shared_ptr_cast<Widget>(new
> 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
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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk