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;