[optional]none.hpp causes VC7.1 precompiled header to behave erratically
It looks like VC7.1 doest not handle boost::none properly when it is included in a precompiled header. I started getting all sorts of weird errors after including boost/none.hpp in one of my precompiled headers. There is a comment in the file that warns borland users about the problem and it seems VC has a similar issue (I only tested it on VC7.1). Interestingly, I notice that boost::none is defined in an unnamed namespace. 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? Thanks, Sean
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. 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) -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
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
"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
participants (4)
-
Fernando Cacciola -
Gennaro Prota -
Joe Gottman -
Sean Huang