May 2008 - Boost-users - lists.preview.boost.org

[Conversion] imprecision with lexical_cast from double to std::string
by Andreas Ries 30 Jul '08

30 Jul '08

Hi, I'm using the borland toolset 5.8.2 under Win XP and have a problem doing the following: double val = 795.6352; string result = boost::lexical_cast <string> (val); the resulting string is: "795.63520000000005" with boost 1_35_0 the resulting string is: "795.6352000000001" with boost_1_34_0 Can anybody help?

3 2

Is there a something in boost to facilitate binary buffer transformations into typed data structures/classes?
by Graham Reitz 28 Jul '08

28 Jul '08

I didn't see anything, but I may have missed something. Problem: Binary data is stored in a char buffer from a proprietary device: char* buffer = new char[6]; Data in buffer: [byte 1][byte 2][byte 3][byte 4][byte 5][byte 6] [---16 bit uint--][------------32 bit uint-------------] ...would like to convert to this in a C++'ish style using a boost facility if it exists: (or consider directing me somewhere else if it doesn't) struct // or class { boost::uint16_t first; boost::uint32_t second; } data; I would like to avoid a C-style way of doing this. This seems like something that would have been solved many times. thanks, graham

4 8

[statechart] history transitions make state-local-storage "un-cool"
by Mick Hollins 26 Jun '08

26 Jun '08

Apologies if this has been discussed before, but I couldn't find any mention of it: I am currently using the history facility of boost::fsm. I've discovered that when I re-enter a state, X, via a history transition I don't actually re-enter the same instance of X that I was in before, but instead enter a newly constructed instance of X. I just checked the UML spec regarding history transitions and it says that "Any necessary entry actions are performed", so given that boost::fsm uses constructors to represent entry actions I guess a new instance of X has to be constructed to ensure UML compliance. My actual concern is the effect this has on the "coolness" of state-local-storage (see http://boost-sandbox.sourceforge.net/libs/statechart/doc/faq.html#Whats_so_…) It seems to me that state-local-storage, which I agree is generally cool, is particularly un-cool (and bug-inducing) in the presence of history transitions. I'm not sure what a good alternative is, but just thought I'd raise the discussion. cheers, mick PS: does the history facility display the same semantics in boost::statechart? I plan to move to statechart real soon now ...

4 19

[DateTime] 1.35.0: Patch to fix typo
by peter.klotz＠ith-icoserve.com 24 Jun '08

24 Jun '08

The attached patch fixes a typo in boost/date_time/gregorian/greg_weekday.hpp. Best regards, Peter.

2 1

is there strided iterator already available somewhere?
by e r 10 Jun '08

10 Jun '08

hello, is there strided iterator already available somewhere? iter = vec.begin(); std::advance(iter,offset) for(unsigned int i=0; i<(vec.size()-offset)/stride; ++i){ /* do something with iter */ std::advance(iter,stride) } alternatively, a permutation iterator does not seem very practical here... thanks, e.

2 2

serialization, 1.34/1.35 difference: serializing a vector
by Filip Peters 08 Jun '08

08 Jun '08

I just tried serializing a simple vector, std::vector<unsigned int> vectortest; If I serialize out in 1.34, I can't read it in in 1.35. xml result from 1.35: <vectortest> <count>3</count> <item>1</item> <item>2</item> <item>3</item> </vectortest> from 1.34: <vectortest> <count>3</count> <item_version>0</item_version> <item>1</item> <item>2</item> <item>3</item> </vectortest> Notice the item_version, this causes an exception when reading it in with 1.35.... I need a way to get the behavior from 1.34 back.... Otherwise my files aren't readable anymore. small testprogram: #include <boost/config.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> //#include <boost/archive/binary_iarchive.hpp> //#include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/export.hpp> #include <fstream> #include <iomanip> int _tmain(int argc, _TCHAR* argv[]) { std::vector<unsigned int> testvector; testvector.push_back(1.); testvector.push_back(2.); testvector.push_back(3.); //this in 1.34 std::ofstream ofs( "testing2.txt", std::ios::binary ) ; boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp("vectortest", testvector); ofs.close(); //do this in 1.35 try{ std::ifstream ofs( "testing2.txt", std::ios::binary ) ; boost::archive::xml_iarchive ia(ofs); ia >> boost::serialization::make_nvp("vectortest", testvector2); ofs.close(); } catch(boost::archive::archive_exception testexception){ //reading a file from 1.34, will end up here std::string error = testexception.what(); } return 0; } ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com

5 6

[xpressive] compilation woes with gcc 3.3.3
by Christoph Duelli 03 Jun '08

03 Jun '08

compiling #include <boost/xpressive/regex_actions.hpp> fails with gcc version 3.3.3 (SuSE Linux) (running SuSE LES9) Any chance that might be fixed? Anything I can do about it?

4 8

[boost::test] running unit tests from DLL with automatic registration facility
by Ovanes Markarian 03 Jun '08

03 Jun '08

Hello Gennadiy, using boost 1.35 & console runner and MSVC 2005 we did the following test: FunctionalityDLL ^ | UnitTestDLL ^ | ConsoleTestRunner.EXE (as distributed in the example directory) UnitTest.DLL had the following defines: #ifndef BOOST_TEST_DYN_LINK # define BOOST_TEST_DYN_LINK #endif #ifndef BOOST_TEST_MODULE # define BOOST_TEST_MODULE example #endif #include <boost/test/unit_test.hpp> We spent some time to figure out how to cause ConsoleTestRunner.exe to find the init_unit_test function. Finally we end up looking to preprocessed code: There we found the function: bool init_unit_test() { using namespace ::boost::unit_test; assign_op( framework::master_test_suite().p_name.value, boost::unit_test::const_string( "example", sizeof( "example" ) - 1 ).trim( "\"" ), 0 ); return true; } Only after taking the function over to the cpp module (removing BOOST_TEST_MODULE define) adding the DLL export statement and adding the C-Linkage ConsoleTestRunner was able to find the address of this function. So the compilation unit looked like: #ifndef BOOST_TEST_DYN_LINK # define BOOST_TEST_DYN_LINK #endif #include <boost/test/unit_test.hpp> #include "TestsDLL.h" extern "C" __declspec(dllexport) bool init_unit_test() { using namespace ::boost::unit_test; assign_op( framework::master_test_suite().p_name.value, boost::unit_test::const_string( "example", sizeof( "example" ) - 1 ).trim( "\"" ), 0 ); return true; } BOOST_AUTO_TEST_SUITE( FunctionalityDLLTest ) BOOST_AUTO_TEST_CASE( test1 ) { BOOST_WARN( sizeof(int) < 4 ); } BOOST_AUTO_TEST_CASE( test2 ) { BOOST_REQUIRE_EQUAL( 1, 2 ); BOOST_FAIL( "Should never reach this line" ); } BOOST_AUTO_TEST_SUITE_END() Only after these modifications we were able to compile and run unit tests. Is there any chance to either update the docs with this example so that it becomes a sort of guarantee how it might work, or let the combination of BOOST_TEST_MODULE and BOOST_TEST_DYN_LINK generate the right linkage specification and export the symbol, otherwise this symbol was not found with GetProcAddress. With Kind Regards, Ovanes

2 1

Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector
by Filip Peters 03 Jun '08

03 Jun '08

----- Original Message ---- From: "Pfligersdorffer, Christian" <Christian.Pfligersdorffer(a)eos.info> To: boost-users(a)lists.boost.org Sent: Friday, April 4, 2008 6:30:00 AM Subject: Re: [Boost-users] serialization, 1.34/1.35 difference: serializing a vector Hello everybody, we at EOS too rely heavily on backwards compatibility of boost::serialization so I read this topic with great interest. And found Filip's discovery quite shocking I must say! I tried the testing program on my machine using boost-1.33.1 and boost-1.35 and all of the boost::archives. And guess what: It worked!! Soooo, this is quite confusing! Either version 1.34 breaks the compatibility or Filip's observation is wrong. Or mine, as everything might depend on the machine architecture or some other nasty detail... Is think this has to be investigated closer. Very interesting. I dug up the zip file for 1.33.1 and ran a couple of tests. (mostly to prove myself that I'm not seeing ghosts.) result: from 1.33.1 to 1.34: no problem from 1.33.1 to 1.35: no problem from 1.34.1 to 1.35: problem. problem seems to be a new "optimization" in the vector serializing. I normally use the binary files, but for debugging purposes the xml output is fantastic. It shows exactly why it works/doesn't work. xml from 1.33.1: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <vectorToSave> <count>2</count> <item>0</item> <item>1</item> </vectorToSave> </boost_serialization> xml from 1.34.1: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="4"> <vectorToSave> <count>2</count> <item_version>0</item_version> <item>0</item> <item>1</item> </vectorToSave> </boost_serialization> xml from 1.35: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="4"> <vectorToSave> <count>2</count> <item>0</item> <item>1</item> </vectorToSave> </boost_serialization> As you can clearly see, from 1.34.1 to 1.35, the archive version stayed at 4, while item_version went missing in 1.35. Btw: my portable binary archive which really does nothing more than endian handling on top of the binary archive was broken by version 1.34 too (wrt reading files generated by 1.33.1). It has to do with the serialization of std collections as well, that much I found out. I did not do extensive investigation then but simply did not migrate. I may have time to take a closer look in the near future though. Regards, -- Christian Pfligersdorffer Software Engineering http://www.eos.info PS: Jens wrote: > Have you reported these issues? Please remember that once you > start testing development versions, especially release > snapshots, you could ensure that such issues are fixed before the > release! Never forget that there users who are not so involved in the boost community, be it for the lack of interest or simply because they are engaged in projects that leave no room for testing of upcoming library versions. Between the announcement and the official release there was less than a laughable day... Exactly. I didn't check the boost list in the previous two weeks (busy with an internal release myself), so wasn't really aware that there was rc2 and rc3.(heck, was rc1 even announced on the users list?) Monday I checked and saw that the boost website was updated, and a nice new version. When I got everything to compile, I noticed that I couldn't read in some older files. So I made a sample program, and reported the output. I also opened a trac ticket for this. Filip Peters. ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com

3 3

Is there any class that can promote a type to the complex type?
by Peng Yu 02 Jun '08

02 Jun '08

Hi, To promote a type, no matter complex or not, to the complex type can be done by the following code. RET would give me a complex type. The code is simple. I'm wonder if boost has already supplied such facility so that I don't have to include the following snippet in my own code. Thanks, Peng #include <complex> #include <iostream> template <typename T> struct convert { typedef std::complex<T> RET; }; template <typename T> struct convert<std::complex<T> > { typedef std::complex<T> RET; }; int main() { std::cout << convert<double>::RET() << std::endl; std::cout << convert<std::complex<double> >::RET() << std::endl; }

4 8