December 2005 - Boost-users

Re: [Boost-users] [serialization]Serializing ptime instances
by Merrill Cornish 19 Dec '05

19 Dec '05

Aaarrrgh! Jeff, Thanks for the pointer. I've finally gotten used to the fact that the Documentation link on the boost.org home page doesn't include (for some reason) the documentation hidden under libs/<library name>/doc/*. Now I see that to find out about serialization, I need to not only check the various serialization documentation pages, but the library documentation to see that IT says about serialization. Anyway, that's good news. Thanks for the pointer. Merrill

1 0

[serialization]Serializing ptime instances
by Merrill Cornish 19 Dec '05

19 Dec '05

Robert, I need to serialize ptime class instances. As far as I can tell, the ptime class isn't covered yet by serialization. However, if I understand how things work, I believe I can do it myself using split member. In the save() function, I would convert my ptime instance into a string, which I then serialize as a string. In the load() function, I would retrieve the string and construct another ptime instance. The other members of the class being serialized would be handled by the usual ar & <member_name>; with the appropriate NVP wrapper, since I'm using XML archives. Is that how I should do it? Merrill

2 1

Boost issues on Darwin (Mac OS X 10.4/gcc 4)
by Ryan McGann 19 Dec '05

19 Dec '05

Hello, I am trying to use the latest release of Boost (1.33.1) on Mac OS X 10.4 with gcc 4. I am running into a couple of issues. I have worked around all of them, but since the workarounds have required editing the actual bost files, I am wondering if there's something I am missing. 1) The build.sh file for the boost bjam tool in the 1.33.0 and 1.33.1 release seems to have DOS line endings. I know there are prebuilt binaries of bjam up on the Web, but our build system builds it manually, and it choked on Darwin because sh didn't like the DOS line endings. I resaved the file with Unix line endings and it built fine. 2) I get errors for multiply defined symbols for the placeholder symbols declared in boost/bind/placeholders.hpp. Every file that #include <boost/bind.hpp> contains actual instances of _1, _2, etc. Changing the declarations of these in boost/bind.hpp to static (I added a __APPLE__ to the #ifdef in the middle of the file) fixes this issue, but then I get warnings for unused static symbols if I don't use the placeholder objects. This issue in particular is quite annoying. 3) The header in boost/compatibility/cpp_c_headers/cstdio does not match up with the cstdio file included with the Mac OS X dev tools. In particular it is missing a using ::snprintf, which causes problems because this cstdio file is being included BEFORE the Mac OS X version of the same file, and other C++ header files rely on std::snprtinf being declared. I fixed this at first by deleting the boost/compatibility/cpp_c_headers folder, but then ending up just deleting that single file so that OS X always used the built-in header file. If anybody has workarounds for any of the above issues that are better than my workarounds, please by all means let me know. Thanks for the help! Ryan

2 1

Graph problem -- solvable using the Boost graph library ?
by matthieu.ferrant＠agfa.com 19 Dec '05

19 Dec '05

4 3

[Boost.Test] Use of numeric_limits in print_log_value (VC++7.1)
by Andrew n marshall 19 Dec '05

19 Dec '05

I've encountered a problem when transitioning from Boost.Test 1.32 to 1.33. New to 1.33 is a set_precision(..) method on the print_log_value functor (in test_tools.hpp). The problem, as I see it, is the use of numeric_limits<T>, which exposes the assumption T is a numeric entity at all. I'm actually surprised it compiles as often as it does, so maybe my blame is misdirected. Nonetheless, I was able to create the attached test case to prove my point. I've also included the generated build log with the really nasty compile time error. Anm // Weird Compile problem with Boost.Test 1.33 #include <iostream> #include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; // Class heirarchy and support functions class Abstract { virtual void go() = 0; // If Abstract is not pure virtual, everything compiles fine }; class Concrete : public Abstract { virtual void go() { } }; inline bool operator== ( const Abstract& a, const Abstract& b ) { return &a == &b; // identity } template <class C, class T > // character type, traits inline std::basic_ostream<C,T>& operator<< ( std::basic_ostream<C,T>& out, const Abstract& a ) { // Just prints a memory address. return out << "Abstract@0x" << &a; } // Function that forces us to work with the abstract interface Abstract& generalize( Concrete& c ) { return c; } // Test case & suite void test_abstract_identity() { Concrete a, b; // These work BOOST_CHECK_EQUAL( a, a ); // works BOOST_CHECK_EQUAL( a, b ); // fails correctly // These won't compile with 1.33 & VC++7.1 BOOST_CHECK_EQUAL( generalize(a), a ); Abstract& c = a; BOOST_CHECK_EQUAL( a, c ); } test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Example failure of Boost.Test 1.33.0" ); test->add( BOOST_TEST_CASE( &test_abstract_identity ), 1 ); return test; } // EOF

3 2

Re: [Boost-users] bjam using vc7.1
by Nat Goodspeed 19 Dec '05

19 Dec '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Scott Harris > Sent: Sunday, December 18, 2005 5:22 PM > To: boost-users(a)lists.boost.org > Cc: Scott Harris > Subject: [Boost-users] bjam using vc7.1 [Nat] We don't use bjam at all. We're using three "built" Boost libraries, and we hand-defined projects for each of them within our own VS .NET 2003 solution. This way we're sure the build configuration for these Boost libraries matches our own code, and we can use the debugger. > Some questions: > 1) How do I avoid the following warning output when building with bjam? [Nat] Don't use bjam :-) > 2) I am used to having solution and project files for Microsoft > Development > Environment (MDE) using Visual C++. > bjam apparently does not create these files. > Can I get bjam to create project files? [Nat] I don't believe it can do that. Maybe somebody out in cyberspace has written a conversion utility to read bjam files and generate equivalent .vcproj files -- but I wouldn't count on it. When we went spelunking through the Boost source tree, we found a .dsp file for one of the libraries we're using, and VS .NET 2003 was willing to read that and convert it to a .vcproj file. But really, it wasn't that hard to hand-create the other project files. Once you know where the appropriate source directory is, you just include every .cpp file in that directory.

1 0

[boost] 1.33.1 [regex] compile with vc2005 express: fatal error C1071
by Huifeng Shen 19 Dec '05

19 Dec '05

I download vc2005 express and install Microsoft Platform SDK for Windows Server 2003 SP1. I use Set Win Svr 2003 32-bit Build Env (Retail) to set the right platform environment and use the script below(vc2005 express and sdk are installed on the default directory) set BOOST_ROOT=c:\opt\boost set PYTHON_ROOT=c:\python set PYTHON_VERSION=2.4 call "C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat" @set BZIP2_SOURCE=c:\opt\bzip2 @set ZLIB_SOURCE=c:\opt\zlib @set TOOLS=vc-8_0 bjam "-sBUILD=debug release <runtime-link>static/dynamic <threading>multi" --with-regex stage >log.txt 2>err.txt I got the error below ============================== vc-C++ bin\boost\libs\regex\build\boost_regex.dll\vc-8_0\debug\threading-multi\regex_traits_defaults.obj regex_traits_defaults.cpp C:\opt\boost\libs\regex\build\../src/regex_traits_defaults.cpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss C:\opt\boost\libs\regex\build\../src/regex_traits_defaults.cpp(668) : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss C:\opt\boost\libs\regex\build\../src/regex_traits_defaults.cpp(690) : fatal error C1071: unexpected end of file found in comment CALL "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\vcvars32.BAT" >nul "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\cl" /Zm800 -nologo EHsc -c -DBOOST_REGEX_CONFIG_INFO=1 -DBOOST_REGEX_DYN_LINK=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Zc:forScope c:wchar_t -I"bin\boost\libs\regex\build" -I"C:\opt\boost" -Fo"bin\boost\libs\regex\build\boost_regex.dll\vc-8_0\debug\threading-multi\regex_traits_defaults.obj" -Tp"C:\opt\boost\libs\regex\build\../src/regex_traits_defaults.cpp" ============================== I find the description of fatal error C1071 in MSDN ============================== unexpected end of file found in comment The compiler reached the end of the file while scanning a comment. Possible causes Missing comment terminator (*/). Missing newline character after a comment on the last line of a source file. The following sample generates C1071: // C1071.cpp int main() { } /* this comment is fine */ /* forgot the closing tag // C1071 ============================== But regex can be compiled with vc7.1, I want to know if it is the vc8 express's fatal. Since I do not own a copy of VC8, I have not tried to compile boost 1.33.1 on it.

2 2

New to Boost and help needed
by Umut Tabak 18 Dec '05

18 Dec '05

Dear all, I have just downloaded Boost library and tried to configure under Ubuntu 5.10 Linux distribution. However the instructions are not so friendly for a person who is new to library usage and configuration(I used GSL but I did not have any problems like Boost). I tried to install bjam and configure the tools but no success. I would appreciate if experienced users could tell me the steps to configure in a more friendly way like a beginner would understand from scratch. I am also new to Linux environment so consider this also when replying if possible. Many thanks in advance and best regards. Umut TABAK

3 2

[serialization]Serializing a static vector
by Merrill Cornish 18 Dec '05

18 Dec '05

I have a class with a static STL vector as a member. The elements of this vector are themselves serializable classes. Can this vector be serialized? Is so, how? Merrill

2 2

Re: [Boost-users] crc.hpp and visual studio run time checking
by Clarke, Trevor 18 Dec '05

18 Dec '05

It's not a mask to stop data loss but to tell VS you want the data loss. I.E. unsigned short a = 0x1234; return (a << 8) & 0xffff; ------------------------------ Trevor R.H. Clarke tclarke at ball com Ball Aerospace & Technologies Corp -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Daryle Walker Sent: Friday, December 16, 2005 1:37 PM To: Boost Users mailing list Subject: Re: [Boost-users] crc.hpp and visual studio run time checking On 12/16/05 1:04 PM, "Clarke, Trevor" <tclarke(a)ball.com> wrote: > The problem is that the code does not state that it doesn't care if those bits > disappear (via masking) so a warning is thrown stating that you are loosing > data. Similar to compiler warnings if you do this: > > int foo(123456789); > char bar = foo; // instead of bar = static_cast<char>(foo); > > The difference is, the masking warning is a run time check which pops up a > dialog every time the code executes and is thus not as easy to ignore as the > compile warning. If we do: int32 g = 0x01234567; assert( g << 8 == 0x23456700 ); The "01" part has already been shifted away. No amount of masking will fix the data loss that has already occurred. Or do you mean to mask first: assert ( (g & 0x00FFFFFF) << 8 == 0x23456700 ); which gets rid of the "01" part, resetting it to zero, before obliterating it with the shift? All the mask would do is shut up the RTC from a nuisance warning; it doesn't add any worth to the code. Is there something like a "#pragma disable" to shut up RTC around this code, or would you have to deactivate RTC? > -----Original Message----- [I wrote (on 2005-12-16T12:38)] >> On 12/14/05 2:32 PM, "Clarke, Trevor" <tclarke(a)ball.com> wrote: >> >>> There are a few places in crc.hpp where the following happens: >>> static value_type shift( value_type rem ) >>> { return rem << CHAR_BIT; } >>> >>> The problem is, if run time checking is active in VS2003 (I assume 2005 has >>> the same issue), a pop-up warning is issued during every call to the >>> function as data is lost. (that¹s the intent in fact). The fix is to mask >>> (rem << CHAR_BIT) & 0xffff (or whatever the appropriate mask value is for >>> value_type). Is this a known issue? It¹s technically not a bug but could >>> cause some annoyances for anybody using rtc. Should this be changed? >> >> What's the point of the mask? The affected bits have already gone to >> oblivion at that point. Maybe RTC has a bug? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2