- Boost-users - lists.boost.org

Modifying all matching elements in a Boost.MultiIndex Container
by Amit Prakash Ambasta 02 Jan '16

02 Jan '16

Hi, I am trying to modify members of all elements matching value for a given index in a boost.multiindex container index.modify( index.find(value), [](T& element) { ... } ) seems to update a singular element(first match) On the other hand, std::pair<index::iterator, index::iterator> iter = index.equal_range(value); while(iter.first != iter.second) { index.modify( iter.first, [](T& element) { ... } ); iter.first++; } leads to segfaults and unexpected behavior. What would be right way to approach this?

3 4

Pointer to objects in Boost.MultiIndex
by Amit Prakash Ambasta 02 Jan '16

02 Jan '16

Consider the following code snippet: #include <iostream> #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> using namespace std; using namespace boost::multi_index; struct LinkList; struct LinkList { size_t index; LinkList* parent; LinkList(size_t index, LinkList* parent) : index(index), parent(parent) {} }; struct llindex {}; typedef ordered_unique<tag<llindex>, member<LinkList, size_t, &LinkList::index> > LinkListIndex; typedef boost::multi_index_container<LinkList, indexed_by<LinkListIndex> > IndexedLinkList; template <typename T> void show(T& iterable) { for(auto const& element: iterable) { if(element.parent != nullptr) { std::cout << "Index<" << element.index << ">: " << element.parent->index << std::endl; } else { std::cout << "Index<" << element.index << ">: " << "NULL" << std::endl; } } } int main() { IndexedLinkList ill; auto &index_ll = ill.get<0>(); ill.insert(LinkList{0, nullptr}); ill.insert(LinkList{1, (LinkList*)(&(*index_ll.find(0)))}); ill.insert(LinkList{2, (LinkList*)(&(*index_ll.find(0)))}); ill.insert(LinkList{3, (LinkList*)(&(*index_ll.find(2)))}); show(ill); return 0; } Would (LinkList*)(&(*index__ll.find(value))) be the recommended way to fetch the pointer to parent?

2 3

[BGL] Are normal and reverse undirected edges the same or different?
by Ireneusz Szcześniak 01 Jan '16

01 Jan '16

Hi, In an undirected graph, we create an undirected edge: add_edge(a, b, g); We get the reverse of that edge: edge(b, a, g); Now, are these two edges the same or different? vIf I compare them with the == operator, they are equal, but they have different source and target vertexes. Can I count on this behavior? Will it stick? I'm asking because I couldn't find it in the documentation. Please find attached my unit test. On Debian Jessie, I'm compiling it with: g++ test.cc -l boost_test_exec_monitor -l boost_unit_test_framework -o test Thanks & best, Irek

1 0

[Boost.Serialization][Boost.Iterators] Problem with Boost 1.59.0 in Solaris with SunCC
by dariomt＠gmail.com 31 Dec '15

31 Dec '15

Hi all, I have found a problem compiling Boost, in libs/serialization/src/basic_text_oprimitive.cpp the usage of boost::iterator::iterator_facade is problematic. I have reduced it to a two line minimal case: #include <boost/archive/iterators/ostream_iterator.hpp> boost::archive::iterators::ostream_iterator<char> it; Trying to compile this with SunCC 5.10 (Sun Studio 12.1) in Solaris I get the following error: "boost/iterator/iterator_facade.hpp", line 779: Error: value is not a member of boost::iterators::detail::is_traversal_at_least<std::output_iterator_tag, boost::iterators::bidirectional_traversal_tag>. "boost/archive/iterators/ostream_iterator.hpp", line 40: Where: While specializing "boost::iterators::iterator_facade<boost::archive::iterators::ostream_iterator<char>, char, std::output_iterator_tag, boost::archive::iterators::ostream_iterator<char>&, int>". "boost/archive/iterators/ostream_iterator.hpp", line 40: Where: Specialized in boost::archive::iterators::ostream_iterator<char>. "fail.cpp", line 2: Where: Specialized in non-template code. I guess it must be some bug in the compiler, because if I try to instantiate directly the template mentioned in the error message it works fine. (i.e. value is indeed a member). #include <boost/iterator/iterator_facade.hpp> const bool value = boost::iterators::detail::is_traversal_at_least< std::output_iterator_tag, boost::iterators::bidirectional_traversal_tag >::value; For reference, this problem was *not* present in Boost 1.55.0. Thanks! PS: I have mentioned both libraries in the subject because I don't know if this is a problem with Boost.Iterator code, or with the usage of that library from Boost.Serialization.

3 2

[iostreams] Fix for Ticket #11860
by Gagan Kumar 28 Dec '15

28 Dec '15

Bug Ticket ( https://svn.boost.org/trac/boost/ticket/11860 ) says "Using iostreams causes lots of messages about deprecated header template_arity_spec.hpp". Thus to reduce messages about deprecated header, I created a pull request here https://github.com/boostorg/iostreams/pull/24 . Regards Gagan

1 0

Implementation Of Natural Sort for C++
by Gagan Kumar 27 Dec '15

27 Dec '15

In Boost Trac, I found Natural Sort as Ticket #11021 (new Feature Requests). I too think it will be good for C++ to have it too. Thus I tried to make my Implementation on Natural Sort. Here, https://github.com/scopeInfinity/NaturalSort Can this be included in Boost extensions, or can you please guide me to make it better so that It can be included. Regards Gagan Kumar Natural Sort Example - Inputs : Hello 100 Hello 34 Hello 9 Hello 25 Hello 10 Hello 8 Normal Sort Output : Hello 10 Hello 100 Hello 25 Hello 34 Hello 8 Hello 9 Natural Sort Output : Hello 8 Hello 9 Hello 10 Hello 25 Hello 34 Hello 100 | | | | | | | | | | | scopeInfinity/NaturalSortNaturalSort - C++ Implementation of Natural Comparision and Natural Sort | | | | View on github.com | Preview by Yahoo | | | | |

1 0

[multi_index] do erase() call key extractors?
by Nick Stokes 26 Dec '15

26 Dec '15

This is probably rather obvious, but I wasn't able to locate this guarantee in MIC docs. Take, struct Foo { explicit Foo(Bar* b = nullptr) : bar(b) {} Bar* bar; }; int getBarValue (const Foo& f) { assert( f.bar ); return f.bar->getValue(); } boost::multi_index< Foo, indexed_by< < hashed_unique < member<Foo, Bar* , &Foo::bar > >> , hashed_non_unique < global_fun<const Foo&, int, &getBarValue >> >> FooIndex; void grill() { FooIndex fooIndex; Bar* b; { auto bWork = make_unique<Bar>(); // ... fooIndex.emplace( bWork.get() ); b = bWork.get(); } fooIndex.erase(b); // ... } Please ignore the fact that raw-pointers are potentially dangerous etc. The question is does erase() call getBarValue() despite the fact I am using the first index? More generally, do key extractors get called *at all* except at the point of insertion? Thanks, Nick

2 4

template error when using multi_index_container
by John M. Dlugosz 25 Dec '15

25 Dec '15

I'm getting a strange template instantiation error with a simple and reasonable use of multi_index_container, which I've written up in detail with a minimal program to reproduce here: http://stackoverflow.com/questions/34450642/why-is-this-member-function-a-d… This showed up in Visual Studio 2015, and has worked just fine for years on VS10 and on other platforms. I've tried updating Boost and new versions don't make any difference. This example was prepared using Boost 1.59, and I see the same thing with 1.60. —John

2 1

[container] Boost 1.60 Release link error
by Hickman, Steve (AdvTech) 25 Dec '15

25 Dec '15

Getting a linker error with the Windows version of Boost on release only (not debug) using v 1.60. This did not show up with 1.58 (I skipped 1.59 so I have no comment on it). I'm using the prebuilt libraries: 8> Creating library D:\GITRepos\fd_x-current_feature\source\Devices\MockDevice\Test\Release\MockTest.lib and object D:\GITRepos\fd_x-current_feature\source\Devices\MockDevice\Test\Release\MockTest.exp 8>MockDevice.lib(Mock.obj) : error LNK2001: unresolved external symbol "public: void __thiscall boost::container::container_detail::has_member_function_named_construct<class boost::container::new_allocator<char> >::BaseMixin::construct(void)" (?construct@BaseMixin@?$has_member_function_named_construct@V?$new_allocator@D@container@boost@@@container_detail@container@boost@@QAEXXZ) 8>MockDevice.lib(Mock.obj) : error LNK2001: unresolved external symbol "public: void __thiscall boost::container::container_detail::has_member_function_named_construct<class boost::container::new_allocator<struct boost::container::container_detail::tree_node<struct std::pair<class boost::container::basic_string<char,struct std::char_traits<char>,class boost::container::new_allocator<char> > const ,struct boost::interprocess::ipcdetail::ref_count_ptr>,void *,0,1> > >::BaseMixin::construct(void)" (?construct@BaseMixin@?$has_member_function_named_construct@V?$new_allocator@U?$tree_node@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$new_allocator@D@container@boost@@@container@boost@@Uref_count_ptr@ipcdetail@interprocess@3@@std@@PAX$0A@$00@container_detail@container@boost@@@container@boost@@@container_detail@container@boost@@QAEXXZ) 8>D:\GITRepos\fd_x-current_feature\source\Devices\MockDevice\Test\Release\MockTest.exe : fatal error LNK1120: 2 unresolved externals Steve Hickman System Architect, Human Machine Collaboration Honeywell | Aerospace Office: 480-236-8367 steve.hickman(a)honeywell.com https://in.honeywell.com/sites/aero/Pages/Home.aspx

3 2

Boost 1.60 causes argument-dependent-lookup issues.
by John M. Dlugosz 24 Dec '15

24 Dec '15

See http://stackoverflow.com/questions/34449254/how-is-argument-dependent-looku… I found that code that has worked OK on previous versions of Boost (and does not have this issues with 1.59) is getting unexpected ambiguities in 1.60. Using boost::totally_ordered et al. (even as a private base) appears to be polluting the namespace in which the client class appears. Something like this: class C : boost::totally_ordered<C> { ⋯ } ; using std::make_shared; ⋮ auto p= make_shared<C>(args); this complains that it finds boost::make_shared via argument-dependent lookup, as well as the expected std::make_shared.

1 0