September 2009 - Boost-users - lists.preview.boost.org

Bug in serialization::make_nvp?
by stair314 05 Sep '09

05 Sep '09

I'm sorry if this appears twice; I received an e-mail saying it couldn't be sent because I hadn't subscribed to the mailing list. When I run the following code, I get this error: terminate called after throwing an instance of 'boost::archive::xml_archive_exception' what(): uninitialized exception Abort However, if I substitute BOOST_SERIALIZATION_NVP for the make_nvp function, it works fine. Am I doing something wrong, or is this a bug? #include <iostream> #include <fstream> #include <string> #include <boost/config.hpp> #if defined(BOOST_NO_STDC_NAMESPACE) namespace std{ using ::remove; } #endif #include <boost/archive/tmpdir.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/nvp.hpp> class A { public: A() {} virtual ~A() {} int a; private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { //ar & BOOST_SERIALIZATION_NVP(a); ar & boost::serialization::make_nvp("example field",a); }; }; void restore( const char * filename) { A s; // open the archive std::ifstream ifs(filename); assert(ifs.good()); boost::archive::xml_iarchive ia(ifs); // restore the schedule from the archive ia >> BOOST_SERIALIZATION_NVP(s); } int main(int argc, char *argv[]) { std::string filename("/tmp/wtf.xml"); { A s; // make an archive std::ofstream ofs(filename.c_str()); assert(ofs.good()); boost::archive::xml_oarchive oa(ofs); oa << BOOST_SERIALIZATION_NVP(s); } printf("---\n"); restore( filename.c_str()); return 0; } -- View this message in context: http://www.nabble.com/Bug-in-serialization%3A%3Amake_nvp--tp25304627p253046… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex
by Rajeev Rao 04 Sep '09

04 Sep '09

Could the problem be with the way I built the boost libraries? I used no options when doing the build. looks like boost::mutex doesn't have the problem (when used with unique_lock). So I guess the problem is in shared_mutex. Rajeev --- On Thu, 9/3/09, Steven Watanabe <watanabesj(a)gmail.com> wrote: From: Steven Watanabe <watanabesj(a)gmail.com> Subject: Re: [Boost-users] valgrind reports memory still reachable when using shared_lock and shared_mutex To: boost-users(a)lists.boost.org Date: Thursday, September 3, 2009, 9:40 AM AMDG Rajeev Rao wrote: > I found similar problems when getting an exclusive lock via unique_lock as well. I wrote this test code to reproduce. I get the still-reachable problem if I use either the read() or the write() call (shared_lock or unique_lock). Multiple calls to these functions did not increase the number of reachable bytes in the valgrind report. I understand my previous use of adopt_lock was undefined (hence i've not used it here). Is my use as described by the code correct now ? If so, is this a bug ? > It is almost certainly exactly the same as with shared_lock. The code that allocates the object is in a lower level component. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 2

[boost::asio]Question about how to properly make several async requests (reads and writes)
by Matheus Araújo Aguiar 04 Sep '09

04 Sep '09

Dear list, I have learned that one cannot make several async write requests, one after another, without waiting for the completion of each request, otherwise the bytes get merged and the messages will not make sense at the receiving side. I am correct assuming that, right? My doubt is if the same happens to async read requests. Does one have to wait a read request completes before issuing another? Will the bytes get merged too, if one does not wait before making another read request? Assuming things happen that way, one async request waiting for the completion of another earlier request, then one have serial I/O processing and if one wants to have things done in parallel, the simplest way would be having other(s) thread(s) reading and writting in the same I/O object. Is this correct? I hope I have made my doubts clear enough, and if it is not clear please say it and i will try to be more objective. Regards, -- Matheus Araújo Aguiar Computer Scientist matheus.pit(a)gmail.com

3 5

[statechart] Pass event data to state constructor?
by Bill Clark 04 Sep '09

04 Sep '09

I'd like to be able to communicate the data from an event to the state(s) that get constructed as a result of a transition. I don't see an obvious way to do that, since the constructors of a state object either take only a context parameter (this is in an asychronous_state_machine), or also take a transition action plus an event. I can save the event data within the context object and then retrieve it post-construction, but that seems error-prone. Is there a better way to do this? Thanks, Bill

2 8

BGL vertex(std::size_t i, Graph) is in no concept
by Sebastian Weber 04 Sep '09

04 Sep '09

Hi! If I am not wrong, then the vertex(std::size_t i, Graph) function is required in no graph concept at all. However, adjacency_list defines it and csr-graphs use it ... Did I overlook something or shouldn't the function belong to some graph concept? Sebastian

3 5

Correct use of unordered_map
by John Dlugosz 04 Sep '09

04 Sep '09

Consider this loop: const my_map_t::iterator end= my_map.end(); for (my_map_t::iterator it= my_map.begin(); it != end; ++it) { if (is_to_be_removed(it->first)) global_map.erase (it); } The documentation I've seen for unordered_map says that removing doesn't invalidate iterators except those referring to the element being deleted. But that's the case for it itself! Also, what does removing one element do to the ordering of the elements -- is there any guarantee that the iterator will visit exactly the ones that were not visited before? What is the correct, standards-conforming, way to perform this? Thanks, --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

5 13

integer to string or char
by pedro chaparro 04 Sep '09

04 Sep '09

hi, i'd like to know what is the equivalent command to itoa in boost? i have to convert a variable from integer to string. how can i do that? thanks -- Ing Pedro Alonso Chaparro Valero Ciudad Politecnica de la Innovación iTEAM - Mobile Communications Group Polytechnic University of Valencia C\ Camino de Vera S/N, Edificio 8G 46022 Valencia, Spain

2 1

Building Boost 1.40.0 with MPI on SUN HPC Developer distribution fails
by Volker Mosert 04 Sep '09

04 Sep '09

Hi, I'm trying to use the Boost MPI library in a virtual Opensolaris environment (specifically the Sun HPC Software, Developer Edition 1.0 for OpenSolaris). System compiler is the sun studio 12u1 compiler. MPI is provided by the Sun HPC ClusterTools which essentially means Open MPI. Trying to build results in following error messages: sun.compile.c++ bin.v2/libs/mpi/build/sun/release/stdlib-sun-stlport/threading-multi/python/py_communicator.o "./boost/mpi/graph_communicator.hpp", line 62: Warning: comm_ptr hides boost::mpi::communicator::comm_ptr. "./boost/mpi/intercommunicator.hpp", line 62: Warning: comm_ptr hides boost::mpi::communicator::comm_ptr. "libs/mpi/src/python/py_communicator.cpp", line 107: Error: Could not find a match for boost::python::class_<b oost::mpi::communicator, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::py thon::detail::not_specified>::def<boost::python::class_<boost::mpi::communicator, boost::python::detail::not_s pecified, boost::python::detail::not_specified, boost::python::detail::not_specified>::Derived>(const char[12] , bool(*)()const) needed in boost::mpi::python::export_communicator(). "libs/mpi/src/python/py_communicator.cpp", line 107: Error: Could not find a match for boost::python::class_<b oost::mpi::communicator, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::py thon::detail::not_specified>::def<boost::python::class_<boost::mpi::communicator, boost::python::detail::not_s pecified, boost::python::detail::not_specified, boost::python::detail::not_specified>::Derived>(const char[12] , bool(*)()const) needed in boost::mpi::python::export_communicator(). "libs/mpi/src/python/py_communicator.cpp", line 107: Error: Could not find a match for boost::python::class_<b oost::mpi::communicator, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::py thon::detail::not_specified>::def<boost::python::class_<boost::mpi::communicator, boost::python::detail::not_s pecified, boost::python::detail::not_specified, boost::python::detail::not_specified>::Derived>(const char[12] , bool(*)()const) needed in boost::mpi::python::export_communicator(). "libs/mpi/src/python/py_communicator.cpp", line 107: Error: Could not find a match for boost::python::class_<b oost::mpi::communicator, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::py thon::detail::not_specified>::def<boost::python::class_<boost::mpi::communicator, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>::Derived>(const char[12], bool(*)()const) needed in boost::mpi::python::export_communicator(). 4 Error(s) and 2 Warning(s) detected. "CC" -library=stlport4 -xO4 -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I"." -I"/opt/SUNWhpc/HPC8.1/sun/include" -I"/opt/SUNWhpc/HPC8.1/sun/include/openmpi" -I"/usr/include/python2.4" -c -o "bin.v2/libs/mpi/build/sun/release/stdlib-sun-stlport/threading-multi/python/py_communicator.o" "libs/mpi/src/python/py_communicator.cpp" sun.compile.c++ bin.v2/libs/mpi/build/sun/release/stdlib-sun-stlport/threading-multi/python/datatypes.o "./boost/mpi/graph_communicator.hpp", line 62: Warning: comm_ptr hides boost::mpi::communicator::comm_ptr. "./boost/mpi/intercommunicator.hpp", line 62: Warning: comm_ptr hides boost::mpi::communicator::comm_ptr. "./boost/mpi/python/serialize.hpp", line 276: Error: Could not find a match for boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::register_type<boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::T>(boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::default_saver<long>, boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::default_loader<long>, const long, _typeobject*) needed in boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::register_type<long>(const long&, _typeobject*). "./boost/mpi/python/serialize.hpp", line 389: Where: While instantiating "boost::python::detail::direct_serialization_table<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive>::register_type<long>(const long&, _typeobject*)". "./boost/mpi/python/serialize.hpp", line 389: Where: Instantiated from boost::python::register_serialized<boost::mpi::packed_iarchive, boost::mpi::packed_oarchive, long>(const long&, _typeobject*). "./boost/mpi/python/serialize.hpp", line 534: Where: Instantiated from boost::mpi::python::register_serialized<long>(const long&, _typeobject*). "libs/mpi/src/python/datatypes.cpp", line 20: Where: Instantiated from non-template code. 1 Error(s) and 2 Warning(s) detected. "CC" -library=stlport4 -xO4 -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I"." -I"/opt/SUNWhpc/HPC8.1/sun/include" -I"/opt/SUNWhpc/HPC8.1/sun/include/openmpi" -I"/usr/include/python2.4" -c -o "bin.v2/libs/mpi/build/sun/release/stdlib-sun-stlport/threading-multi/python/datatypes.o" "libs/mpi/src/python/datatypes.cpp" I would be nice if someone helped me resolving this issue. A second problem was the missinterpretation of ">>" in a template argument by the sun compiler. I resolved that by changing the file "boost/archive/detail/register_archive.hpp". (I probably overcompensated with white spaces) 57c57 < get_counter<Archive>::next adjust_counter(get_counter<Archive>::type);\ --- > get_counter< Archive >::next adjust_counter(get_counter< Archive >::type);\ 60,62c60,62 < get_counter<Archive>::type) { \ < ptr_serialization_support<Archive, Serializable> x; \ < instantiate_ptr_serialization(s, get_counter<Archive>::prior()); \ --- > get_counter< Archive >::type) { \ > ptr_serialization_support< Archive, Serializable > x; \ > instantiate_ptr_serialization(s, get_counter< Archive >::prior()); \ 84c84 < BOOST_DEDUCED_TYPENAME _ptr_serialization_support<Archive, Serializable>::type \ --- > BOOST_DEDUCED_TYPENAME _ptr_serialization_support< Archive, Serializable >::type \ ciao, Volker

1 0

[iterator] Does the base of iterator_adaptor need a const version of operator* ?
by Andre Massing 04 Sep '09

04 Sep '09

Hi, I am trying to wrap our kind of iterators (for meshes) with the iterator_adaptor class template, something like class CellBoostIterator : public boost::iterator_adaptor< CellBoostIterator //Derived , CellIterator //Base , Cell //Value , boost::forward_traversal_tag // CategoryOrTraversal > { ... }; Since the base class CellIterator already provides a operator* and a operator-> (both non-const version) I did not redefine any of these within the CellBoostIterator class. If I now want to use with code-snippet typedef Mesh_2::CellBoostIterator MIT; MIT mit; Mesh_2 mesh_2(omega1); for (MIT mit = mesh_2.begin(); mit != mesh_2.end(); ++mit) { std::cout << mit->index() <<std::endl; } I get a compile error /usr/include/boost/iterator/iterator_adaptor.hpp:312: error: passing ‘const dolfin::CellIterator’ as ‘this’ argument of ‘dolfin::Cell& dolfin::CellIterator::operator*()’ discards qualifiers I looked at the corresponding line /usr/include/boost/iterator/iterator_adaptor.hpp:312: typename super_t::reference dereference() const { return *m_iterator; } So it seems to me that I have to provide a const version of operator*, or do I get something wrong? I am a bit confused, since I have not found this kind of requirements in the documentation. Any enlightening, hints or pointers are greatly appreciated! Greetings, Andre

1 0

1.40 and pch - gcc problems?
by Jonathan Brannan 04 Sep '09

04 Sep '09

I just got 1.40 and tried building. I kept having some pieces fail with a complete build, sometimes I had gcc that ran until resources exausted, sometimes the compiler would segfault. Eventaully I tracked it down to the math library. After noticing the many errors from the gch (things like : error _REENTERANT not defined or used diffrent -fpic). I disabled pch for the math library (actually the boost project and the libs/math/test) and I did not have any more issues. This is how I compiled it: ./bootstrap.sh --without-icu --prefix=ID_1_40_0 ./bjam install stage --prefix=/path/to/install -j 16 --buildid=ID_1_40_0 --layout=tagged --build-type=complete --stagedir=/path/to/install The system is sles (suse enterprise) 11. It's an 8 core intel machine. gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) I did not figure out how to disable this via the command line, so I did this: *** boost_1_40_0-compiled/Jamroot 2009-08-23 12:17:37.000000000 -0400 --- boost_1_40_0-new/Jamroot 2009-09-03 13:25:05.000000000 -0400 *************** *** 177,182 **** --- 177,183 ---- # Disable auto-linking for all targets here, primarily because it caused # troubles with V2. <define>BOOST_ALL_NO_LIB=1 + <toolset>gcc:<pch>off # Used to encode variant in target name. See the 'tag' rule below. <tag>@$(__name__).tag <conditional>@handle-static-runtime *** boost_1_40_0-compiled/libs/math/test/Jamfile.v2 2009-07-23 05:45:33.000000000 -0400 --- boost_1_40_0-new/libs/math/test/Jamfile.v2 2009-09-03 13:24:40.000000000 -0400 *************** *** 23,28 **** --- 23,29 ---- <toolset>intel:<linkflags>-nologo #<toolset>intel-linux:<pch>off <toolset>intel-darwin:<pch>off + <toolset>gcc:<pch>off <toolset>msvc:<warnings>all <toolset>msvc:<asynch-exceptions>on <toolset>msvc:<cxxflags>/wd4996

3 2