Re: [boost] [optional]none.hpp causes VC7.1 precompiled header tobehave erratically

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2006-07-17 18:50:20

Gennaro Prota wrote:
> On Sun, 16 Jul 2006 01:16:10 -0400, "Sean Huang"
> <huangsean_at_[hidden]> wrote:
>
>> Interestingly, I notice that boost::none is defined in an unnamed
>> namespace.
>
> That really surprised me. As a rule of thumb unnamed namespaces
> shouldn't be used in headers. In the rare cases where a good reason
> exists for doing the contrary, that should be adequately commented.
>
>> Since boost::none is const and thus has internal linkage so I
>> removed the unnamed namespace and everything started working again.
>> So my questions is what purpose the unnamed namespace serves? Can it
>> be removed in light of this problem with precompiled headers?
>
> If there are good reasons for having it, it should be removed
> regardless of the precompiled header problem. An unnamed namespace has
> a name which is unique to its translation unit, not source file.
>
OK. To be honest I can't find myself any good reason for that.
I have a faint recollection that I just duplicated the implementation of
some other boost library which is, or was, putting such "global constants"
on the unnamed namespace, but I can't find it now.
In any event, I agree that the unnamed namespace should be removed, so
unless someone comes up with a good reason for that in the next few days,
I'll just proceed with it.

> I'm also surprised that both none.hpp and none_t.hpp are in the boost
> root dir. Do they have any general usage that justifies that? (I think
> I was guilty of a similar sin with non_type.hpp and I'd be happy to
> move it)

The truth is that I see "none" as a general token and not something specific
to optional.
You could use it in variant, any, tuple, etc... so like most stuff in boost
is there so others can use it... but of course is up to those others to go
ahead and do it.

Best

Fernando Cacciola