Visual C++ 8.0 Compiler Bug makes namespaces public
Hi, we discovered a compiler bug using Visual C++ 8.0 (SP1). This bug makes boost namespace items visible in the global namespace and so makes boost libraries conflict with other libraries. The following example [1] displays how this bug can make namespace items public. When moving the exception class definition outside the namespace everything works as expected. We encountered this problem when using boost::integer in combination with boost::serialization. After including the file shared_count_132.hpp all boost::integer types are public and conflict with other libraries. This leads to the problem shown in the example [0]. The uint32_t type is publicly visible. To our knowledge this bug is present in Visual C++ 8.0 (SP1). Visual C++ 9.0 does not show this bug anymore. [0] #include <boost/cstdint.hpp> #include <boost\serialization\detail\shared_count_132.hpp> int main(int argc, char **argv) { uint32_t hallo; // this should not be possible } [1] #include <stdexcept> namespace fu { typedef unsigned int uint32_fu; } // namespace fu namespace fu2 { using namespace fu; class bad_weak_ptr: public std::exception {}; namespace detail{ class sp_counted_base { void add_ref_lock() { throw bad_weak_ptr(); } }; } } int main(int argc, char **argv) { uint32_fu hallo; } -chris -- Christopher Lux | | Bauhaus-Universität Weimar | Faculty of Media - Virtual Reality Systems Group
Christopher Lux wrote:
Hi, we discovered a compiler bug using Visual C++ 8.0 (SP1). This bug makes boost namespace items visible in the global namespace and so makes boost libraries conflict with other libraries. The following example [1] displays how this bug can make namespace items public. When moving the exception class definition outside the namespace everything works as expected.
We encountered this problem when using boost::integer in combination with boost::serialization. After including the file shared_count_132.hpp all boost::integer types are public and conflict with other libraries. This leads to the problem shown in the example [0]. The uint32_t type is publicly visible.
To our knowledge this bug is present in Visual C++ 8.0 (SP1). Visual C++ 9.0 does not show this bug anymore.
Yep this is indeed evil :-( Boost.Serialization's author, Robert Ramey, seems to be away at present (Robert?), but if he'd like a Boost.Config macro to help work around this it can be added soon enough. John.
John Maddock wrote:
Yep this is indeed evil :-(
Boost.Serialization's author, Robert Ramey, seems to be away at present (Robert?), but if he'd like a Boost.Config macro to help work around this it can be added soon enough.
This would be great. Thanks -chris -- Christopher Lux | | Bauhaus-Universität Weimar | Faculty of Media - Virtual Reality Systems Group
Hi Christopher.
Hi, we discovered a compiler bug using Visual C++ 8.0 (SP1). This bug makes boost namespace items visible in the global namespace and so makes boost libraries conflict with other libraries.
This seems to be related to the bug I mentioned in the '[boost.pool] Workaround for a msvc 7.1 & 8.0 bug surfaced in the boost 1.35 release' from 8.4.2008. That post also includes two minimalistic examples for reproducing the bug. There I found a way to avoid it using some fully qualified identifiers so perhaps something like this can help you. Hope this helps. Best regards, Jurko Gospodnetić
Christopher Lux wrote:
Hi, we discovered a compiler bug using Visual C++ 8.0 (SP1). This bug makes boost namespace items visible in the global namespace and so makes boost libraries conflict with other libraries. The following example [1] displays how this bug can make namespace items public. When moving the exception class definition outside the namespace everything works as expected.
We encountered this problem when using boost::integer in combination with boost::serialization. After including the file shared_count_132.hpp all boost::integer types are public and conflict with other libraries. This leads to the problem shown in the example [0]. The uint32_t type is publicly visible.
To our knowledge this bug is present in Visual C++ 8.0 (SP1). Visual C++ 9.0 does not show this bug anymore.
We found this last week, I posed it to the list and filed a ticket: http://svn.boost.org/trac/boost/ticket/1773 We found it in conjunction with IntelTBB, rather than boost::integer though. Robert has fixed it though, it looks like. (Good work!) Cheers /Marcus
Marcus Lindblom wrote:
We found this last week, I posed it to the list and filed a ticket: http://svn.boost.org/trac/boost/ticket/1773
We found it in conjunction with IntelTBB, rather than boost::integer though.
Robert has fixed it though, it looks like. (Good work!)
Hi, thanks for the heads up. But i am not able to find the fix in the svn (trunk, tags/release or branches/release). Is the fix already in the repository? -chris -- Christopher Lux
Christopher Lux wrote:
Marcus Lindblom wrote:
We found this last week, I posed it to the list and filed a ticket: http://svn.boost.org/trac/boost/ticket/1773
We found it in conjunction with IntelTBB, rather than boost::integer though.
Robert has fixed it though, it looks like. (Good work!)
Hi, thanks for the heads up. But i am not able to find the fix in the svn (trunk, tags/release or branches/release). Is the fix already in the repository?
Looking at the comments on the ticket linked above, Robert claims he has fixed it, but not yet commited. So, that's a no, for now. Cheers, /Marcus
participants (4)
-
Christopher Lux -
John Maddock -
Jurko Gospodnetić -
Marcus Lindblom