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

[multi_array] operator= requires resize - why?
by Markus Werle 04 Jun '12

04 Jun '12

Hi! IMHO the behaviour of operator= for multi_array is a little bit broken. A lot of preconditions required: template <typename ConstMultiArray> multi_array_ref& operator=(const ConstMultiArray& other) { [...] // make sure the dimensions agree assert(other.num_dimensions() == this->num_dimensions()); assert(std::equal(other.shape(),other.shape()+this->num_dimensions(), this->shape())); Besides the fact that I get mad about … [View More]

6 18

Design for boost::serialization of STL iterators.
by Carlo Wood 23 May '09

23 May '09

On Sat, Mar 11, 2006 at 11:45:36PM +0200, Peter Dimov wrote: > Carlo Wood wrote: > > > 1) WHY does boost::serialization not support serialization > > of iterators? > > It's very hard, if not impossible, in general. It is either impossible or possible. When it is possible, it can't be hard :p I think that at the moment of serialization, the actual container needs to be known. So, only concentrating on the syntax of the code that serializes an iterator, the following … [View More]cannot work: ar & iter; However, the container will be known at that point (or at least, we might as well assume that). Therefore, I could imagine a syntax like: ar & foobar(container, iter); where 'foobar' is some template function (that will be part of boost::serialization in the future). Lets start with the last one (have to start somewhere). In order to deserialize the iterator (and taken into account that we already have the container) -- which makes me think that it might be better to pass a functor to operator& above. In other words, (at least for writing), use: template<class Container> struct Foobar { Foobar(Container const&, typename Container::const_iterator& iter) : M_container(container), M_iter(iter); private: Container const& M_container; Container::const_iterator& M_iter; }; and then assign to M_iter, whatever we find in M_container. > If you have access to the container to which the iterator i refers: > > a) if the container is a map, you can serialize i->first, then on > deserialization look up the key in the map using .find(); > > b) if the container is a sequence, and it has the same contents on > deserialization as it does on serialization, you can serialize the index of > the element - distance( c.begin(), i ). I don't think that it is a requirement that the whole container has to be read: either it's a map or set, in which case later insertions will not invalidate the container, or it is a vector, in which case we use an index, from which we can construct the end iterators before the whole container is reconstructed. Therefore, the following syntax can work imho: ar & FooBar(container, iter); Would you agree? There are a zillion questions and implementation details open - but I'd like to get anyones feedback about this type of interface for iterators before continuing. Current questions: What is a good name for Foobar? Am I right when I think that Foobar needs to be declared in boost::serialization? Now the hard part (for me) is that part that involves the internals of the boost library. At the moment one tries to serialize an iterator, it is possible (though not necessarily) that the object that the iterator points to is already serialized. In the case that we are dealing with an associative container (map or set etc), we don't want to store the contents of the object (or key part, in the case of a map) again: I'd like to just store that once, and store a reference in the archive at the other place. How can I make the library store an object only the first time and the store a reference the second time? This would be for an object of arbitrary type thus. I think that it is only feasible to do this when it's actually the same object (same memory address), which is the case; but while storing the object element of the container, the address of it isn't stored as well, is it? Is there a way to make: std::set<SomeData> s; [...] ar << s; Store the address of s (&s) along with the contents of s? And would that then automatically cause the library to not store that same object again when I do: std::set<SomeData>::iterator iter = s.find(...); [...] ar << *iter; Because then, &*iter would again be the same memory address as what was stored before. -- Carlo Wood <carlo(a)alinoe.com> [View Less]

3 2

[BGL] citing the Boost Graph Library
by Alejandro Marcos Aragón 06 May '09

06 May '09

Can anyone point me how to cite the Boost Graph Library in a paper? Is there any information in the boost website? Thank you all, Alejandro Aragón

4 3

Boost Graph Library and Boehm Garbage Collector
by FBSL 08 Sep '08

08 Sep '08

Hello I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator. Does anyone … [View More]

3 4

[statechart] history transitions make state-local-storage "un-cool"
by Mick Hollins 26 Jun '08

26 Jun '08

Apologies if this has been discussed before, but I couldn't find any mention of it: I am currently using the history facility of boost::fsm. I've discovered that when I re-enter a state, X, via a history transition I don't actually re-enter the same instance of X that I was in before, but instead enter a newly constructed instance of X. I just checked the UML spec regarding history transitions and it says that "Any necessary entry actions are performed", so given that boost::fsm uses … [View More]

4 19

[serialization, ASIO] Assertion when serializing recursive boost::variant type
by Falco Hirschenberger 05 Sep '07

05 Sep '07

Hi, I have defined a recursive variant type like this: --- typedef boost::make_recursive_variant<bool, int, double, std::string, std::vector< boost::recursive_variant_ >, std::map<std::string, boost::recursive_variant_>, TGrey8Image, TRgbImage, TRgbaImage>::type TVType; --- and two containers which can store … [View More]this type: --- typedef std::vector<TVType> TVector; typedef std::map<std::string, TVType> TMap; --- I wrote a set of unit-tests testing all types of plain and recursive containers and they work as expected. I also tested (de-)serialization to a binary archive and there's also no problem. Then I implemented a Message class which contains such a TVType + some other stuff. Serializing and deserializing also works in the tests. Finally I implemented a client and server with ASIO like the ASIO "serialization" example. First sending the size of the archive and then the data itself. The sending works but when I want to deserialize my message I get the following assertion: --- testSerialization: /usr/include/boost/variant/detail/visitation_impl.hpp:203: typename Visitor::result_type boost::detail::variant::visitation_impl(int, int, Visitor&, VPCV, mpl_::true_, NBF, W*, S*) [with W = mpl_::int_<20>, S = boost::detail::variant::visitation_impl_step<boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_end> >, Visitor = boost::detail::variant::invoke_visitor<boost::detail::variant::direct_assigner<const int> >, VPCV = void*, NBF = boost::variant<boost::detail::variant::recursive_flag<bool>, int, double, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<boost::recursive_variant_, std::allocator<boost::recursive_variant_> >, std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_variant_, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_variant_> > >, CIS::Image2d<unsigned char>, CIS::Image2d<CIS::RGB>, CIS::Image2d<CIS::RGBA>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_]: Assertion `false' failed. --- I absolutely don't know what't wrong here the backtrace iss huge but the point in my code where it happens is the line when deserializing the message. When I comment out the TVType payload of the message, it works. I would really appreciate any clue. Greetings, Falco [View Less]

2 1

Re: [Boost-users] cross compiling boost for ARM
by Hughes, James 12 Aug '07

12 Aug '07

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of remi > Sent: 05 January 2007 14:44 > To: boost-users(a)lists.boost.org > Subject: [Boost-users] cross compiling boost for ARM > > > hi! > > I want to cross compile boost for an ARM processor. > For a pxa 270. but when i try to cross compile boost with > arm-linux-g++ , it dosen't work ... a proble with jam... > … [View More]

3 3

[Serialization] Problem serialization of derived classes
by Andreas Willich 09 Aug '07

09 Aug '07

Hi there! I have a problem with the code in the attachment. I followed the documentation and the examples, but I did not get the code to work. Gcc produces a lot of failures that something is already instantiated in header files of the serialization library. Has someone a idea what I am doing wrong? My gcc version is 4.1.1-r3 and I am working on a gentoo x86 box. Andreas Willich

4 5

[lambda][1.33.1] Lambda warnings after installing VS2005 SP1
by john.wismar＠autozone.com 01 Aug '07

01 Aug '07

I have just installed Service Pack 1 for VS2005, and am now getting a warning in some code using lambda::bind. There wasn't a warning previously, but I don't know if the issue is due to an update to the C++ standard library, a legitimate warning that they weren't flagging before, or a spurious warning. It looks like the issue is that I'm passing a function pointer, to bind. Is this a warning I should just ignore, or is this a legitimate issue? Thanks for your help! Here's a sample app,… [View More]

2 1

[Serialization] is_serializable trait?
by Sohail Somani 20 Jul '07

20 Jul '07

Hi, I know there is the tracking level trait. Is that sufficient to be able to say that T is serializable? struct T { T(some_stuff); private: some_non_default_constructing_members; }; In this case, I think tracking level will be set to track selectively but its not serializable as is. Thanks, Sohail

3 2