- Boost-users - lists.boost.org

google.stringencoders vs (boost.string_algo & boost.lexical_cast)
by Roman Shmelev 01 Jun '09

01 Jun '09

Hi! stringencoders are told to be 2x faster than std approaches. But what about boost? Has somebody tested the performance of both libraries? I mean toLower, toUpper, itoa, dtoa functions. Thank you

4 3

multi_array_ref (lack of) default constructor
by gtsml owevwr 01 Jun '09

01 Jun '09

Hi, Does anybody know why multi_array_ref doesn't have a default constructor? I'm asking because I wanted to make a multi_array of multi_array_ref and that doesn't seem to be possible because multi_array expect the element type to be default constructible. Thanks, Frank

3 6

Re: [Boost-users] boost::serialization and PHP websites
by Brian Wood 01 Jun '09

01 Jun '09

Pascal Kesseli writes: > Currently, I consider the > boost serialization a de-facto standard for C++ serialization issues. In 2007 it wasn't a stretch to say that General Motors was a de facto standard in the automobile industry. Now they want 70 billion from taxpayers. Oh my G-d! -- Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

5 15

Vector types in dynamic_properties used by write_graphml
by Richard Vock 31 May '09

31 May '09

He Folks, I'm using bundled properties in order to attach multiple attributes to graph nodes. Using only basic data types like integers, strings etc. the following example code works well. However I would like to also use vectors or similar containers (like in the example about bundled properties at http://www.boost.org/doc/libs/1_39_0/libs/graph/doc/bundles.html) However I don't know how to use this field for my dynamic_property map. In the following code the single commented-out line is the point where I most probably didn't understand some kind of vital concept. Maybe you could enlighten me or at least point me in the right direction, thanks in advance Richard Vock --- Here's the example code: #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/dynamic_property_map.hpp> #include <boost/graph/graphml.hpp> struct NodeProperties { int test; std::vector<int> ints; }; int main(int argc, char* argv[]) { typedef std::pair<int,int> Edge; std::vector< Edge > connections; // create simple edge loop for testing purposes for (int i=0; i<10; ++i) connections.push_back( Edge(i,(i+1)%10) ); typedef boost::adjacency_list< boost::vecS, boost::vecS, boost::undirectedS, NodeProperties> Graph; Graph g(connections.begin(), connections.end(), 10); boost::graph_traits<Graph>::vertex_iterator v, v_end; for (tie(v,v_end) = vertices(g); v != v_end; ++v) { Graph::vertex_descriptor desc = *v; g[desc].test = 10; for (int i=0; i<5; ++i) g[desc].ints.push_back(i); } boost::dynamic_properties dp; dp.property("test", get(&NodeProperties::test, g)); //dp.property("testInts", get(&NodeProperties::ints, g)); boost::write_graphml(std::cout, g, dp, true); }

1 0

Re: [Boost-users] Bug Sprint Report for Friday, May 29th
by Daniel James 31 May '09

31 May '09

2009/5/30 Marshall Clow <marshall(a)idio.com>: > The following bugs appear to have been fixed, but the tickets were never > closed. > I would appreciate it if the library maintainers could verify this and close > the tickets. > https://svn.boost.org/trac/boost/ticket/145 Iterator Oh, I just closed this as it's certainly fixed. Then I realised that it might have been mentioned on the list and found this. > The following tickets are feature requests that are unlikely ever to be > implemented. > Should they be closed? > https://svn.boost.org/trac/boost/ticket/558 database This one should definitely be closed as 'wontfix'. It's too open ended. There's a better place for ignoring library requests: https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#LibrariesW… > https://svn.boost.org/trac/boost/ticket/100 concept_check > https://svn.boost.org/trac/boost/ticket/182 concept_check I'd close there as well. They're very open ended and nothing to do with concept check. The allocator request could possibly be requested for other libraries. Anyway, they're so old I can't imagine requester has probably given up by now. Daniel

1 0

Boost.Unordered throws 64-bit portability warnings
by Lindley M French 31 May '09

31 May '09

I've noticed on Visual Studio 2005 that I get a slew of warnings from Boost/unordered/detail/hash_table_impl.hpp when I build with "Detect 64-bit portability issues" turned on. In particular at the moment I'm seeing the following warning: boost/unordered/detail/hash_table_impl.hpp(1569) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data And the same on lines 1328, 1569, 1541, 1799, and 1763. I doubt this poses a real problem, but with hash tables you never know. I'd prefer not to see warnings when I build. Can this be fixed, and can regression testing using this build setting be added to the mix in general?

3 5

stlport string vs. std string causing link errors - how to workaround?
by Chris Kruger 31 May '09

31 May '09

Hello everybody, I'm a relatively new user of boost and I have a problem. I believe I know what is causing the problem but I don't yet have a solution and I am looking for suggestions. I'm currently porting a product to Mac OSX. It makes use of both stlport and boost. I have got the software compiling happily enough but I have a couple of link errors that have stumped me for a bit. I believe the link problems are caused by the fact that boost was compiled using the stdlib included with gcc and the code in the product is using stlport. The boost methods causing problems both have stl strings in their arguments. The exact link errors I get is: 1. "boost::filesystem::detail::dir_itr_first(void*&, void*&, stlpmtx_std::basic_string<char, stlpmtx_std::char_traits<char>, stlpmtx_std::allocator<char> > const&, stlpmtx_std::basic_string<char, stlpmtx_std::char_traits<char>, stlpmtx_std::allocator<char> >&, boost::filesystem::file_status&, boost::filesystem::file_status&)" 2. "boost::filesystem::detail::status_api(stlpmtx_std::basic_string<char, stlpmtx_std::char_traits<char>, stlpmtx_std::allocator<char> > const&, boost::system::error_code&)" As you can see the linker is looking for methods that are using stlpmtx_std::basic_string ... i.e. the stlport string The library libboost_filesystem-xgcc40-1_36.dylib as expected contains these basic methods (confirmed by "nm libboost_filesystem-xgcc40-1_36.dylib") but no doubt with std::string I'm using boost 1_36 if that makes any difference and am quite happy to test any assumptions if you don't trust mine. TIA Chris K. http://www.coresoftware.net.au http://www.krugerheavyindustries.com

2 1

Bug Sprint Report for Saturday, May 30th
by Marshall Clow 31 May '09

31 May '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 7:15 AM PDT 5/31: 763 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Re: [Boost-users] Boost Serialization + Forward compatibility [was Re: boost::serialization and PHP websites]
by Brian Wood 31 May '09

31 May '09

Robert Ramey writes: > Sohail Somani wrote: >> I also notice you have not mentioned anything about the 70 billion >> dollar bailout for the serialization library and spreading the >> wealth. I assume the cheque's in the mail. > I purposely overlooked that comment. It seemed to be an > attempt at some sort of criticism. I was pointing out how quickly things changed in the automobile industry. I don't think anyone would argue that the computer industry is less volatile than the automobile industry. I'm also dismayed by the government's investment of billions of dollars in General Motors. (I'm not sure if the amount is closer to 50 billion or 70 billion.) > It's absolutely amazing to > me how much I've been criticised (many times personally) > for making this library. I'm not sure if you are referring to me there. I have at times pointed out what I consider to be weaknesses of the serialization library. I don't think I've criticised you personally. Regards, Brian Wood Ebenezer Enterprises www.webEbenezer.net

3 2

boost::thread Compile error with Sun Studio 12
by Roman Morokutti 30 May '09

30 May '09

Hi, When I compile the example on the boost::thread documentation (the source is wrapped by a main function): #include <stdlib.h> #include <boost/thread.hpp> /* * */ int main(int argc, char** argv) { boost::system_time const timeout = boost::get_system_time() + boost::posix_time::milliseconds(500); extern bool done; extern boost::mutex m; extern boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); while (!done) { if (!cond.timed_wait(lk, timeout)) { throw "timed out"; } } boost:: return (EXIT_SUCCESS); } I get the error CC -library=stlport4 -mt -c -g -I/opt/boost/boost_1_39_0 -o build/Debug/SunStudio-Solaris-x86/thread.o thread.cpp "/opt/boost/boost_1_39_0/boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost::thread>). 1 Error(s) detected. So could anyone tell me how to bypass this error, or should the library be updated? -Roman

3 11