By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,422 Members | 1,615 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,422 IT Pros & Developers. It's quick & easy.

using directive being transitive

P: n/a
As far as I know, the using directive is transitive, and I'm not sure I
like this. So I'd like to ask if there's any workaround. Consider this:

namespace MyNameSpace
{
void
F(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpace::SomeType a);
void
G(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpaceSomeOtherType
a);
// ...
// Lots of such function declarations using types in
YetAnotherNameSpace
// ...
}

It's really inconvenient to always use these long qualifications, so it
would be nice to write using namespace
SomeNameSpace::SomeOtherNameSpace::YetAnotherNameS pace; at the
beginning of MyNameSpace. However, that would mean that client code
using MyNameSpace would see everything inside YetAnotherNameSpace, and
I think this is bad. Client code should be able to decide if thay want
to use the long syntax to access names inside YetAnotherNameSpace or
write their own using directive. The using at the beginning of
MyNameSpace would be an implementation detail; it's only purpose is
making the life of the implementor of MyNameSpace easier, but it
shouldn't force clients into using any other namespaces.

So, is this, or something similar possible in C++?

Thanks,

Imre

Aug 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Imre wrote:
As far as I know, the using directive is transitive, and I'm not sure I
like this. So I'd like to ask if there's any workaround. Consider this:

namespace MyNameSpace
{
void
F(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpace::SomeType a);
void
G(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpaceSomeOtherType
a);
// ...
// Lots of such function declarations using types in
YetAnotherNameSpace
// ...
}

It's really inconvenient to always use these long qualifications, so it
would be nice to write using namespace
SomeNameSpace::SomeOtherNameSpace::YetAnotherNameS pace; at the
beginning of MyNameSpace.
It might be better to have a namespace declaration instead... Or maybe
have typedefs for particular types involved, like

typedef
SomeNameSpace::SomeOtherNameSpace::YetAnotherNameS pace::SomeType SSYS;
However, that would mean that client code
using MyNameSpace would see everything inside YetAnotherNameSpace, and
I think this is bad. Client code should be able to decide if thay want
to use the long syntax to access names inside YetAnotherNameSpace or
write their own using directive. The using at the beginning of
MyNameSpace would be an implementation detail; it's only purpose is
making the life of the implementor of MyNameSpace easier, but it
shouldn't force clients into using any other namespaces.

So, is this, or something similar possible in C++?


I am not really sure what you mean here, could you give an example using
C++ instead of English? It doesn't have to compile. Just comment it.

V
Aug 17 '05 #2

P: n/a
Victor Bazarov wrote:
Imre wrote:
As far as I know, the using directive is transitive, and I'm not sure I
like this. So I'd like to ask if there's any workaround. Consider this:

namespace MyNameSpace
{
void
F(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpace::SomeType a);
void
G(SomeNameSpace::SomeOtherNameSpace::YetAnotherNam eSpaceSomeOtherType
a);
// ...
// Lots of such function declarations using types in
YetAnotherNameSpace
// ...
}

It's really inconvenient to always use these long qualifications, so it
would be nice to write using namespace
SomeNameSpace::SomeOtherNameSpace::YetAnotherNameS pace; at the
beginning of MyNameSpace.


It might be better to have a namespace declaration instead... Or maybe
have typedefs for particular types involved, like

typedef
SomeNameSpace::SomeOtherNameSpace::YetAnotherNameS pace::SomeType SSYS;


This works, but can be tedious if there are many types involved.
> However, that would mean that client code
using MyNameSpace would see everything inside YetAnotherNameSpace, and
I think this is bad. Client code should be able to decide if thay want
to use the long syntax to access names inside YetAnotherNameSpace or
write their own using directive. The using at the beginning of
MyNameSpace would be an implementation detail; it's only purpose is
making the life of the implementor of MyNameSpace easier, but it
shouldn't force clients into using any other namespaces.

So, is this, or something similar possible in C++?


I am not really sure what you mean here, could you give an example using
C++ instead of English? It doesn't have to compile. Just comment it.


Sure.

namespace n1
{
namespace n2
{
namespace n3
{
class T1 {};
class T2 {};
}
}
}

namespace ns
{
// just for convenience while declaring F1 and F2 (and possibly many
more such functions)
using namespace n1::n2::n3;

T1 F1();
T2 F2();

// these don't use anything from n3
void F3();
void F4();
}

// client code

class T1 {};

void F()
{
// for unqualified calls to ns::F3() and ns::F4()
// note that we don't use anything from n1::n2::n3
using namespace ns;

F3();
F4();

T1 t1; // T1 is ambiguous symbol.
}

The problem here is that even though client code is not interested in
stuff inside n1::n2::n3, it still gets them as a bonus, just because
the imlpementor of ns wanted some convenience.

What I'd like to do is change the
using namespace n1::n2::n3;
line in ns to something that says "I want to see everything in
n1::n2::n3, but anyone using me should _not_ automatically see them".
Names in n1::n2::n3 should be visible only while ns is open, not when
being used. Something like a "private using".

Imre

Aug 18 '05 #3

P: n/a

After some googling I found this:

http://www.open-std.org/jtc1/sc22/wg...1994/N0560.asc

Towards the end of the document the author discusses the same problem I
tried to explain. It seems that the current standard doesn't offer any
solutions.

Imre

Aug 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.