Gennaro Prota wrote:
On Sun, 16 Jul 2006 01:16:10 -0400, "Sean Huang" <huangsean@hotmail.com> 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