Re: Idle curiosity re. using directive/declaration scoped to a givenclass - is this technique sensible?
 

On 04/19/10 10:35 AM, Stuart Golodetz wrote:
> Hi guys,
>
> Just curious what you think of the technique described below. It seems
> to solve an issue I've occasionally encountered, but it involves putting
> a using directive/declaration in a header file (but within a
> class-specific namespace). Just wondering whether this would be "frowned
> upon" or whether you think it's a valid technique please.
>
> The problem:
>
> I occasionally find I want to bring things from a namespace into scope
> within a class definition in a header file. AFAIK I can't do that in a
> trivial way, however. (Obviously I don't want to put the using
> directive/declaration somewhere where it will pollute the global
> namespace, or the actual namespace in which the class should reside.)
>
> A suggested solution:
>
> Put a class-specific namespace around the class and shove the using
> directive/declaration in that, e.g.
>
> #include <boost/shared_ptr.hpp>
>
> namespace N
> {
>
> namespace N__X
> {
> using namespace boost;
> struct X
> {
> shared_ptr<int> p;
> };
> }
>
> using N__X::X; // bring N__X::X into N (as originally intended)
>
> }
>
> (a) Does this seem reasonable?
> (b) Is there a better way at all?
>
> N.B. Using shared_ptr doesn't entirely illustrate why I find the
> technique appealing -- for a better example, consider something like a
> Boost Multi-Index Container.

Could you achieve the same result using one or more typedefs?

--
Ian Collins

Re: Idle curiosity re. using directive/declaration scoped to a givenclass - is this technique sensible?
 

On 19 apr, 03:31, Stuart Golodetz <b...@blah.com> wrote:
> On 18/04/2010 23:56, Ian Collins wrote:
>
>
>
> > On 04/19/10 10:35 AM, Stuart Golodetz wrote:
> >> Hi guys,
>
> >> Just curious what you think of the technique described below. It seems
> >> to solve an issue I've occasionally encountered, but it involves putting
> >> a using directive/declaration in a header file (but within a
> >> class-specific namespace). Just wondering whether this would be "frowned
> >> upon" or whether you think it's a valid technique please.
>
> >> The problem:
>
> >> I occasionally find I want to bring things from a namespace into scope
> >> within a class definition in a header file. AFAIK I can't do that in a
> >> trivial way, however. (Obviously I don't want to put the using
> >> directive/declaration somewhere where it will pollute the global
> >> namespace, or the actual namespace in which the class should reside.)
>
> >> A suggested solution:
>
> >> Put a class-specific namespace around the class and shove the using
> >> directive/declaration in that, e.g.
>
> >> #include <boost/shared_ptr.hpp>
>
> >> namespace N
> >> {
>
> >> namespace N__X
> >> {
> >> using namespace boost;
> >> struct X
> >> {
> >> shared_ptr<int> p;
> >> };
> >> }
>
> >> using N__X::X; // bring N__X::X into N (as originally intended)
>
> >> }
>
> >> (a) Does this seem reasonable?
> >> (b) Is there a better way at all?
>
> >> N.B. Using shared_ptr doesn't entirely illustrate why I find the
> >> technique appealing -- for a better example, consider something like a
> >> Boost Multi-Index Container.
>
> > Could you achieve the same result using one or more typedefs?
>
> Yes -- that's what I do if it's just for one or two things actually.
>
> The sort of use cases I was pondering are:
>
> (a) Things like Boost Multi-Index Container which can require quite a
> lot of typedefs -- which sort of obscure the code a bit.
>
> (b) Bringing a class template rather than an instance of it into scope
> -- with typedefs, for instance, I might have to do:
>
> typedef boost::shared_ptr<double> double_Ptr;
> typedef boost::shared_ptr<int> int_Ptr;
> typedef boost::shared_ptr<X> X_Ptr;
> //etc.
>
> I guess I was just wondering whether this would qualify as a respectable
> practice or whether it's just a hack :)

Typedefing has other goals. You put things into context. With
"shared_ptr<int>" to "int_Ptr" it is just renaming. It is worth to
typedef things that you are going to use:

typedef boost::adjacency_list< boost::vecS
, boost::vecS
, boost::undirectedS
, boost::property< boost::vertex_color_t,
int >
, boost::property< boost::edge_weight_t,
int >
, boost::no_property
, boost::listS
> MovementGraph;

I got probably sick of typing "boost" here, but this MovementGraph is
exposed in interface. For someone unfamiliar with Boost.Graph who is
reading it it is perhaps even worse Chinese if i remove all boost::
from it. At least now he rests assured that the things used are
probably described together with boost::adjacency_list somewhere and
not my own makings.

Re: Idle curiosity re. using directive/declaration scoped to a givenclass - is this technique sensible?
 

On Apr 19, 2:29*pm, Stuart Golodetz <b...@blah.com> wrote:
> On 19/04/2010 02:09, Öö Tiib wrote:
> > typedef boost::adjacency_list< *boost::vecS
> > * * * * * * * * * * * * * * * , boost::vecS
> > * * * * * * * * * * * * * * * , boost::undirectedS
> > * * * * * * * * * * * * * * * , boost::property< boost::vertex_color_t,
> > int>
> > * * * * * * * * * * * * * * * , boost::property< boost::edge_weight_t,
> > int>
> > * * * * * * * * * * * * * * * , boost::no_property
> > * * * * * * * * * * * * * * * , boost::listS
> > * * * * * * * * * * * * * * * > *MovementGraph;
>
> > I got probably sick of typing "boost" here, but this MovementGraph is
> > exposed in interface. For someone unfamiliar with Boost.Graph who is
> > reading it it is perhaps even worse Chinese if i remove all boost::
> > from it. At least now he rests assured that the things used are
> > probably described together with boost::adjacency_list somewhere and
> > not my own makings.
>
> It's a fair point. I have to say I usually get sick of typing "boost"
> very quickly with things like this though -- aside from the fact that
> it's exposed in interface (which I agree makes it debatable), this was
> exactly the sort of use case I had in mind.

Yes, writing intuitive public interfaces is difficult. I think it is
less about making it shorter to type and more about making it easier
to understand and to use. C++ has powerful ways to hide irrelevant
information. Often it is not needed to expose such constructs like
above in header file. When it is needed then i prefer raw forms for
things that i do not expect to be used. I did not typedef
boost::property<boost::vertex_color_t,int> to display that i do not
expect it to be used as separate type by users of that interface.
There may be reasons why i did not hide and enwrap that MovementGraph.
You may also have reasons not to hide usage of that multi-index-
container (behind Pimpl idiom for example). Such reasons are worth to
think about when it feels like typing too lot of boost:: in header.