- Boost-users - lists.boost.org

Re: [Boost-users] Thread-safe smart pointers, hashtables without locking
by Ray Whitmer 05 May '06

05 May '06

> The algorithm makes sense, and if all these claims hold then it > should work, I think. I'm still concerned about step (2), however, > if only because of the assumption that what you write as a load/ > store in C++ maps to a load/store in ML. Will it? Always? I ask as > a non-rhetorical question: does the C++ standard *guarantee* it? > Because if it doesn't then it seems like a potential problem, but > maybe I'm being too careful. If I could answer in the affirmative, I could prove it works and not have to talk to anyone. I can make a bunch of lesser claims, that of course fail to add up to the strong claim but make me feel better: 1. For years, people have written and relied on C/C++ characteristics that apparently were not in the standard until later if at all. If the popular platforms support it, it takes a strong reason to justify a violation of it. 2. Java, on any platform, would seem to strongly depend upon a reference assignment being accomplished all-or-nothing as a machine assignment. The alternative would be threads that see partial references being assigned in different threads and all the safety of references is out the window. This is such a common operation, it would be difficult to believe that there is thread synchronization going on around every pointer/reference assignment. 3. I have looked at the output of many C compilers and have never seen a pointer assignment take multiple instructions. The exception might be if someone used a poorly-written memcpy-like operations to transfer the contents of a structure byte by byte. A well-written one takes the respective alignments into account and transfers aligned 32-bit quantities one-by-one. We are talking about code in a controlled Hashtable class, it would have to be the "C" compiler choosing to transfer a class consisting of a single address field using something other than a single instruction. It doesn't sound logical to me, but it wouldn't surprise me completely to see it happen, but I would report it as a compiler bug and expect it to be addressed even though it is not in the standard. 4. These issues have to be addressed with the multi-processor cores becoming more prevalent because they are basic to lock-free processing, or can C++ accept significant inferiority to Java with respect to lock-free multiprocessing? Sorry that my arguments in this case frequently refer to Java. > > Have you read any of the literature on lock-free data structures, > btw? There was articles in the October and December '04 C/C++ User > Journal about them. I have read a number of articles on the subject, several specifically on the topic of lock-free hashtables, several with implementations they claim to be proven to be correct. My own first attempt is far from a proven-correct implementation. Many seem to arrive at similar conclusions, although each has its own slightly-different take on the subject and quite different mechanisms. They are also very often theoretical and build their proofs of completeness on features not apparently explicitly present in "C" standards. I certainly have yet to find an implementation I can just plug in and use. They often resort to garbage collection to solve the hard problems (even if they are working in C) or if they solve the deallocation problem, they only do so for the main array, not for the entries in the hashtable itself. > I realize that I haven't answered your original question about > atomic_count, btw, and I'm sorry: the reason is simply that I don't > know! Thanks for the comments anyway, which were thought-provoking. For what it is worth, if anyone else thinks the solution is worth a generic contribution, or is of the opposite opinion that it would not be generic enough, I would be interested in hearing. I suppose this sort of question should go to the developers list. I think it would be much more difficult to implement a table of shared_ptr than it is for intrusive_ptr, because assigning a shared_ptr is much less likely to be uninterrupted, leaving other threads with a broken visible state. There is clearly more detail to discuss as well. Ray Whitmer

1 0

Re: [Boost-users] Thread-safe smart pointers, hashtables without locking
by james.jones＠firstinvestors.com 05 May '06

05 May '06

From: Ray Whitmer <ray(a)personallegal.net> >> This would be truly thread-safe but might perform better if you >> have lots of simultaneous readers/writers. I haven't tested this, >> but if you do, I'd be interested to hear the results. > > I don't think it even begins to be thread-safe, because it doesn't > begin to deal with reallocation of the array itself... That's certainly true. I guess I was thinking of a hashtable whose interface is that it is allocated with a fixed size and not reallocated (although it might be copy-constructed to a hashtable of a different size). If modern hashtables reallocate their storage, that would certainly have to be done in a thread-safe manner. > Here is my first stab at a solution: > > 2. Perform changes to the hashtable in a manner that, given atomic > loads or stores of aligned pointers, never leaving the table in a > state that simultaneous readers cannot use it. This is very easy > compared to the allocation issues, and I have been doing this in Java > for years. I would be happy to expand on this. This write operation > may include releasing objects with ref-count 1, if this is supposed > to be a weak hashtable that does not keep unused objects in the index. [rest snipped] The algorithm makes sense, and if all these claims hold then it should work, I think. I'm still concerned about step (2), however, if only because of the assumption that what you write as a load/store in C++ maps to a load/store in ML. Will it? Always? I ask as a non-rhetorical question: does the C++ standard *guarantee* it? Because if it doesn't then it seems like a potential problem, but maybe I'm being too careful. Have you read any of the literature on lock-free data structures, btw? There was articles in the October and December '04 C/C++ User Journal about them. I realize that I haven't answered your original question about atomic_count, btw, and I'm sorry: the reason is simply that I don't know! - James Jones Administrative Data Mgmt. (v)732-510-1806 375 Raritan Center Pkwy, Suite A (f)732-510-1855 Edison, NJ 08837 Visit us on the web at http://www.firstinvestors.com/

1 0

[tribool]compile error
by Thomas Matelich 05 May '06

05 May '06

This is only happening when I'm instrumenting code with Insure++ from Parasoft. They use an EDG based parser (not sure of the version, but I know they have it set to be very strict) and it is failing like so: /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp: In function `boost::logic::tribool boost::logic::operator&&(boost::logic::tribool, boost::logic::tribool)': /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:203: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:203: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:205: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:205: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp: In function `boost::logic::tribool boost::logic::operator||(boost::logic::tribool, boost::logic::tribool)': /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:270: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:270: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:272: within this context /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:78: ` struct boost::logic::tribool::dummy' is private /usr/local/eddynet/debug_eddynet/opt/include/boost/logic/tribool.hpp:272: within this context Locally I've worked around this with changing the first part of the tribool class from: class tribool { private: to class tribool { #ifdef __INSURE__ //Symbol defined by parser when used in this context public: #endif (no #else since private is implied) Anyway, I don't mind maintaining my own mods, just thought I'd report this. If you don't mind enlightening me, I am a little curious why using safe_bool works if its private on any compiler. Seems like private typedefs usually are private. Thanks, Tom

1 0

Re: [Boost-users] [Unit-Test] How to test private functions
by james.jones＠firstinvestors.com 05 May '06

05 May '06

From: Carlo Wood <carlo(a)alinoe.com> >Also, the above is slightly dangerous, as the 'public' would >'leak' beyond the #ifdef when TESTING is defined. You'd have to make >sure that the test block at the end of the class. This is a very good point. A method defined as public in test might fail to compile as private in production. >Personally, I like the #define private public best, because it doesn't >polute the real code. But this contradicts your prior good point. This is even more dangerous than the conditional public: which you objected to, because now *every* method is public! At least with the other method, you can do it safely if you're careful. - James Jones Administrative Data Mgmt. (v)732-510-1806 375 Raritan Center Pkwy, Suite A (f)732-510-1855 Edison, NJ 08837 Visit us on the web at http://www.firstinvestors.com/

2 1

Re: [Boost-users] Thread-safe smart pointers, hashtables without locking
by Ray Whitmer 05 May '06

05 May '06

> Personally, I read this and said, "eeek!" (Well, not literally. My > office mates would wonder what was up.) I think any design like > this is going to be (at best) very non-portable, and (more likely) > subject to breaking at the worst possible moment (i.e. when > demonstrating to a customer). Is "relatively" thread-safe really > good enough here? Let me make it clear. I do not want relatively thread-safe. I want completely thread safe. It seems to me that boost already relies on an atomic counter for shared_ptr. I do not think the solution would be less portable than this. I certainly want it to run on Windows and Mac, 32 and 64 bit as well as major Unix and Linux including certain 32-bit-or-more embedded situations. There may be hopefully-rare C++ threading situations that may be difficult to recover from, and I will simply have to gather more information on these and see if they can be dealt with. > As a constructive suggestion, if you want to reduce lock conflicts > in hash tables, have you considered some form of finer-grained > locking? You could, for example, have one lock per "slot" in your > hash table. Computing the hash and finding the slot is thread-safe > (since it doesn't depend on the state of the hash table), so you > could then lock only the slot itself while performing list > maintenance or whatever you need to do to read/write the data. For the more-common reader of the hash table, it is not my intent to reduce lock conflicts, but, rather, to generally eliminate them, and replace them with something lighter-weight, such as the atomic counter used by shared_ptr, that in best cases may only take a few instructions to execute. I may have thousands of threads reading info from the hashtable at once and there may never be a natural time when there are no readers so I can update the table. The purpose of the threads is many operations that rely heavily on the hashtables -- every other instruction they are looking up something. For what it is worth, finding the slot is not thread-safe, because the table size and pointer can change. List maintenance involves multiple slots and I do not think it is worthwhile doing finer- grained locks because of the complexity, deadlock potential, and likely worse performance it would introduce. > This would be truly thread-safe but might perform better if you > have lots of simultaneous readers/writers. I haven't tested this, > but if you do, I'd be interested to hear the results. I don't think it even begins to be thread-safe, because it doesn't begin to deal with reallocation of the array itself, and if it did, your fine-grained locks appear to become worthless because you need a high-level lock protecting that allocation assuming you are going to use locks for readers, which seems like a bad idea from the start for me. There is a reason shared_ptr does not use locks (at least on the best-supported platforms), but uses an atomic count. > PS - I'd be even more worried in Java, btw, since Java opcodes > should map to CPU operations less well than a compiled binary. Not > to mention that in Java, the portability assumption becomes really > critical. Java classes are *supposed* to be portable. I do not want to get into Java wars here, but Java has to solve the deallocation problem in a thread-safe manner. When the garbage collector actually reclaims an allocation, the possibility cannot exist that someone else still happens to be using it or the language is badly broken. This is the hard thing to be solved in C++ to make a thread-safe hashtable that you do not have to deal with in Java. The deallocation problem is, from everything I have analyzed, the big problem in C++. When you attempt to deallocate something, for all you know there could be another thread that just barely loaded its pointer into shared memory and as soon as it unstalls will want to increment its reference count, but it has not yet been incremented, so even a smart pointer using an atomic reference count fails because the object is sharable in a multithreaded environment, but not the reference itself. Here is my first stab at a solution: Extra data (for each Hashtable): 1. Array of two atomic counts, one active and one inactive. 2. Index that flops between 0 and 1, so there is an active and inactive count. 3. A mutex that can be used for exclusive writers Each reader behaves as follows: 1. Fetch index. 2. Increment corresponding atomic count. 3. If fetched index is not current index, decrement atomic count and loop to step 1. This is rare and safely eliminates rare bad cases 4. Now the reader has free access to the entire hashtable structure, and is guaranteed by cooperation of the writer that the pointers it sees are not stale. It must only guarantee that any pointer referenced in step 4 is either destroyed or it's ref count is incremented before step 5 -- this includes the pointer to the allocated resizable array itself. 5. Decrement the same atomic count (of fetched index) incremented in step 3. Note that in Java, none of this is necessary for readers because the language safety assumes any reference is not deallocated. Each writer behaves as follows: 1. Obtain an exclusive lock on the hashtable. This lock only excludes other writers, not other readers. 2. Perform changes to the hashtable in a manner that, given atomic loads or stores of aligned pointers, never leaving the table in a state that simultaneous readers cannot use it. This is very easy compared to the allocation issues, and I have been doing this in Java for years. I would be happy to expand on this. This write operation may include releasing objects with ref-count 1, if this is supposed to be a weak hashtable that does not keep unused objects in the index. 3. This is really part of 2: any step in (2) which destroys a reference a reference keeps a private local copy to make sure it is not deallocated before all reading threads are finished with it. If the references are ref-counted, a ref-counted private reference is kept. 4. If there are no private local pointers/references being kept, go to step 9 5. Wait for inactive (1-index) atomic count to go to 0. This is rare and safely eliminates rare bad cases. 6. Change index (index = 1 - index). 7. Wait for inactive (1-index) atomic count to go to 0. This means that all readers who might have a copy of a stale pointer are finished. 8. Release all private local references with a reference count of 1. Non-ref-counted references always get released, due to single owner. If this is a weak hashtable, reinsert any references that have a reference count greater than one since these were found and incremented while we were waiting for readers to exit. 9. Release lock. Done. More notes: Although we don't want to go out of our way to make the writer inefficient, there is a single writer at any one time with an exclusive lock. But we do not have to wait for all readers to exit to perform the update, we only need to wait for current readers to exit, during which time new readers may enter, which we do not care about because we have already removed the candidates from public places in the list. This includes the pointer to the array itself, which is generally treated like any other allocated pointer, but does not require a reference count. There are many details I left out that did not directly pertain to the allocation problem, but only with atomically updating the rest of the table so that the reader view is always consistent. Ray Whitmer

1 0

pool_allocator<void> not supported?
by Strelnikov Michael 05 May '06

05 May '06

Dear all, It seem std::allocator specialized for void, but pool_allocator don't. Why? Thanks.

1 0

Re: [Boost-users] [serialization] I can't figure out what I'm doing wrong with xml_oarchive - please help
by Manos Tsagarakis 05 May '06

05 May '06

Hello Robert, I'm posting this message again (3rd time actually) as I did not see the previous two ... Thank you for the quick response. I'm glad you liked the title ... A) I did replace all BOOST_CLASS_EXPORT with BOOST_CLASS_EXPORT_GUID, but the problem with xml persists. It is really difficult for me to figure out what is wrong with xml, as both txt and bin versions are ok. Actually what worries me, is the possibility that the problem with xml somehow will show up in other formats too ... B) I don't use the version numbers at the moment but I added it just for future use. I actually have a couple of questions here. 1) BOOST_CLASS_VERSION has to be in the header file? Can I place it in the cpp file? 2) Please correct me If I'm wrong: I don't use BOOST_CLASS_VERSION so that all classes have version number assignment set to 0. I also don't use BOOST_SERIALIZATION_SPLIT_MEMBER for now. Later on, I add some members, so that the class version must change. I simply add BOOST_CLASS_VERSION(..., 1) and split serialize to save/load at that time. Previously saved data files are not affected as long as version info is handled correctly by my code. Is that correct? C) I avoid using templated code in CTCDataBase for as long as the core data that must be serialized evolve, in order to avoid frequently modification of the most included header file TC_database.h. That meens almost recompile all, and that takes time. Thank you for the suggestion any way. I'll keep it in mind. To be honest, I did try to use export feature of templates bug no luck ... D) I re-attach a couple of header files to this post and I kindly ask you to take a look at the implementation and tracking level for template class fem::CPropRepository implementation_level< fem::CPropRepository<T, SZ> > and tracking_level< fem::CPropRepository<T, SZ> >, and one utilization of it at the other header. Should it be so? Do I need it? And also is it possible that using this CPropRepository stuff (especially with MFC CString) breaks the xml code? E) After adding all headers of the serialize library compilation takes a lot more time. Are there any guidelines by you on that? I hope I'm not encroaching your time... Thank you again, Emmanuil Tsagarakis >> -----Original Message----- >> From: boost-users-bounces(a)lists.boost.org >> [mailto:boost-users-bounces@lists.boost.org] On Behalf Of >> Robert Ramey >> Sent: Friday, May 05, 2006 8:36 AM >> To: boost-users(a)lists.boost.org >> Subject: Re: [Boost-users] [boost-users] [serialization] >> I can't figure outwhatI'm doing wrong with xml_oarchive - >> please help >> >> LOL - I liked the title. >> >> I've taken a very quick look at your code and files. >> >> a) I'm a little suspicious of including a ":" character >> as the GUID for a class. I think that might be an issue. >> Try replacing >> >> BOOST_CLASS_EXPORT(fem::CTCSoil); >> >> with >> >> BOOST_CLASS_EXPORT_GUID(fem::CTCSoil, "fem_CTCSoil"); >> >> You'll have to double check the exact syntax. >> >> b) You've set version numbers to 1 but I don't see the >> version numbers used in the deserializations. Version >> number assignment is only necessary if you're going to >> use the version numbers and they are not equal to 0. >> >> c) A minor suggestion - not important here but interesting anyway. >> In fem_boost_serialize.cpp Use templates to shorten the code. >> >> template<class Archive> >> void CTCDataBase::boost_serialize_open(const char* filename) { >> try { >> std::ifstream ifs(filename); >> assert(ifs.good()); >> Archive ia(ifs); >> >> ia >> BOOST_SERIALIZATION_NVP(m_lstSoils); >> ia >> BOOST_SERIALIZATION_NVP(m_lstBrickWalls); >> ia >> BOOST_SERIALIZATION_NVP(CTCFooting::s_bspSoil); >> ia >> BOOST_SERIALIZATION_NVP(CTCFrame::s_bspBrickWall); >> } >> catch (const boost::archive::archive_exception& e) { >> e; >> } >> } >> >> and >> template<class Archive> >> void CTCDataBase::boost_serialize_saveconst char* filename) { >> try { >> std::ofstream ofs(filename); >> assert(ofs.good()); >> Archive oa(ofs); >> >> oa << BOOST_SERIALIZATION_NVP(m_lstSoils); >> oa << BOOST_SERIALIZATION_NVP(m_lstBrickWalls); >> oa << BOOST_SERIALIZATION_NVP(CTCFooting::s_bspSoil); >> oa << BOOST_SERIALIZATION_NVP(CTCFrame::s_bspBrickWall); >> } >> catch (const boost::archive::archive_exception& e) { >> e; >> } >> } >> >> void main() >> { >> fill_with_build_in(); >> boost_serialize_save<boost::archive::text_oarchive>("boost >> _serialize.txt"); >> boost_serialize_save<boost::archive::binary_oarchive>("boo >> st_serialize.bin"); >> boost_serialize_save<boost::archive::xml_oarchive>("boost_ >> serialize.xml"); >> >> // some time later ... >> boost_serialize_open<boost::archive::text_oarchive>("boost >> _serialize.txt"); >> boost_serialize_open<boost::archive::binary_oarchive>("boo >> st_serialize.bin"); >> boost_serialize_open<boost::archive::xml_oarchive>("boost_ >> serialize.xml"); >> } >> >> Robert Ramey >> >> TOL mtsagara wrote: >> >> Hi to all, >> >> >> >> This is my very first post to boost-users! I've been >> using a couple >> >> of boost libraries for a while (shared_ptr & bind >> mostly). Write now >> >> we are in the process of transforming a project based on MFC >> >> collections, (with objects derived from CObject), to >> STL, and doing >> >> some search for a library that will allow object >> persistence the way >> >> MFC does, the obvious solution was boost::serialize. >> As I'm a newbie >> >> in mpl style code the first impression was terrifying! >> But after >> >> reading the documentation and experimenting a lot, I >> did manage to >> >> start using boost::serialize. In fact there is no need >> to be familiar >> >> with mpl. The library is excellent - an exemplary >> work, thank you >> >> Robert Ramey! >> >> >> >> Now my problem is with xml files. I can write a couple >> of classes >> >> both in txt and binary files. But I can't write the >> very same data in >> >> xml format. I believe I followed all guidelines but I >> had no luck ... >> >> :( >> >> >> >> The scenario in pseudo code is this: >> >> >> >> >> >> >> ////////////////////////////////////////////////////////// >> /////////// >> >> / >> >> // file fem.h >> >> #include <boost/archive/...> >> >> #include <boost/serialize/...> >> >> >> >> namespace fem { >> >> >> >> class CTCBase >> >> { >> >> ... >> >> }; >> >> typedef boost::shared_ptr<CTCBase> CBSPBase typedef >> >> std::list<CBSPBase> CBSPBaseList >> >> >> >> >> >> >> >> class CTCSoil >> >> { >> >> ... >> >> }; >> >> typedef boost::shared_ptr<CTCSoil> CBSPSoil typedef >> >> std::list<CBSPSoil> CBSPSoilList >> >> >> >> >> >> >> >> class CTCBrickWall >> >> { >> >> ... >> >> }; >> >> typedef boost::shared_ptr<CTCBrickWall> CBSPBrickWall typedef >> >> std::list<CBSPBrickWall> CBSPBrickWallList >> >> >> >> >> >> >> >> // list of soils >> >> CBSPSoilList s_lstSoils; >> >> // list of Brick Walls >> >> CBSPBrickWallList s_lstBrickWalls; >> >> // initial soil for each new foundation beam (also >> contained in above >> >> list) CBSPSoil s_bspSoil; // initial brick wall on >> each beam (also >> >> contained in above list) CBSPBrickWall s_bspBrick; } >> >> >> >> BOOST_CLASS_VERSION(fem::CTCBase, 1); >> >> BOOST_CLASS_VERSION(fem::CTCSoil, 1); >> >> BOOST_CLASS_VERSION(fem::CTCBrickWall, 1); >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ////////////////////////////////////////////////////////// >> /////////// >> >> / >> >> // file fem.cpp >> >> >> >> #include "fem.h" >> >> #include <boost/serialization/export.hpp> >> >> >> >> >> >> BOOST_IS_ABSTRACT(fem::CTCBaseObj); >> >> BOOST_CLASS_EXPORT(fem::CTCSoil); >> >> BOOST_CLASS_EXPORT(fem::CTCBrickWall); >> >> >> >> void fill_with_build_in() >> >> { >> >> ... >> >> } >> >> >> >> >> >> void main() >> >> { >> >> fill_with_build_in(); >> >> boost_serialize_save_txt("boost_serialize.txt"); >> >> boost_serialize_save_bin("boost_serialize.bin"); >> >> boost_serialize_save_xml("boost_serialize.xml"); >> >> >> >> >> >> // some time later ... >> >> boost_serialize_open_txt("boost_serialize.txt"); >> >> boost_serialize_open_bin("boost_serialize.bin"); >> >> boost_serialize_open_xml("boost_serialize.xml"); >> >> } >> >> >> >> >> >> >> >> The xml save & open functions are in file >> fem_boost_serialize.cpp >> >> >> >> I attached the 3 files produced this way. I can also >> read back txt & >> >> binary versions. I'm wondering if somebody - hopefully >> Robert Ramey! >> >> - can tell me just by examining the output files, >> where should I look >> >> for the problem. Or do I have to debug the code line >> by line and see >> >> what wend wrong? It seems something is wrong with the >> very first >> >> shared_ptr serialization . >> >> >> >> I include some - not stand alone I'm afraid - source >> code files with >> >> this message just in case someone might take a look at >> them. I can >> >> tell that during the transition period from MFC to STL >> (possibly >> >> after that too), our objects derive from MFC CObject. >> Also at the >> >> moment, we still use MFC CString and not std::string. >> I had to copy >> >> CString to std::string for the serialization to work >> properly. Could >> >> there be a conflict somewhere there? Could it be the >> order in hpp >> >> files are included? >> >> >> >> >> >> Finally I use MS Visual C++ .net 2003 and boost v1.33.1. >> >> >> >> >> >> Thank you in advanced, >> >> >> >> >> >> >> >> Emmanuil Tsagarakis >> >> >> >> >> > >> > >> > >> >> _______________________________________________ >> >> Boost-users mailing list >> >> Boost-users(a)lists.boost.org >> >> http://lists.boost.org/mailman/listinfo.cgi/boost-users >> >> >> >> _______________________________________________ >> 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 python std::set
by Nat Goodspeed 05 May '06

05 May '06

From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Craig Glasgow Sent: Friday, May 05, 2006 3:55 AM To: Boost-users(a)lists.boost.org Subject: [Boost-users] Boost python std::set Does anyone know how to write the python conversions to go between the C++ STL class std::set and Python sets? I've written simialar conversions between lists/tuples and std::vector and between dict and std::map by modifying the code in: scitbx/include/scitbx/boost_python/container_conversions.h mentioned in the FAQ. Boost python, however, while supporting dict, list, tuple does not appear to support set. Any ideas? [Nat] <grin> Your timing is excellent. Check the C++-sig mailing list from two days ago: http://article.gmane.org/gmane.comp.python.c%2B%2B/9682 In general, check the C++-sig mailing list for Boost.Python questions.

1 0

Boost python std::set
by Craig Glasgow 05 May '06

05 May '06

Hi Does anyone know how to write the python conversions to go between the C++ STL class std::set and Python sets? I've written simialar conversions between lists/tuples and std::vector and between dict and std::map by modifying the code in: scitbx/include/scitbx/boost_python/container_conversions.h mentioned in the FAQ. Boost python, however, while supporting dict, list, tuple does not appear to support set. Any ideas? Regards Craig

1 0

[boost-users] [serialization] I can't figure out what I'm doing wrong with xml_oarchive - please help
by TOL mtsagara 05 May '06

05 May '06

Hi to all, This is my very first post to boost-users! I've been using a couple of boost libraries for a while (shared_ptr & bind mostly). Write now we are in the process of transforming a project based on MFC collections, (with objects derived from CObject), to STL, and doing some search for a library that will allow object persistence the way MFC does, the obvious solution was boost::serialize. As I'm a newbie in mpl style code the first impression was terrifying! But after reading the documentation and experimenting a lot, I did manage to start using boost::serialize. In fact there is no need to be familiar with mpl. The library is excellent - an exemplary work, thank you Robert Ramey! Now my problem is with xml files. I can write a couple of classes both in txt and binary files. But I can't write the very same data in xml format. I believe I followed all guidelines but I had no luck ... :( The scenario in pseudo code is this: ////////////////////////////////////////////////////////////////////// // file fem.h #include <boost/archive/...> #include <boost/serialize/...> namespace fem { class CTCBase { ... }; typedef boost::shared_ptr<CTCBase> CBSPBase typedef std::list<CBSPBase> CBSPBaseList class CTCSoil { ... }; typedef boost::shared_ptr<CTCSoil> CBSPSoil typedef std::list<CBSPSoil> CBSPSoilList class CTCBrickWall { ... }; typedef boost::shared_ptr<CTCBrickWall> CBSPBrickWall typedef std::list<CBSPBrickWall> CBSPBrickWallList // list of soils CBSPSoilList s_lstSoils; // list of Brick Walls CBSPBrickWallList s_lstBrickWalls; // initial soil for each new foundation beam (also contained in above list) CBSPSoil s_bspSoil; // initial brick wall on each beam (also contained in above list) CBSPBrickWall s_bspBrick; } BOOST_CLASS_VERSION(fem::CTCBase, 1); BOOST_CLASS_VERSION(fem::CTCSoil, 1); BOOST_CLASS_VERSION(fem::CTCBrickWall, 1); ////////////////////////////////////////////////////////////////////// // file fem.cpp #include "fem.h" #include <boost/serialization/export.hpp> BOOST_IS_ABSTRACT(fem::CTCBaseObj); BOOST_CLASS_EXPORT(fem::CTCSoil); BOOST_CLASS_EXPORT(fem::CTCBrickWall); void fill_with_build_in() { ... } void main() { fill_with_build_in(); boost_serialize_save_txt("boost_serialize.txt"); boost_serialize_save_bin("boost_serialize.bin"); boost_serialize_save_xml("boost_serialize.xml"); // some time later ... boost_serialize_open_txt("boost_serialize.txt"); boost_serialize_open_bin("boost_serialize.bin"); boost_serialize_open_xml("boost_serialize.xml"); } The xml save & open functions are in file fem_boost_serialize.cpp I attached the 3 files produced this way. I can also read back txt & binary versions. I'm wondering if somebody - hopefully Robert Ramey! - can tell me just by examining the output files, where should I look for the problem. Or do I have to debug the code line by line and see what wend wrong? It seems something is wrong with the very first shared_ptr serialization . I include some - not stand alone I'm afraid - source code files with this message just in case someone might take a look at them. I can tell that during the transition period from MFC to STL (possibly after that too), our objects derive from MFC CObject. Also at the moment, we still use MFC CString and not std::string. I had to copy CString to std::string for the serialization to work properly. Could there be a conflict somewhere there? Could it be the order in hpp files are included? Finally I use MS Visual C++ .net 2003 and boost v1.33.1. Thank you in advanced, Emmanuil Tsagarakis

2 1