August 2010 - Boost-users - lists.preview.boost.org

Fwd: Some trouble using mutexes
by Ernest Galbrun 30 Aug '10

30 Aug '10

Ok, thank you for your reply, I have been away for a week and I am back to work, with this problem still preventing my program to work fine. To answer your question, I have only one Robot in my project (for now) and the io_service is a Robot member. I now get why the active_count goes negative when the count goes up, but now I can't figure how it can ever be incremented twice. When debugging, I see the active_count being either 0, -2147483648, OR -2147483647. In fact, even when the active_count is not ==0, the lock() call returns instantly. Any clue ? Ernest Galbrun. > > Ernest Galbrun wrote: > > I would be really grateful if someone could give me a hint about what I > am > > doing wrong with the mutex and thread class (I am using boost 1.43, on > > windows XP running visual c++ 2010, the library has been built using the > > bjam utility). > > > > I have a main thread that creates an object of class robot : > > > > class Robot > > { > > private: > > boost::mutex tcpLock; > > boost::thread continuousThread; > > ... > > } > > > > Robot k3; > > > > this thread launches a thread that makes continuous calls to a member > > function of the robot. Since this function uses network ressources, I > want > > it to be safe so i use a lock The function called is the only function in > my > > program that uses this lock : > > > > int Robot::sendMsg(string msg, int n, vector<string>* answer) > > { > > tcpLock.lock(); > > (do stuff with the tcp io service) > > tcpLock.unlock(); > > return 0; > > } > > > > Of course, I also call this function from the main thread. > > > > And I have disruptive behavior, which I don't understand. > > Do you have multiple Robots? Is the io_service shared between them? > > > When debugging, I > > see that the 'active_count' of the tcpLock object stays negative or ==0, > > which seem absolutely wrong to me, but I don't understand how it could > ever > > be anything other than 0 or 1. > > > > The implementation indicates that the mutex is locked with the > high-order bit, which means that a locked mutex will have > a negative active count. > > In Christ, > Steven Watanabe >

1 0

boost transfer pointers by serialize
by Jack Bryan 29 Aug '10

29 Aug '10

Dear All, I need to transfer some pointers from one process to another process on Open MPI cluster. These pointers are members of a class. They are like: class myClass{double *;int *;double**; } When I use serialize in boost , I got errors: /boost/serialization/access.hpp:118: error: request for member âserializeâ in âtâ, which is of non-class type âdoubleâ Any help is appreciated. JACK Aug. 29 2010

2 5

boost thread - bug pthread
by Kraus Philipp 29 Aug '10

29 Aug '10

Hi, I'm writing a multithread application and I test my program with valgrind. I create a thread group and valgrind shows this message: ==4608== Thread #1: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==4608== at 0x503FC: pthread_cond_wait* (hg_intercepts.c:653) ==4608== by 0x19C3B7: boost::thread::join() (in libboost_thread.dylib) ==4608== by 0x15D8C: boost::thread_group::join_all() (in ./main) I use Boost 1.44 on OSX 10.5. How can I solve this "Bug"? Thanks Phil

1 0

string algo - documentation bug?
by mafeusek＠gmail.com 29 Aug '10

29 Aug '10

Hallo Group Members. in http://www.boost.org/doc/libs/1_44_0/doc/html/string_algo/concept.html I can read: * Function Finder. Finder can be any function object. That is, any ordinary function with the required signature can be used as well. However, such a function can be used only for a specific iterator type. boost::iterator_range<std::string> simple_finder( std::string::const_iterator Begin, std::string::const_iterator End ) { return boost::make_range( Begin, End ); } but following code does not compile: #include <iostream> #include <string> #include <boost/algorithm/string.hpp> #include <boost/range.hpp> int main(int argc, char *argv[]) { boost::iterator_range<std::string> dd; return 0; } As I understand, I need to put iterator as template parameter to iterator_range, thus: #include <iostream> #include <string> #include <boost/algorithm/string.hpp> #include <boost/range.hpp> /* boost::iterator_range<std::string> simple_finder( std::string::const_iterator Begin, std::string::const_iterator End ) { return boost::make_range( Begin, End ); } */ int main(int argc, char *argv[]) { boost::iterator_range<std::string::iterator> dd; return 0; } compiles ok. Is it documentation bug? best regards, Pawel

1 0

Any stream class for C standard FILE * streams ?
by Timothy Madden 29 Aug '10

29 Aug '10

Hello Is there a stream class in boost that would use a C standard FILE * stream as the buffer ? Thank you, Timothy Madden

2 1

Multiple link errors when using boost 1.44 boost::filesystem and gcc 4.1.2 on CentOS 5.5
by Potato Soup 29 Aug '10

29 Aug '10

I have installed gcc 4.1.2 (from Cent OS 5.5 repos), boost 1.44, and built all the libraries. I am able to link to all other libraries I try. As soon as I so much as add the include for boost::filesystem, and attempt to build my single .cpp file, I get the following errors: In function `__static_initialization_and_destruction_0(int, int)': testbuild.cpp:(.text+0xfa): undefined reference to `boost::system::generic_category()' testbuild.cpp:(.text+0x106): undefined reference to `boost::system::generic_category()' testbuild.cpp:(.text+0x112): undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status The linking stage fails and despite hours of googling I see no clear solution. I would be grateful for any advice on how to move past this, as it's the only thing holding me back from developing with boost. To be clear again, simply including <boost/filesystem.hpp> is enough to cause this when performing a link against libboost_filesystem.a.

2 1

boost serialize error
by Jack Bryan 29 Aug '10

29 Aug '10

Dear All: I am trying to use boost (1.43) serialize to transfer data. But I got errors: ---------------------------------------------------------------- path/boost_1_43_0/boost/config/stdlib/libstdcpp3.hpp:40:1: warning: "BOOST_HAS_THREADS" redefined<command line>:1:1: warning: this is the location of the previous definitionpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = int*]âpath/boost_1_43_0/boost/archive/detail/iserializer.hpp:182: instantiated from âvoid boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_iarchive, T = int*]â myProg.cpp:413: instantiated from herepath/boost_1_43_0/boost/serialization/access.hpp:118: error: request for member âserializeâ in âtâ, which is of non-class type âint*âpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_iarchive, T = double]âpath/boost_1_43_0/boost/archive/detail/iserializer.hpp:182: instantiated from âvoid boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_iarchive, T = double]â myProg.cpp:413: instantiated from herepath/boost_1_43_0/boost/serialization/access.hpp:118: error: request for member âserializeâ in âtâ, which is of non-class type âdoubleâpath/boost_1_43_0/boost/serialization/access.hpp: In static member function âstatic void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]â:path/boost_1_43_0/boost/serialization/serialization.hpp:74: instantiated from âvoid boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]âpath/boost_1_43_0/boost/serialization/serialization.hpp:133: instantiated from âvoid boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_oarchive, T = int*]âpath/boost_1_43_0/boost/archive/detail/oserializer.hpp:148: instantiated from âvoid boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::mpi::packed_oarchive, T = int*]â ---------------------------------------------------------------- It does not indicate the line number of my program with errors. The 413 is the last line of myProg.cpp. What is the meaning of "request for member serialize in t, which is of non-class type double" ? Any help is appreciated. Jack Aug. 28 2010

1 0

Fwd: Bundled properties for GraphProperties
by Saeed Nari 29 Aug '10

29 Aug '10

Hi all, I wonder if I can use a user defined class (bundled property) as a GraphProperty. The documentation just says about vertex and edge properties. Actually I could compile the below line with no errors: typedef adjacency_list<listS, vecS, directedS, vClass, eClass, gClass> Graph; vClass, eClass and gClass are my own classes. I don't know how to access the members from gClass anyway. Graph g; Vertex v; Edge e; g[v].vMember and g[e].eMember work fine. But I get error for g.gMember. Thanks Saeed

4 3

Is Boost-CMake Dead or Alive?
by Michael Jackson 28 Aug '10

28 Aug '10

http://ryppl.org/news/ So the boost-svn tracking is now hosted at Github. Ok. If you read farther down the page then it looks like Boost-CMake really _is_ going to be resurrected in the future? Is there any current activity with respect to Boost and git and cmake? I am so confused. I was going to take over for Troy S. in getting Boost-CMake ready after each release but if there is "Official" work doing this then I am not going to waste me time. Clarifications would be wonderful at this point. Thanks Mike Jackson

5 5

Any class for a buffer or temporary file ?
by Timothy Madden 28 Aug '10

28 Aug '10

Hello Is there a class or stream class in boost to implement a buffer that will use memory storage fro small data sizes, and disk storage in temporary files for large data sizes ? Or is there a (random-access) file stream class to open some unnamed or temporary file that will automatically be deleted after closing ? Thank you, Timothy Madden

1 0

[filesystem] Using filesystem library from Boost version 1.44 on Cygwin 1.7
by Clarke, Carus V 27 Aug '10

27 Aug '10

I have been using the filesystem library from Boost version 1.43 on a Cygwin 1.7.6-1 platform without any problems. The library was built using the Cygwin version of GCC 4.3.4. The library from the 1.44 version of Boost compiles compiles o.k., but the functions that access files no longer work. This appears to be true for both versions 2 and 3 of the library. Below is a simple program that runs o.k. with the Boost version 1.43 version of the library. The program runs but can not read the file status using Boost version 1.44. This program also works fine when built using MSVC 9.0 and Boost version 1.44. Am I doing something wrong? Any help would be appreciated. Thanks, Carus V. (Bud) Clarke carus.v.clarke(a)boeing.com //-------------------- #include <fstream> #include <iostream> #include <string> #include <boost/version.hpp> #define BOOST_FILESYSTEM_NO_DEPRECATED # if !defined(BOOST_FILESYSTEM_VERSION) # define BOOST_FILESYSTEM_VERSION 3 // disabled: # define BOOST_FILESYSTEM_VERSION 2 # endif #include <boost/filesystem.hpp> #include <boost/system/error_code.hpp> int main() { namespace boost_fs = boost::filesystem; const std::string pathStr = "foo"; std::ofstream ostrm(pathStr.c_str()); if (ostrm) { ostrm << "abcde-12345" << std::endl; ostrm.close(); } boost_fs::path path(pathStr); boost::system::error_code ec; std::cout << std::boolalpha; std::cout << "Checking status of file " << pathStr << "..." << std::endl; boost_fs::file_status st = boost_fs::status(path, ec); std::cout << "Error code value: " << ec.value() << std::endl; std::cout << "Error code message: " << ec.message() << std::endl; return 0; } //-------------------- This program's output on my system is shown below. The file 'foo' is written by the program and does actually exist. For version 2: boost::filesystem library version is v2 Checking status of file foo... Error code value: 0 Error code message: The operation completed successfully Does file exist? false For version 3: boost::filesystem library version is v3 Checking status of file foo... Error code value: 2 Error code message: The system cannot find the file specified Does file exist? false //--------------------

2 1

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Boost.MPI] question about serializingcustomobject
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >David Abrahams wrote: >>>> And since Boost.MPI and Boost.Serialization are so closely >>>> related, I think it's especially important that *you* underestand. >>> >>> I disagree. Boost MPI depends upon Boost.Serialization >>> but not the other way around. >> >> I didn't say they were interdependent, just that they were >> closely-related. But anyway, I think you're being shortsighted: The >> success of tools built on top of Boost.Serialization is an important >> indicator of the correctness and genericity of its design. > >> Boost.Serialization *is* dependent on Boost.MPI for a portion of its >> userbase, > ><off topic> what portion of the user base? (This is a rhetorical question >please don't spend any time answering it.) It's always bothered me >that we have no per library data/feedback on the interest/usage >on a library by library basis. I've spoken about this before and >I know you agree with me about it. But until this get's addressed >I think we just have to set these questions aside and recognize >that the answers are anyone's guess. > ><snip> > >> You can't be a generic serialization library without reference to real >> applications. Maybe you still haven't really decided whether serving >> Boost.MPI and its users is something you want to do. > > I think that >> might account for a good deal of the recurring friction we experience. >> It would be a good idea to settle on an answer to that question, along >> with the question of what other applications you're willing to >> support. > >I am acutely aware of this aspect of "generic library design". Every >post on this list reminds me of it. > >>> I only really have few observations/suggestions at this point. >>> >>> a) It would be helpful if there were a way to test the serialization >>> of the archive classes in boost MPI without having MPI installed. >>> If this is not possible, it would seem to me that the serialization >>> is intertwined with the data transport - rather than be separated >>> as it is in the stream/streambuf io/stream design. This would look >>> like a design flaw to me. >> >> Helpful to whom? I agree this is all a good idea, but I'm not sure >> how this relates to anything else we're discussing. > >It would permit me to use the MPI serialization as a use case >to verify that I hadn't broken anything. I know what your going >to say - concepts - but that is going to be a while before that >happens. > >>> b) user experience seems to show that archive >>> construction/destruction is a significant performance issue when a >>> new archive is made for each data transmission. On the other hand, >>> one has to do this since the current archive implemenation track >>> addresses of serialized obects so the same archive can't be use send >>> the same structure (maybe with changed data) multiple times. > >> I can't understand how you reach that conclusion. In my long >> explanation I thought I made it clear that Boost.MPI and its database >> get a great deal of its performance advantage from exactly that: >> sending the same structure multiple times with the same MPI type map. > >hmm - what about tracked objects? I suggested turning off tracking >and Matthias told me that it was needed to send pointers. But for this >to work an archive has to be reconstructed everytime to re-initialize >the tracking lists. I don't want to spend a lot of time on this as that >means I have to delve into the MPI serialization and I don't want >to do this. > >>> Given that MPI has a focus on performance, I wonder if this has been >>> considered. I looked a the documentation, code and examples and it >>> wasn't obvious to me how this is question was addressed - if at all. >> >> We've obviously misunderstood one another somewhere along the way. It >> would be good if we could get that cleared up. > >I think it would take too much time for me to understand. And if I did >come to understand it, I might have something to say about it. If I >said it, then it might start a thread which would cost even more time >which I don't have right now. > >Robert Ramey > > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] BoostSerialization callinga customserialize method
by Elli Barasch 27 Aug '10

27 Aug '10

Robert Ramey <ramey(a)rrsd.com> wrote: >Pooyan Dadvand wrote: > >> Can you please explain me more the idea of extradata structure? >> Consider that my extradata can be a double, ublas::vector, or even >> std::vector<weak_ptr<Element> > or any new type of variables. I >> have: >> >> std::vector<std::pair<VariableData, extradata> > mData >> ... >> ar << mData; >> >> >> and each element of vector can have a different type of data with >> different size or even have pointers. (It's a heterogeneous >> container) > >The above will work as written. > >Maybe what you want is: > >template<class T> >class mytype : std::vector<std::pair<VariableData, T> > { > template<class Archive> > void serialize(Archive &ar, const unsigned int version){ > ar << boost::serialization::base_object(*this); > } >}; > >then you can > >mytype<double> m_t >... >ar << m_t > >The possibilities are endless. This really isn't about the serialization >library >but about C++ > >Robert Ramey > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[boost::wave] Hooks not called for conditionals
by Alden King 27 Aug '10

27 Aug '10

I am currently working on a project that uses Wave to pre-process and tokenize C/C++ code, but I am not getting everything that I expect from the preprocessing hooks. We use the preprocessing hooks to extract data about false-branches, macro calls and macro expansions so this is a major roadblock for us. I am trying to extract information about the true and false branch of #if 1 int foo; #elif 0 float foo; #else struct { } foo; #endif The first #if is seen by 'found_directive'. If that returns false, then I get #ifint foo; #eliffloat foo; #else struct { } foo; #endif Note that it skips the newline after the #if and #elif and that it doesn't reveal their conditions. If it returns true, then 'evaluated_conditional_expression also gets called and I get #if 1 // [Taken] int foo; #elif0 float foo; struct { } foo; Without the #else directive, the #endif directive, and the whitespace between #elif and it's condition. My problem is that the false branch is not seen by either function (the endif also has trouble sometimes). I therefore expected all tokens in the false branch to be processed by 'may_skip_whitespace' or 'skipped_token', but that is not the case. Could you please help me to find our how to get the tokens from the false branch of the conditional expression using the preprocessing hooks? I've attached my wave test program and a sample input file. Thanks.

2 1

Boost Serialization calling a custom serialize method
by Pooyan Dadvand 27 Aug '10

27 Aug '10

Hi, Im trying to use the boost serialization in our project Kratos (a Multi-physics finite element code) in which I found the following problem, I have a class Variable which is derived from VariableData as follow: Class VariableData { std::size_t mKey; public: ..... }; template<class TDataType> class Variable : public VariableData { .... } Now I have a container which holds a pairs, consist of VariableData pointer to the Variable and a void* pointer to its value: std::vector<std::pair<const VariableData*, void*> > which I want to serialize but as it can be seen I dont have the pointer to data in my variable and I might need to implement a costumized version of Serialized with void* pValue as an additional parameter for VariableData and Variable classes: template<class TArchiveType> Variable::serialize(TArchiveType &rArchive, const unsigned int Version, void* pValue) { rArchive & static_cast<TDataType>(pVAlue); } The problem here is the template definition of this method which make it impossible to be virtual. I note that the library uses get_extended_type_info for this porposed. But I dont know how is its correct way of use. Can anybody give me a hint about how I can handle this problem? Just to add some restriction: - I dont want to add a hierarchy of handlers instead of pair because it adds another pointer jump to the container and reduce its performance in normal use of it - I dont want to add a version of non template members for each archive type while it makes a lot of duplications and makes extra dependency to the archive types in a layer of code which is not expected to have this dependency Thanks, Pooyan. ____________________________________________________________________________ ____________________________________________________________________________ _______________________ Dr. Pooyan Dadvand Member of Kratos team International Center for Numerical Methods in Engineering - CIMNE Campus Norte, Edificio C1 c/ Gran Capitán s/n 08034 Barcelona, España Tel: (+34) 93 401 56 96 Fax: (+34) 93.401.65 17 web: <http://www.cimne.com> www.cimne.com <http://www.cimne.com/kratos/> www.cimne.com/kratos/ ____________________________________________________________________________ ____________________________________________________________________________ _______________________ AVISO IMPORTANTE Los datos de carácter personal contenidos en el mensaje, se registrarán en un fichero para facilitar la gestión de las comunicaciones de CIMNE. Se pueden ejercitar los derechos de acceso, rectificación, cancelación y oposición por escrito, dirigiéndose a nuestras oficinas de CIMNE, Gran Capitán s/n, Edificio C1 - Campus Norte UPC, 08034 Barcelona, España. AVÍS IMPORTANT Les dades de caràcter personal contingudes en aquest missatge es registraran en un fitxer per facilitar la gestió de les comunicacions del CIMNE. Es poden exercir els drets d'accés, rectificació, cancel·lació i oposició, per escrit a les nostres oficines del CIMNE, Gran Capità s/n, Edifici C1, Campus Nord UPC, 08034 Barcelona, Espanya. IMPORTANT NOTICE All personal data contained in this mail will be processed confidentially and stored in a file property of CIMNE in order to manage corporate communications. You may exercise the right of access, rectification, deletion and objection by letter sent to CIMNE, Gran Capitán, Edificio C1 - Campus Norte UPC, 08034 Barcelona, Spain.

5 17

[Hash] Custom hash_value for Pointers
by Hossein Haeri 27 Aug '10

27 Aug '10

Dear all, Should not the program in the P.S. output "I got used!"? If not, how can I ensure that it's size_t hash_value(B*) which gets called upon use of bPtrHasher's operator()? TIA, --Hossein P.S. namespace Bs { struct B { virtual string id() const {return "This is a B!";} }; struct D: B { string id() const {return "And, this one is a D.";} }; size_t hash_value(B* bptr) { cout << "I got used!" << endl; boost::hash<string> hasher; return hasher(bptr->id()); } } int main() { Bs::B* bp1 = new Bs::B; Bs::B* bp2 = new Bs::D; boost::hash<Bs::B*> bPtrHasher; size_t h1 = bPtrHasher(bp1), h2 = bPtrHasher(bp2); }

2 1

NDEBUG causes a compilation error in Boost.Interprocess
by Sergey Kurenkov 27 Aug '10

27 Aug '10

I use Boost 1.42 and gcc 4.3.1 on HP-UX 11.31. So today I defined NDEBUG and BOOST_DISABLE_ASSERTS in my makefile, ran make and got this error: ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp: In function 'void boost::interprocess::detail::semaphore_close(sem_t*)': ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp:102: error: 'assert' was not declared in this scope ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp: In function 'void boost::interprocess::detail::semaphore_destroy(sem_t*)': ../../../src/libs/src/external/boost/1.42.0/boost/interprocess/sync/posix/semaphore_wrapper.hpp:137: error: 'assert' was not declared in this scope If I do not set NDEBUG and BOOST_DISABLE_ASSERTS everything is OK. Seems like the problem is that in semaphore_wrapper.hpp there is a call to assert() and if NDEBUG is set then correct headers are not included.

2 1

[Serialization] Combination of templates and polymorphism
by Michal Gregor 27 Aug '10

27 Aug '10

I am writing serialization for a template library I created. The problem is that I cannot figure out how to serialize templates of polymorphic classes (combination of polymorphism and templates). Polymorphic classes generally need to be exported using BOOST_CLASS_EXPORT, which however takes in a complete type so this would require me to register all possible instantiations of the templates, which is not possible - I don't know beforehand what instantiations might the library user make (I would have to rely on the user of the library to do the work and there is no way the user will even know which template classes may be instantiated behind the scenes somewhere). What I would like is a mechanism that would automagically register the class upon instantiation. Any ideas? -- View this message in context: http://old.nabble.com/-Serialization--Combination-of-templates-and-polymorp… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

How to disable warnings on gcc?
by Jean-Pierre Bergamin 27 Aug '10

27 Aug '10

Dear boost users On FreeBSD 8.1 with boost 1.43 and gcc 4.2.1 we have lots of warnings like: ... /usr/local/include/boost/type_traits/is_unsigned.hpp: In instantiation of 'boost::detail::is_ununsigned_helper<short int>': /usr/local/include/boost/type_traits/is_unsigned.hpp:73: instantiated from 'boost::detail::is_unsigned_imp<short int>' /usr/local/include/boost/type_traits/is_unsigned.hpp:123: instantiated from 'boost::is_unsigned<short int>' /usr/local/include/boost/type_traits/make_unsigned.hpp:110: instantiated from 'boost::detail::make_unsigned_imp<short int>' /usr/local/include/boost/type_traits/make_unsigned.hpp:130: instantiated from 'boost::make_unsigned<short int>' /usr/local/include/boost/lexical_cast.hpp:846: instantiated from here /usr/local/include/boost/type_traits/is_unsigned.hpp:40: warning: comparison between 'enum boost::detail::is_unsigned_values<short int>::<anonymous>' and 'enum boost::detail::is_unsigned_values<short int>::<anonymous>' ... Similar warnings about "comparison between ..." pop up in the serialization library as well. What is the easiest way to suppress these warnings? I tried using the switches "-Wno-sign-compare" and "-Wno-conversion", but the warnings don't go away. Thanks for your help James

2 4

[Serialization] Is there any documentation on make_nvp()?
by Robert Jones 27 Aug '10

27 Aug '10

If so, please point me to it. Thx - Rob.

2 2

Missing lib with Boost::Regex
by Emir D. 27 Aug '10

27 Aug '10

Hello everybody, I'm having some problems with using Boost's Regex in MS Visual Studio 2010. I've included the header file and downloaded the "bjam.exe" file, which I have run and it generated some lib and obj files. After including the newly generated files in VS2010, when I try to compile, I get the following: "fatal error LNK1104: cannot open file 'libboost_regex-vc100-mt-gd-1_43.lib' " I've inspected the bjam.exe generated files and it appears to have a lib file 'libboost_regex-vc100-mt-1_43.lib', but not 'libboost_regex-vc100-mt-gd-1_43.lib'. After doing some more googling, I have found a number of related questions, but failed to find an answer, although it seems to be a common problem. Can you please help me solve my problem? Thanks in advance, p.s. If i rename the lib file, it works, at least for now. However, it is a 'Release' version and therefore I can't using it in VS in debugging mode, meaning that I can only BatchBuild and create Release versions of my program, although I also need to create debug ones. p.s.s. My first Boost Mailing List post! p.s.s.s. I've just found out that VS10 has TR1 support, so I can TR1 Regex, which is Boost's Regex :) but I am still wondering how could of I solved the above stated problem? It's bound to happen with some other Boost library.

4 3

Boost test, segmentation fault.
by Matthijs Mohlmann 27 Aug '10

27 Aug '10

Hello all, First of all: I'm building an application and with that I use Boost test for unit testing. This helped me already to fix some obscure bugs. (I am very happy with boost test) I have the Master suite test setup in one file and the normal test suites each in one file. This worked very well. Now I have the following test suite which gives me a segmentation fault and I have no idea why: BOOST_AUTO_TEST_SUITE(ProgramOptions) BOOST_AUTO_TEST_CASE(ProgramOptions_Valid_Options) { // Output boost::test_tools::output_test_stream output("misc/ProgramOptions_01.output", true); // Save output buffer std::streambuf *strmbuffer; strmbuffer = std::cout.rdbuf(); // Redirect the output. std::cout.rdbuf(output.rdbuf()); // Redirect output stream so we can do some checks. printSomething(); BOOST_REQUIRE(output.match_pattern()); // Now lets process some arguments. printSomething(); BOOST_REQUIRE(output.match_pattern()); // Restore output buffer std::cout.rdbuf(strmbuffer); } BOOST_AUTO_TEST_SUITE_END() The function that gets tested: void printSomething() { std::cout << "Test output" << std::endl; } If I put the same content 'Test output' in the ProgramOptions_01.output file then everything is fine and executes ok. When putting different content in that file it goes wrong. I have also a gdb backtrace if that is interesting: (gdb) r Starting program: /home/matthijs/Projects/cppcms/trunk/cmsapp_test [Thread debugging using libthread_db enabled] Running 10 test cases... Program received signal SIGSEGV, Segmentation fault. 0xb7f6f9e8 in vtable for boost::unit_test::progress_monitor_t () from /usr/lib/libboost_unit_test_framework.so.1.42.0 (gdb) bt full #0 0xb7f6f9e8 in vtable for boost::unit_test::progress_monitor_t () from /usr/lib/libboost_unit_test_framework.so.1.42.0 No symbol table info available. #1 0xb7e5b77f in std::ostream::flush() () from /usr/lib/libstdc++.so.6 No symbol table info available. #2 0xb7f0a13d in boost::unit_test::output::compiler_log_formatter::log_finish(std::ostream&) () from /usr/lib/libboost_unit_test_framework.so.1.42.0 No symbol table info available. #3 0xb7f2e492 in boost::unit_test::unit_test_log_t::test_finish() () from /usr/lib/libboost_unit_test_framework.so.1.42.0 No symbol table info available. #4 0xb7f1a593 in boost::unit_test::framework::run(unsigned long, bool) () from /usr/lib/libboost_unit_test_framework.so.1.42.0 No symbol table info available. #5 0xb7f2f469 in boost::unit_test::unit_test_main(bool (*)(), int, char**) () from /usr/lib/libboost_unit_test_framework.so.1.42.0 No symbol table info available. #6 0x08062133 in main (argc=1, argv=0xbffff824) at /usr/include/boost/test/unit_test.hpp:59 No locals. Hopefully someone with some insight in boost.test can help me out here... Regards, Matthijs Möhlmann

2 2