...

. template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees; ar & minutes; ar & seconds; } int degrees; int minutes; float seconds;

I am using MSVC 8.0 and here is example. This is the complete code and find the error at the end. If namespaces are used to avoid ambiguity I started wondering why are we doing using namespace boost::detail #include #include <fstream> // include headers that implement a archive in simple text format #include #include ///////////////////////////////////////////////////////////// // gps coordinate // // illustrates serialization for a simple type // class gps_position { private: CRITICAL_SECTION cs; friend class boost::serialization::access; // When the class Archive corresponds to an output archive, the // & operator is defined similar to <<. Likewise, when the class Archive // is a type of input archive the & operator is defined similar to public: gps_position(){}; gps_position(int d, int m, float s) : degrees(d), minutes(m), seconds(s) {} }; int main() { // create and open a character archive for output std::ofstream ofs("Test.Dat"); // create class instance const gps_position g(35, 59, 24.567f); // save data to archive { boost::archive::text_oarchive oa(ofs); // write class instance to archive oa << g; // archive and stream closed when destructors are called } // ... some time later restore the class instance to its orginal state gps_position newg; { // create and open an archive for input std::ifstream ifs("Test.Dat", std::ios::binary); boost::archive::text_iarchive ia(ifs); // read class state from archive ia >> newg; // archive and stream closed when destructors are called } return 0; } ERROR : 1>------ Build started: Project: BoostSerializationSimple, Configuration: Debug Win32 ------ 1>Compiling... 1>Main.cpp 1>y:\sourcecode\tempprojects\boostserializationsimple\boostserialization simple\main.cpp(16) : error C2872: 'CRITICAL_SECTION' : ambiguous symbol 1> could be 'c:\program files\microsoft sdks\windows\v6.0a\include\winbase.h(314) : RTL_CRITICAL_SECTION CRITICAL_SECTION' 1> or 'c:\program files\boost\boost_1_35_0\boost\detail\lwm_win32_cs.hpp(33) : boost::detail::CRITICAL_SECTION' 1>Build log was saved at "file://y:\SourceCode\TempProjects\BoostSerializationSimple\BoostSeriali zationSimple\Debug\BuildLog.htm" 1>BoostSerializationSimple - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Monday, August 04, 2008 1:50 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) causing problems on MSVC compiler AMDG Terdale, Shantibhushan wrote:

I am using boost for the first time and not much aware of whets going on. I am including serialization archive hpps and it is including these lines eventually somewhere inside

namespace detail{

#if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )

using namespace boost::detail;

#endif

I am using Visual Studio and MSVC compiler and this using directive is

causing me problems. There is a CRITICAL_SECTION defined in boos::detail which conflicts with standard windows CRITICAL_SECTION.

The thing am not able to understand is how is this Workaround works ? If this workaround checks for BORLANDC then shouldn't it just place that code for Borland compiler?

Did you notice the ! The using directive will appear for all compilers except borland.

Please help. Is there any other macro I can define or undefine that will get rid of this.

Grrr... I think this is a compiler bug. Do you have a small test case? Which version of msvc are you using? What file is this in? In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Steven Watanabe:

Terdale, Shantibhushan wrote:

...

I am using MSVC 8.0 and here is example. This is the complete code and find the error at the end. If namespaces are used to avoid ambiguity I started wondering why are we doing using namespace boost::detail

This seems to have been fixed. It fails with 1.35 but compiles with the 1.36 beta.

IIRC, the particular problem with CRITICAL_SECTION has been fixed, but the general problem with the MSVC bug making everything boost:: and boost::detail:: visible in the global namespace has not been. The header needs to be updated to not rely on an using directive (on non-Borland compilers as well).