September 2011 - 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 asserts instead of exceptions (please change this to a way users may choose) why do we have such an odd behaviour here? >From page 1, line 3 of the docs I cite: "The interface design is in line with the precedent set by the C++ Standard Library containers" - this is not true for operator=, since std::<container>::operator= works fine for me all the time _without_ any resize. Could we please change the behaviour of multi_array::operator= to take care of resize where in need to? IMHO operator= should result in a true copy ignoring previous state. Markus

6 18

offlist - Re: [iterator] Problems with iterator_facade and const-qualification
by Neil Groves 24 May '12

24 May '12

On Sat, May 7, 2011 at 5:52 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > On Fri, May 6, 2011 at 1:51 PM, Evan Driscoll <driscoll(a)cs.wisc.edu> > wrote: > > On 05/06/2011 11:59 AM, Jeff Flinn wrote: > >> > >> You might google any_iterator, and see how other authors have addressed > >> similar problems. > > > > Great! I tried to find someone who had done something similar, figuring I > > couldn't have been the first, but all the search terms I tried were too > > generic. > > > > Thanks, > > Evan > > You can find one in the ASL that's built on iterator_facade. > http://stlab.adobe.com/classadobe_1_1any__iterator.html > > The underlying Boost.Range implementation implements an any_iterator that I believe to be similar to the one in ASL in terms of functionality. I believe that the small-buffer optimization implementation is superior to forcing the definition of a closed-set of possible type as suggested in a TODO within the ASL documentation. During my performance testing I had considerably superior performance than the ASL implementation. I wondered if you disliked my implementation, or had any feedback. Additionally I wondered what you thought about moving the Boost.Range internal any_iterator implementation into Boost.Iterator. I can't honestly imagine a good use-case for using any_iterator in preference to any_range, hence I haven't suggested this previously. This could easily be due to my lack of imagination! Can you think of a time when using an any_iterator on any interface would be superior to using an any_range? Your opinions and guidance would be much appreciated. HTH, > > -- > Dave Abrahams > BoostPro Computing > http://www.boostpro.com Regards, Neil Groves

4 5

Recommended mock framework to use with Boost?
by doug livesey 15 Mar '12

15 Mar '12

Hi -- I'm trying to learn to develop properly with C++ and Boost, and to that end am learning along with Boost.Test, as I'm a BDD coder in another language (Ruby) in my day job. I'm at the point, now, where my tests could really benefit from a mocking framework. There doesn't appear to be one in Boost (not documented, at least), so I wondered if anyone on the list could recommend a mocking framework that they use that works well with Boost.Test? Any and all advice gratefully received, Doug.

9 16

Boost.Generic sources?
by Nathan Ridge 05 Mar '12

05 Mar '12

I just read about the Boost.Generic library at https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic…. It looks amazing! I understand it's not fully complete, but are the sources available somewhere? Thanks, Nate.

2 5

[python] converting C++ object to PyObject
by Johan Råde 05 Dec '11

05 Dec '11

I have three C++ classes X, Y and Z that I have exported from C++ to Python using python::class_. Now I want to write a factory function like PyObject* f(char c) { if(c == 'x') return new X; else if(c == 'y') return new Y; else if(c == 'z') return new Z; else PyErr_SetString(PyExc_ValueError, "Bad function argument"); } and export that function to Python. What is missing here is code that converts X*, Y* and Z* to PyObject*. How do I write that? Thank you, Johan

4 7

Changelog for 1.47.0 does not properly warn about critical bug
by Paul Harris 02 Dec '11

02 Dec '11

Hello, I discovered this bug by accident https://svn.boost.org/trac/boost/changeset/68866 which was only linked via the ticket mentioned below, The code below demonstrates that ANY wide-character string of the same length resolves to the same UUID ! Thats pretty darn serious, I expected to see a much more serious mention in the Changelog in boost 1.47.0... for UUID, there was only a mention of a few tickets including this one: https://svn.boost.org/trac/boost/ticket/5145 which only mentioned a WARNING in the description ! "Fixed warning: use of logical && with constant operand; switch to bitwise & or remove constant [-Wconstant-logical-operand]" Surely it should say something like "UUIDs for wide character strings are totally wrong" Note also that the Changelog link for UUID goes to Utility, not UUID. The code: #include <boost/uuid/name_generator.hpp> #include <boost/uuid/nil_generator.hpp> #include <boost/uuid/uuid_io.hpp> #include <iostream> using namespace boost::uuids; using namespace std; int main() { { cout << "WIDE" << endl; const wchar_t* a = L"one long string that is something like this and that blahh"; const wchar_t* b = L"hello there you long long string that looks nothing like t"; nil_generator nil; name_generator na(nil()); name_generator nb(nil()); uuid ua = na(a); uuid ub = nb(b); cout << to_string(ua) << endl; cout << to_string(ub) << endl; } { cout << "NARROW" << endl; const char* a = "one long string that is something like this and that blahh"; const char* b = "hello there you long long string that looks nothing like t"; nil_generator nil; name_generator na(nil()); name_generator nb(nil()); uuid ua = na(a); uuid ub = nb(b); cout << to_string(ua) << endl; cout << to_string(ub) << endl; } return 0; } the result: $ g++ main.cpp && ./a.out WIDE 4ffa48af-9685-5089-97ac-fe6627ead94c 4ffa48af-9685-5089-97ac-fe6627ead94c NARROW 73030b72-a864-5c7b-9963-c0bedff1283e da8943a6-26c9-5641-bd37-427b1b70d619 $ The two different wchar_t strings resolve to the same uuid !!! What am I doing wrong? thanks Paul

3 3

Manipulating boost::multi_array
by kelvSYC 30 Nov '11

30 Nov '11

Right now, I'm using boost::multi_array for implementing a dynamic-sized matrix for an algorithm in which the number of rows and columns therein may wildly fluctuate (is boost::multi_array even the right class for this?). What's frustrating me is how I can do any and all of the following: 1. Remove a single row or column from a matrix 2. Insert a single row or column to a matrix 3. Augment two matrices together 4. Swap two rows or columns Is there any way to do the first three without calling resize() and moving the elements around manually? For the last, does something like std::swap(A[row1], A[row2]) work?

3 3

Re: [Boost-users] multi_array with large dimensions crashes
by Jothy 28 Nov '11

28 Nov '11

Hi Pierre, Sorry for the late reply. The code work now, thanks very much. But the programme crashes with a run-time error when the dimensions of the array are huge 500x500x500. This is probably due to the limitation of the 32 bit addrress space. Is there any other work around. I heard of creating arrays with strides and allocating them in different blocks of memory rather than in contiguos memory? Thanks again Jothy On Wed, Aug 24, 2011 at 6:25 PM, Pierre-Andre Noel < noel.pierre.andre(a)gmail.com> wrote: > Yes, 500, 300 and 400 were the example dimensions you used in your earlier > message. > > Did you got it to work? > > Pierre-André > > PS: This email was not sent to the whole list. > > > > On Wed, Aug 24, 2011 at 11:55 AM, Jothy <jothybasu(a)gmail.com> wrote: > >> You mean 500,300,400 are the required dimesnions and xDim,yDim,zDim are >> site_type parameters. >> >> So the code should be like below I guess for an array of [x][y][z] >> >> >> array_ref_type::size_type xDim(x), yDim(y), zDim(z); >> >> array_storage_type Storage(xDim*yDim*zDim); >> array_ref_type Array(&Storage.front(),boost::extents[xDim][yDim][zDim]); >> >> Thanks >> >> Jothy >> >> >> >> >> >> >> On Wed, Aug 24, 2011 at 3:51 PM, Pierre-Andre Noel < >> noel.pierre.andre(a)gmail.com> wrote: >> >>> >> I am not familiar with multi_array, but it seems that you are creating >>> a >1GB object on the stack. This will almost always crash. Try creating it >>> on the heap instead. Be prepared for std::bad_alloc. >>> >>> > But how to do this? I am new to c++. >>> >>> I suggest you to either 1. read on the operators "new" and "delete" or 2. >>> use a std::vector to allocate the memory then use a boost::multi_array_ref >>> to refer to it. Here's an example: >>> >>> #include <vector> >>> #include <boost/multi_array.hpp> >>> >>> int main() >>> { >>> typedef float data_type; >>> typedef std::vector<data_type> array_storage_type; >>> typedef boost::multi_array_ref<data_type,3> array_ref_type; >>> >>> array_ref_type::size_type xDim(500), yDim(300), zDim(400); >>> array_storage_type Storage(xDim*yDim*zDim); >>> array_ref_type >>> Array(&Storage.front(),boost::extents[xDim][yDim][zDim]); >>> // You may now use Array as usual. >>> } >>> >>> Hope it helps, >>> >>> Pierre-André Noël >>> >>> >>> On Wed, Aug 24, 2011 at 5:20 AM, Jothy <jothybasu(a)gmail.com> wrote: >>> >>>> Thanks for pointing this out. >>>> >>>> But how to do this? I am new to c++. >>>> >>>> Jothy >>>> >>>> >>>> On Tue, Aug 23, 2011 at 10:42 PM, Juraj Ivančić < >>>> juraj.ivancic(a)gmail.com> wrote: >>>> >>>>> On 23.8.2011. 12:18, Jothy wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I have just started to use boost libs. I am trying to create a large >>>>>> float array (mandatory for my purpose). it works fine till certain >>>>>> limit, but crashes above that. I think it about allocating memory in >>>>>> the >>>>>> stack. >>>>>> >>>>>> My code is like this >>>>>> >>>>>> typedefboost::multi_array<**float,3>array_type; >>>>>> typedefarray_type::indexindex; >>>>>> array_typeArray(boost::**extents[xDim][yDim][zDim]);//**500,300,400 >>>>>> for instance >>>>>> >>>>>> >>>>>> Can some one help me to resolve this? >>>>>> >>>>> >>>>> I am not familiar with multi_array, but it seems that you are creating >>>>> a >1GB object on the stack. This will almost always crash. Try creating it >>>>> on the heap instead. Be prepared for std::bad_alloc. >>>>> >>>>> HTH >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> Boost-users mailing list >>>>> Boost-users(a)lists.boost.org >>>>> http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<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 >>>> >>> >>> >>> _______________________________________________ >>> 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 >> > >

4 3

dubious range mismatch prerequisite
by Krzysztof Żelechowski 17 Nov '11

17 Nov '11

The documentation for mismatch, as applied to ranges, says that rng2 must be at least as long as rng1. Why is this precondition necessary? The precondition is impossible to evaluate for bare input iterators without destroying the iterators, whereupon it is impossible to call mismatch any more. IMHO, it would be perfectly reasonable to stop at the end of rng2 if rng2 is shorter. <URL: http://www.boost.org/doc/libs/1_47_0/libs/range/ doc/html/range/reference/algorithms/non_mutating/mismatch.html >

2 1

[mpi/serialization] Potential bug or just library misunderstanding?
by Tim Jacobs 10 Nov '11

10 Nov '11

I'm not sure why the following test-class produces this error: "MPI_Recv: MPI_ERR_TRUNCATE: message truncated" If the std::map has only a single element (ie I remove one of the test[].push_back() lines) the error does not occur. Can someone verify that this is indeed a bug and not just novice misuse of the library? Thanks, Tim #include <boost/mpi.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/map.hpp> int main( int argc, char * argv [] ) { boost::mpi::environment env(argc, argv); boost::mpi::communicator world; if(world.rank()==0){ std::map<int, std::vector<std::string> > test; test[1].push_back("FOO"); test[50].push_back("BAR"); world.send(1, 1, boost::mpi::skeleton(test)); world.send(1, 1, boost::mpi::get_content(test)); std::cout << "sent" << std::endl; } else{ std::map<int, std::vector<std::string> > test; world.recv(0,1,boost::mpi::skeleton(test)); world.recv(0,1,boost::mpi::get_content(test)); } }

4 6