- Boost - lists.boost.org

[tti] Write access to Boost
by Edward Diener 09 Aug '11

09 Aug '11

For my TTI library I need write access to the Boost repository si I can check the library into the trunk and maintain it there. Eddie Diener

2 2

[function][bind] Crash with g++ 4.5.0 -O[23]
by Daniel Larimer 08 Aug '11

08 Aug '11

I recently wrote some code that only crashes with g++ 4.5.0 -O[23] and am not sure whether it is a g++, boost::bind, or boost::function bug. I have prepared a minimum test case that crashes every time: 0 test 0x00000001000016ba Private::method_name(std::string const&) + 26 1 test 0x0000000100001348 boost::detail::function::function_obj_invoker1<boost::_bi::bind_t<void_t, boost::_mfi::mf1<void_t, Private, std::string const&>, boost::_bi::list2<boost::_bi::value<Private*>, boost::arg<1> > >, void_t, std::string const&>::invoke(boost::detail::function::function_buffer&, std::string const&) + 24 2 test 0x00000001000027bb boost::detail::function::void_function_obj_invoker2<functor<std::string, boost::function<void_t ()(std::string const&)> >, void, std::string const&, std::string&>::invoke(boost::detail::function::function_buffer&, std::string const&, std::string&) + 59 3 test 0x0000000100003893 Private::test() + 2723 4 test 0x00000001000012d8 main + 56 5 test 0x0000000100001250 start + 52 Mac OS X 10.6 Snow Leopard g++-4.5.0 -O3 or -02 crashes g++-4.5.0 -O1 works. g++-4.2 -O3 works. g++-4.0 -O3 works llvm-g++-4.2 -O3 works The odd thing is that if I replace boost::bind() with my own custom functor then it does not crash. If I include both working and non-working functors (uncomment code) then they both work. Because older versions of g++ work (pre C++0x support) it could be a bug in how boost::function or boost::bind use rvalue references. Because replacing boost::bind() with my own custom functor also fixes it, I suspect that the problem, if not g++, lies in boost::bind. If I remove boost::function from the equation by creating functor<Seq,Functor> with Functor = TYPEOF( boost::bind( ... ) ) via the use of a helper method, then it also does not crash. Thus some combination of creating a boost::function<...> from a boost::bind() functor on g++4.5 causes the crash.

2 2

[Containers] Should flat_* expose implementation vector?
by Phil Endecott 08 Aug '11

08 Aug '11

Dear All, Should Ion's proposed flat_set, flat_map etc. expose the underlying vector that they use as their implementation? Pros: it lets the user efficiently load and save the content, and implement algorithms that cannot be done via the flat_* interface. Cons: it lets the user break the invariants. Const access to the impl is another possibility. Related to that: could the implementation type be a template parameter? Example: could one implement a flat_set on top of a stable_vector? (Is that useful?) And/or: should flat_* actually be adaptors that take a reference to their underlying implementation? Regards, Phil.

8 10

[gsoc] mentor summit
by Andrew Sutton 08 Aug '11

08 Aug '11

Mentors, If you are interested in attending the mentor summit (Mountain View, CA Oct 22-24 -- check the calendar that might be wrong), please let me know. We send 2 people to represent Boost. I will not be one of them since I have a prior engagement. The reimbursement scheme looks like it's going to change this year. Essentially, Boost (actually the SFC) will submit a single purchase order for mentored projects + the cost of mentor summit air travel. That means that actual reimbursement for your flight costs may not happen until... I don't know. June 2012? The process is ridiculously slow, and I never got word that Boost received mentor payments from last summer. Andrew

1 0

[Date Time] bug in documentation example (Localization Demonstration)
by Frédéric Bron 08 Aug '11

08 Aug '11

In "Localization Demonstration": http://www.boost.org/doc/libs/1_47_0/doc/html/date_time/examples.html#date_… 11 should be 12 and 6 should be 7 in the following lines: std::copy(&de_short_month_names[0], &de_short_month_names[11], std::back_inserter(short_months)); std::copy(&de_long_month_names[0], &de_long_month_names[11], std::back_inserter(long_months)); std::copy(&de_short_weekday_names[0], &de_short_weekday_names[6], std::back_inserter(short_weekdays)); std::copy(&de_long_weekday_names[0], &de_long_weekday_names[6], std::back_inserter(long_weekdays)); Regards, Frédéric

1 0

Boost.Atomic, pushing forward and a little request for help
by Helge Bahmann 07 Aug '11

07 Aug '11

Hi folks, from the comments to Boost.Lockfree I understand that you consider a non-reviewed Boost.Atomic as a "blocker"? I apologize that I have not pushed forward for review (considering that "it just works for me", and considering the length of the review queue...), but if you consider it blocking please just let me know what I would need to do to clear the path. What I will do shortly is to provide and uptodate package containing several fixes, several contributed by others (they are in the repo, but not in any release archive) as well as some missing bits to more closely match latest C++0X draft. The big sore point is still support for the various flavours of VC -- I know that there are (especially older) versions for which it is not working, but I am lacking test systems, so if you are affected please let me know and I will do my best to resolve the issues. Cheers, Helge

10 14

[interprocess::file_mapping] Please add resize method
by Dmytro Ovdiienko 07 Aug '11

07 Aug '11

Hello, Could you please add resize method to the file_mapping class? Also please don't fill file with zeros by default? This functionality increases latency spikes. Make it as quick as possible. Thanks. Best regards. Dima -- Dmytro Ovdiienko e-mail: dmitriy.ovdienko(a)gmail.com skype: dmitriy.ovdienko(a)gmail.com mobile: +38050-1909731

2 5

[containers] review
by Gordon Woodhull 07 Aug '11

07 Aug '11

Hi Ion, John, all, I apologize that I don't have time for a full review, as I'm going offline hiking for the rest of the review period. Obviously the library should be accepted. Move emulation, stateful allocators, emplace, recursive containers, ... so many excellent features. And this code has been tested as part of Interprocess for years. However, I do find the documentation lacking. While the Doxygen reference looks very complete, I want to see the overview documentation expanded, including covering the following topics: Stateful allocators seem to be unmentioned. Do they affect performance or behavior? I know this might be a big topic; links are okay. My understanding is that these are fully supported but other allocator improvements are not yet present? Out of curiosity I'd like to see a bit of text about the future directions, mentioning N1953 & N2045. Could the contents of Joachin's blog post http://bannalia.blogspot.com/2008/08/stable-vectors.html go into an overview section for stable_vector? Recursive container is not defined, also maybe link to http://en.wikipedia.org/wiki/Recursive_data_type What is it used for: directed graph. Some guideline about when it's better to use flat_*. I figure you would use such a structure when you're not doing a lot of inserts or when there are few elements. The advice can be somewhat handwavy and instruct the user to do measurements, but it should be there. Silly question, but I'm not clear how to use this ordered_unique_range_t that's in the Doxygen - is there a constant or do you default construct it or what? As earlier pointed out, a lot of the Doxygen parameters and descriptions have gotten out of sync k/x first/i etc. Well, I've run out of time. Hope this helps a little. Cheers, Gordon

3 3

[Container] boost::container::vector<bool>
by Joel falcou 07 Aug '11

07 Aug '11

It is not clear from the doc but does the vector from boost::container *don't* do the so not useful bool optimization ? Aka can I finally take a pointer to vector<bool> element ? Thanks

2 1

[Containers] Complexity of flat_*::insert(first,last)
by Phil Endecott 07 Aug '11

07 Aug '11

Hi Ion, This library looks great. A quick comment about range-insertion in the flat containers, e.g.: template<typename InputIterator> void insert(InputIterator first, InputIterator last); Requires: i, j are not iterators into *this. Effects: inserts each element from the range [i,j) . Complexity: N log(size()+N) (N is the distance from i to j) search time plus N*size() insertion time. (Note typo: i,j vs, first,last) What implementation are you assuming to get that complexity? It seems to me that it is worse than it could be if you implement it something like this (PSEUDO-CODE): template<typename InputIterator> void insert(InputIterator first, InputIterator last) { iterator m = end(); insert(end(), first, last); sort(m,end()); inplace_merge(begin(),m,end()); } (I've only ever done this with multi* containers. For set and map you'll need something to avoid duplicates.) Regards, Phil. p.s. Having typed that I have developed a feeling of deja vu. Have I asked you this before?

4 11