July 2007 - Boost-users - lists.preview.boost.org

the thread safe boost serialization library is thread safe?
by Fei Liu 11 Jul '07

11 Jul '07

I am testing a multi-thread app which uses boost serialization library..I got the dreaded error: *** glibc detected *** double free or corruption (fasttop): 0x0aed93d0 *** Aborted Using a core dump and gdb, here is a backtrace. It appears it crashed inside the multi-thread library. Any advice is appreciated.. #0 0xb7f9a6be in boost::serialization::extended_type_info::type_info_key_cmp () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 (gdb) bt #0 0xb7f9a6be in boost::serialization::extended_type_info::type_info_key_cmp () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #1 0xb7f9a6f2 in boost::serialization::extended_type_info::operator< () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #2 0xb7f9b43e in std::_Rb_tree<boost::serialization::extended_type_info const*, boost::serialization::extended_type_info const*, std::_Identity<boost::serialization::extended_type_info const*>, boost::serialization::detail::tkmap::type_info_compare, std::allocator<boost::serialization::extended_type_info const*> >::insert_unique () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #3 0xb7f9adfb in boost::serialization::extended_type_info::self_register () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #4 0x08053c23 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, std::map<std::string, std::string, std::less<std::string>, std::allocator<std::pair<std::string const, std::string> > > >::load_object_data (this=0x805ba7c, ar=@0x933f71e0, x=0x933f73a8, file_version=2470408016) at extended_type_info_typeid.hpp:77 #5 0xb7f91900 in boost::archive::detail::basic_iarchive::load_object () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #6 0x080537a7 in boost::archive::detail::iserializer<boost::archive::xml_iarchive, ns::ge::rule>::load_object_data (this=0x805ba60, ar=@0x933f71e0, x=0x933f73a8, file_version=4) at iserializer.hpp:143 #7 0xb7f91900 in boost::archive::detail::basic_iarchive::load_object () from /usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0 #8 0x08052c82 in utils::xml::deserialize<ns::ge::rule> (s=@0x4, is=@0xb7fb7f1e) at iserializer.hpp:143 #9 0x08052f41 in ns::ge::rules<ns::ge::rule>::process_xml (this=0x805b9a0, xml=@0x933f7410) at ns_ge_rules.h:54 #10 0x08053353 in ns::ge::rule_server<ns::ge::rules<ns::ge::rule>, pthread::thread_pool> (arg=0xb7fb7f1e) at ns_ge_rule_listener.h:47 #11 0xb7bb73b0 in start_thread () from /lib/tls/libpthread.so.0 #12 0xb79f426e in clone () from /lib/tls/libc.so.6

5 7

Re: [Boost-users] [wave] compling error - error C2001: newline inconstant
by Hartmut Kaiser 10 Jul '07

10 Jul '07

Hi, > I　have been using boost wave library without much problems so > far. But recently when I was trying to compile our program > with UNICODE mode using > VC++ 2005 Express, I got this compile error: > > c:\users\tools\boost\boost_1_34_0\boost\wave\util\cpp_macromap .hpp(683) : > error C2001: newline in constant > > It complains about the following lines: > > argument->push_back(token_type(T_PLACEMARKER, "?, [snip] > It was strange to me that without setting to UNICODE mode, I > did not have this problem. This has been fixed in Boost::CVS head already. Please replace the "$" by a "\xA7". > Another interesting thing is that if I added the closing > double quate " and changed the line as to below, the compile > error went away: > > argument->push_back(token_type(T_PLACEMARKER, "?", Don't do that. Wave is relying on a specific character there. > But I am not sure if I am doing right thing and not sure if > the wave developer really missed closing double quate. The double quote has been eaten by your unicode editor. HTH Regards Hartmut

1 0

intrusive_ptr and NULL value
by Pavel Syomin 10 Jul '07

10 Jul '07

Hi, guys! I found embarrassing difference between shared_ptr::operator*() and intrusive_ptr::operator*() behavior (even the same I can say about operator ->). At first, look on shared_ptr: reference operator* () const // never throws { BOOST_ASSERT(px != 0); return *px; } If shared_ptr object has NULL value and someone call operator*(), it will throws exception. But if we look on intrusive_ptr(): T & operator*() const { return *p_; } we can see, that pointer don't checks.... Is it an imperfection or a feature?

2 3

feature for multidimensional binary tree
by valentin julien 10 Jul '07

10 Jul '07

I have heard about your library from a friend and badly i haven't found some kind of template binary tree implementation... What i'm working on is a multi dimensional binary tree to make Quadtrees Octrees or more.... And I want to make genericity to put several types of object in the same Leaf of my tree... I think this idea sounds like a cool stuff ...Is there laready any structure in Boost that can be use like it ? Or What do you think of this feature? ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************

3 5

Re: [Boost-users] boost library for SQL
by Ovanes Markarian 10 Jul '07

10 Jul '07

On Tue, July 10, 2007 08:04, Meryl Silverburgh wrote: > Hi, > > Does boost library has library in c++ for SQL? If not, does anyone know if there is a c++ library for sql? > > Thank you. > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > Please take a look at SOCI at http://soci.sourceforge.net/ This is a really great lib! With Kind Regards, Ovanes Markarian

3 3

boost library for SQL
by Meryl Silverburgh 10 Jul '07

10 Jul '07

Hi, Does boost library has library in c++ for SQL? If not, does anyone know if there is a c++ library for sql? Thank you.

3 2

[serialization] hacking serialization : handles to pointers
by Sean Cavanaugh 10 Jul '07

10 Jul '07

Ok I've spent a good chunk of my day making a set of custom archive class, based on the portable_binary_iarchive and portable_binary_oarchive. I have a non-virtual class hierarchy named Asset, in memory this is a cyclic graph, but my requirements are that this structure cannot be serialized all at once, it has to be broken up at boundaries. So the archiver serializes the first Asset* (which is always the root object passed into operator&). This object serializes as normally as per the boost serialization code, except except that when subsequent Asset*'s are encountered I send the pointer into an AssetManager class and translate the Asset* into a ResourceID, and serialize the ResourceID instead of the object. This is done by directly calling operator& inside save_override. So far all of this works: The reverse case of loading, by hooking load_override almost works. Almost, because I have to apply a hack of skipping 4 bytes inside load_override, before trying to read the ResourceID structure with operator&. I can't figure out how to make it 'proper', without simply hard coding the 4 byte read. As far as I can tell before save_override some bookkeeping information is written, but the reverse operation in load_override has not yet stripped this bookkeeping information from the stream, so these functions aren't quite mirror operations. As best as I can tell the function guilty of reading the bookkeeping information is load_pointer. What I need is another function in the boost archive API that pulls the bookkeeping information out of the stream safely, that I can call from within load_override, since I have no intention of calling load_pointer through any means. Aside from the hack, it technically works, but even then I still have a few aching problems: I also have to hard-code the full list of derived Asset types and manually provide specializations for all of them in save_override and load_override. If I use the base class, I end up slicing my class down to its base, and cannot serialize it. I can't make serialize virtual, since the intrusive serialize methods are templates, but it certainly would solve the problem if it were possible. In addition the bodies of all of my overrides are completely identical except for the classname (AssetModel, AssetTexture, etc). Which means I'll be wrapping the bodies of a generic save_override and load_override in a macro, and have to manually add all Asset derived classes to a list of classes inside my archive class. Which means that my archiver cannot be generic, even though I have managed to make it a template in the sense that the passed in asset manager and base asset types are template parameters. the type ResourceID is a std::string saving... class asset_oarchive : ... void save_override(const AssetModel& t, int i) { if (!RootAssetSaved) { RootAssetSaved = true; binary_oarchive_impl::save_override(t, i); } else { AssetManagerType::ResourceID ResourceId = TheAssetManager->ResourceIdForAsset(&t); operator&(ResourceId); } } loading ... class asset_iarchive : ... void load_override(AssetModel*& t, int i) { if (!RootAssetLoaded) { RootAssetLoaded = true; binary_iarchive_impl::load_override(t, i); } else { unsigned char c[10]; for (INT x=0; x<10; ++x) { c[x] = 0xFF; } for (INT x=0; x<4; ++x) { operator&(c[x]); //hackhack } AssetManagerType::ResourceID ResourceId; operator&(ResourceId); AssetType* a = TheAssetManager->FindAsset(ResourceId); if (!a) { a = TheAssetManager->LoadAsset(ResourceId); } // TODO: throw on missing resources, potentially query asset manager for substitutes t = static_cast<AssetModel*>(a); } } So I have a working implementation, how do I make it better?

2 2

Re: [Boost-users] wrapping stdlib fstream with boost filtering streams
by Daniel Oberhoff 10 Jul '07

10 Jul '07

Hi, egoots <egoots(a)gmail.com> writes: >> 1) does the compressor flush the zlib compression buffer when I flush/ >> pop it? > > As I understand it, pop() and reset() both flush and close the current > device and then destroy it. Well, but I explicitly switched the auto_close feature off... >> 2) is fstream a bidirectional stream (my guess due to separate seekg/ >> seekp methods) or a seekable stream (one read/write head)? Because I >> currently require the former. >> >> btw: the above code runs without exceptions, but when I read back >> variables I have just written they are garbled. > > You should read the thread of messages at... there may be some relevant > info here: > http://thread.gmane.org/gmane.comp.lib.boost.user/13824 > > Especially the replies by Jonathan Turkanis Well, there he says that strict_sync is there to switch filters, but it wouldn't make sense to use it before all the data is compressed. but that is exactly the point: all the data IS compressed. Matlab files effectively consist of carefully concatenated compressed and uncompressed files. Effectively I could take out a compressed block from a matlab file and send it to gunzip. Also, in my code strict_sync returns true, unlike what the original poster in the mentioned thread has experienced, indicating that all has been flushed and written and switching filters is ok. I also check after every pop() if the fstream has been closed, and it has not. Using a different z stream wrapper (zipstream) works (mostly) and gives me the original data, while the boost approach gives me zeros. Well, I will try to make a simpler test case, since the program is quite complex. thanks 4 the reply Daniel

1 0

Re: [Boost-users] Réf. : Problem message bis
by question boost 10 Jul '07

10 Jul '07

> Now I do:> cd C:\Documents and Settings\Administrateur\Bureau\boost_1_33_1\boost_1_33_1\tools\build\jam_src> C:\Documents and Settings\Administrateur\Bureau\boost_1_33_1\boost_1_33_1\tools\build\jam_src\build.bat> Then I set the following variables:> BOOST_ROOT= C:\Documents and Settings\src\boost> and BOOST_BUILD_PATH=C:\Documents and Settings\Administrateur\Bureau\boost_1_33_1\boost_1_33_1\tools\build\v2. The problem is the same. I don't know what to do now in order not to get the message any more. Thank you for your response. > To: boost-users(a)lists.boost.org> Wrom: HAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZU _________________________________________________________________ David Guetta a réuni les sons les plus connus de Messenger dans le Mix Messenger, le son de l’été ! Téléchargez-le gratuitement ! http://specials.divertissements.fr.msn.com/mixmessenger

1 0

boost::lambda::bind - a better name?
by Maciek Godek 10 Jul '07

10 Jul '07

Wouldn't it be better if boost::lambda::bind was named boost::lambda::call (or boost::lambda::eval, to make it more lispish), in order to: -avoid the confusion and potential overlap with boost::bind -make the name more sensible within lambda expressions, especially when "binding" nullary functions, ie. int six() { return 6; } if_(call(six) == 6) [ ... ] IMHO looks better than if_(bind(six) == 6) [ ... ] Yours, Chuj

2 1