"Fernando Cacciola" <fernando_cacciola@hotmail.com> wrote in message news:e9h475$3oq$1@sea.gmane.org...
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.
Just out of curiosity, why didn't you declare none_t as an enum? If you define enum none_t {none = 0}; then you have easily defined the value boost::none in a header file so that it can be included in as many headers as possible without bumping into the ODR. Joe Gottman