namespace naming -- the question to moderators
Hi all, The typeof library defines some templates in the unnamed namespace. This was done to avoid ODR violations in certain contexts (although it introduces them in other contexts). The unnamed namespace used now is: boost::type_of::<unnamed> It turnes out MSVC 7.1 and 8.0 cannot handle this kind of namespace correctly in conjunction with precompiled headers. Specifically, if a template is defined inside such a namespace in the precompiled header, it cannot be specialized outside this precompiled header (for typeof this means types cannot be registered outside pch). The problem can be worked around by using a different kind of unnamed namespace, like, for example: <unnamed>::boost_typeof (<unnamed>::boost::type_of introduces ambiguity in some contexts) This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace. Thoughts? Regards, Arkadiy
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
I'm surprised the any kind of unnamed namespace can be handled by PCH's: after all each TU should get it's own distict name for the unnamed namespace. John.
"John Maddock" <john@johnmaddock.co.uk> wrote
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
I'm surprised the any kind of unnamed namespace can be handled by PCH's: after all each TU should get it's own distict name for the unnamed namespace.
I don't know much about how this is done, but I think PCH stores the state of the compiler, so it should be possible to leave some unknowns in this state, such as namespace name, to resolve later. But again, I am just speculating. In any case, if you do somehing like this in PCH: namespace a { namespace { template<class T> struct foo {}; }} and then, outside PCH: namespace a { namespace { template<> struct foo<int> {}; }} the compiler (7.1, 8.0) will complain. If, OTOH, you use: namespace { namespace a { everything seems to compile fine. (I don't know how other compilers handle this problem, though) Regards, Arkadiy
Arkadiy Vertleyb wrote:
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
Thoughts?
MPL introduces a namespace called "::mpl_" (note: root namespace) by default. It is configurable with a macro. Maybe a similar approach will work for Typeof ("::<anonymous>::boost_typeof" or so). ::<anonymous>::boost::<...> looks potentially dangerous (ambiguity) to me although I believe it /should/ work... Regards, Tobias
Tobias Schwinger wrote:
Arkadiy Vertleyb wrote:
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
Thoughts?
MPL introduces a namespace called "::mpl_" (note: root namespace) by
FYI: IIRC, there was a recent post where explicit leading "::" in refering to namespaces caused problems in atleast one compiler. I don't remember the exact problem, but I think it was a version of borland. Jeff Flinn
"Jeff Flinn" wrote:
FYI: IIRC, there was a recent post where explicit leading "::" in refering to namespaces caused problems in atleast one compiler. I don't remember the exact problem, but I think it was a version of borland.
Yes, BCB (up to the newest version) doesn't like the leading :: in many contexts. /Pavel
Jeff Flinn wrote:
Tobias Schwinger wrote:
Arkadiy Vertleyb wrote:
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
Thoughts?
MPL introduces a namespace called "::mpl_" (note: root namespace) by
FYI: IIRC, there was a recent post where explicit leading "::" in refering to namespaces caused problems in atleast one compiler.
Actually I thought I'd be talking to human beings rather than a compiler, here ;-). Regards, Tobias
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
Jeff Flinn wrote:
Tobias Schwinger wrote:
Arkadiy Vertleyb wrote:
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
Thoughts?
MPL introduces a namespace called "::mpl_" (note: root namespace) by
FYI: IIRC, there was a recent post where explicit leading "::" in refering to namespaces caused problems in atleast one compiler.
Actually I thought I'd be talking to human beings rather than a compiler, here ;-).
:-) FWIW, I don't think we need this for typeof. All we need is to define some templates in, for example, <unnamed>::boost_typeof, and then refer to them as boost_typeof::blah. No leading "::" is needed. At least for Microsoft. Does anybody know if the similar problem exists in other compilers? Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote
Jeff Flinn wrote:
Tobias Schwinger wrote:
Arkadiy Vertleyb wrote:
This kind of unnamed namespace can be handled correctly by both MS compilers, with respect to pch, but I don't believe it satisfies the Boost naming convention. OTOH, if no other solution is found, this is the only way we can achieve typeof compliance with pch, while still staying in the unnamed namespace.
Thoughts?
MPL introduces a namespace called "::mpl_" (note: root namespace) by
FYI: IIRC, there was a recent post where explicit leading "::" in
refering
to namespaces caused problems in atleast one compiler.
Actually I thought I'd be talking to human beings rather than a compiler,
here ;-).
:-)
FWIW, I don't think we need this for typeof. All we need is to define some templates in, for example, <unnamed>::boost_typeof, and then refer to them as boost_typeof::blah.
Hmmm... That's about what I was talking about. Figuring that "boost_typeof" (other than "_mpl") is a name that's pretty unlikely to collide with user code, you probably won't need a configuration macro for its name.
No leading "::" is needed.
And (so joking doesn't obscure the message of my previous post) there is no "::" in the code! I used "::" simply to denote the namespace lives in the root namespace :-)... Regards, Tobias
Arkadiy Vertleyb wrote:
FWIW, I don't think we need this for typeof. All we need is to define some templates in, for example, <unnamed>::boost_typeof, and then refer to
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote them
as boost_typeof::blah.
Hmmm... That's about what I was talking about.
Figuring that "boost_typeof" (other than "_mpl") is a name that's pretty unlikely to collide with user code, you probably won't need a configuration macro for its name.
No leading "::" is needed.
And (so joking doesn't obscure the message of my previous post) there is no "::" in the code! I used "::" simply to denote the namespace lives in the root namespace :-)...
So, we seem to be in total agreement :-) My only concern was that this violates the Boost naming convention, but I think getting things to work is more important. Besides, you pointed to a precedent. I also know another one -- bind placeholders. I will not be available next week, but after that, unless somebody suggests a better alternative, I will implement this (I hope CVS is stable at that point, and we are not yet in the code freeze). Regards, Arkadiy
to denote the namespace lives in the root namespace
:-)...
So, we seem to be in total agreement :-)
My only concern was that this violates the Boost naming convention, but I think getting things to work is more important. Besides, you pointed to a precedent. I also know another one -- bind placeholders.
I will not be available next week, but after that, unless somebody suggests a better alternative, I will implement this (I hope CVS is stable at that point, and we are not yet in the code freeze).
Regards, Arkadiy
Great, thanks a lot! I'll poll for this on the CVS :) (All this trouble with the C++ compilers compliance remind me our trouble with different graphic hardware) Bertrand
participants (6)
-
Arkadiy Vertleyb -
Bertrand Augereau -
Jeff Flinn -
John Maddock -
Pavel Vozenilek -
Tobias Schwinger