namespace naming -- the question to moderators

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

namespace naming -- the question to moderators

Arkadiy Vertleyb
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

John Maddock
> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Tobias Schwinger
In reply to this post by Arkadiy Vertleyb
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Arkadiy Vertleyb
In reply to this post by John Maddock
"John Maddock" <[hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Jeff Flinn
In reply to this post by Tobias Schwinger
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Pavel Vozenilek

"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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Tobias Schwinger
In reply to this post by Jeff Flinn
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Arkadiy Vertleyb
"Tobias Schwinger" <[hidden email]> 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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Tobias Schwinger
Arkadiy Vertleyb wrote:

> "Tobias Schwinger" <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Arkadiy Vertleyb
"Tobias Schwinger" <[hidden email]> wrote
> 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
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Bertrand Augereau
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: namespace naming -- the question to moderators

Bulygin, Sergey
In reply to this post by Arkadiy Vertleyb
Even from my light boost.typeof experience, i know that this problem with MS
precompiled headers is a show-stopper for comfortable boost.typeof usage.

This is why I am actively vote for this fix.

Best Regards,
Sergey Bulygin


"Arkadiy Vertleyb" <[hidden email]> wrote in message news:<e174i9$8aj$[hidden email]>...

> "Tobias Schwinger" <[hidden email]> wrote
> > 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
> 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
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost