- Boost-users - lists.boost.org

[Filesystem] Reverse traversal of boost::filesystem::path::const_iterator?
by Nat Linden 02 Nov '12

02 Nov '12

I've stumbled across some code in our code base that wants to walk up a fixed number of containing parent directories from the starting path. (It's in a Mac application bundle nested within another.) boost::filesystem::path::[const_]iterator is described as bidirectional. But boost::filesystem::path has no rbegin() or rend(). In libs/filesystem/test/path_test.cpp's iterator_tests(), I see, for a path variable named itr_ck, use of boost::prior(itr_ck.end()). That suggests that usage of this form would be legal: path mypath = /* ...something... */; for (path::const_iterator rcomp(mypath.end()), rend(mypath.begin()); rcomp != rend; --rcomp) { // ... use boost::prior(rcomp) ... } Am I correct? Given the way some containers implement end(), I always feel nervous about decrementing end(). I'm happy to see that Boost.Filesystem's own tests guarantee that usage; but is there anything in the documentation that would have assured me of that?

6 8

boost::heap::skew_heap(1_51_0) ordered_iterator
by imns70 02 Nov '12

02 Nov '12

Hi This question pertains to boost::heap::skew_heap as defined here:- http://www.boost.org/doc/libs/1_51_0/doc/html/boost/heap/skew_heap.html Can you please help me understand what is the complexity of skew heap traversal using ordered_iterator. I am traversing over the heap, using ordered_iterator as shown in code below :- for(bk_heap::ordered_iterator it=buy_heap->ordered_begin();it!=buy_heap->ordered_end();it++) { /// some code here... } I suspect it to be O(n), but just want to make sure. Thanks in advance. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-heap-skew-heap-1-51-0-ordered-iter… Sent from the Boost - Users mailing list archive at Nabble.com.

1 1

advice with containers and data types
by Georg.Kellerer＠lfu.bayern.de 02 Nov '12

02 Nov '12

Hi all, i am a newbie to boost and hope, somebody here can give me an advice. i want to change the implementation of an existing container class in one of my projects. It is a container which for the moment is based on a very old roguewave version which should be replaced by boost. main features of this container are: - the container is based on a hashmap. - the key datatype can be string or int. - the value data type can be string, int, double, time, date, the container type itself and another container type. I thought about implementing the class based on a map container with boost:any as key and value type. is this possible? Or do you have other and even better recommendations for me? i am a bit confused about the great number of diferent containers and datastructures the boost library offers. Thanks in advance, Georg

2 1

[phoenix] Using with Boost.Function.
by Robert Jones 02 Nov '12

02 Nov '12

Can anyone tell me the correct incantation to get the 'Not OK' lines to work? Thx, Rob. #include <boost/function.hpp> #include <boost/phoenix/core.hpp> #include <boost/phoenix/operator.hpp> #include <boost/phoenix/bind/bind_member_variable.hpp> #include <boost/phoenix/bind/bind_function.hpp> #include <boost/function.hpp> #include <list> struct S { int i; }; void f( std::list<S> & l, int i ) { using boost::phoenix::arg_names::_1; using boost::phoenix::arg_names::_2; // OK l.remove_if( bind( & S::i, _1 ) >= i ); *// Not OK.* * boost::function<bool( int, int )> pred = _1 >= _2;* * l.remove_if( bind( pred, _1, i ) );* }

3 3

Iterator Range, sub range of a desired size
by David Kimmel 02 Nov '12

02 Nov '12

Is there a function in BOOST, given a starting point and a desired size, that returns iterators for a (sub) range? For example, given: a boost::circular_buffer which contains: 1 2 3 4 5 6 7 8 9 10 a starting point which is an iterator pointing to 5 and finally a desired size which is an int s = 4 The result of which would be iterators producing: 5 6 7 8 A possible implementation might be this (but I was hoping there was a BOOST version since I can't find an STD algorithm) template <typename Itr> std::pair<Itr, Itr> getWindowDown(Itr begin, Itr end, Itr start, const int windowSize) { // Down first, then up if need be const Itr bottom = (end - start > windowSize) ? (start + windowSize) : (end); const Itr top = (bottom - begin > windowSize) ? (bottom - windowSize) : (begin); return make_pair(top, bottom); } Thanks, -- View this message in context: http://boost.2283326.n4.nabble.com/Iterator-Range-sub-range-of-a-desired-si… Sent from the Boost - Users mailing list archive at Nabble.com.

6 17

Re: [Boost-users] [Thread] Win32 TLS problem with dynamic libraries
by Sarah Tappon 02 Nov '12

02 Nov '12

On Mon, Oct 29, 2012 at 12:31 AM, Сергей Захарченко wrote: > * Rename the Boost.Thread library into 'original_boost_thread'. > > * Add a custom target named 'patched_boost_thread' which uses dumpbin > and lib utilities to delete just the tss_pe.obj object from Boost.Thread. > > * Add a library called boost_thread which links to 'patched_boost_thread' and > contains a file named tss_pe.cpp which contains the aforementioned code > (essentially it's the 'null tss cleanup implementation'). I've been researching a similar issue and it's useful to hear from someone who has successfully implemented a workaround. A couple of follow-up questions, if you don't mind: Once the solution is in place, what (if anything) do you have to do to ensure that resources are cleaned up appropriately? Is it sufficient to call on_thread_exit() whenever a thread exits? > Assuming that I can guarantee that no Boost.Thread functions > are called from non-Boost.Thread threads, it shouldn't be > needed. Could you give me a concrete example of a call that would violate this guarantee? What happens if you violate it? Thanks, Sarah

1 0

[boost::python] exposing an abstract base class through boost::ptr_vector and the vector indexing suite
by Andy Falanga (afalanga) 01 Nov '12

01 Nov '12

Hi everyone, I have need to expose a couple of different classes which inherit from a single, abstract, C++ class. This abstract class is what I need to expose to python. Using the python wiki, I've figure out the correct way to expose these classes. However, the next dimension to this problem is that my users aren't supposed to be able to instantiate any of the derived classes directly. Instead, they are to use a function which will return a list of these objects. I've been working on the correct implementation for use with boost::ptr_vector. Now, I want to use the vector indexing suite in boost::python to expose these things. I've worked through properly making an assignment overload operator appropriate to this for use with the vector indexing suite. However, I'm stumped at this error: Error 2 error C2440: 'return' : cannot convert from 'Base' to 'Base *' c:\program files\boost\boost_1_47\boost\python\suite\indexing\vector_indexing_suite.hpp 77 Because of this error, I'm wondering if it's not possible, or at least not recommended, to use the vector indexing suite to expose boost::ptr_vectors. Is this true? I'm using Visual Studio 2010 and Boost 1.47. Thanks, Andy

1 0

[serialization] support for C++-11 types
by Marco Craveiro 01 Nov '12

01 Nov '12

Hi boost-users, Apologies if this question has been asked before - I'm sure it has, but my googling-fu is not finding decent matches. Anyways, the question is: with C++11 we have a number of new container types such as std::array, std::underdered_map/set, std::forward_list, etc. Are those supported by the latest release of the serialization library? If not, is there a trac ticket for this work? Many thanks for your time, Marco -- So young, and already so unknown -- Pauli blog: http://mcraveiro.blogspot.com

6 8

bug of boost algorithm library or boost asio?
by kpzhang 01 Nov '12

01 Nov '12

Hi, Apologize if this is not the right place for this mail. This program (it has been narrowed down from a larger program) always crashes after compiled in vs2008 Release(Win32) mode under windows 7. I am not familiar with assembly code and don't know it's a bug of compiler or boost::ends_with or boost::asio::buffers_iterator. It can be compiled and executed with g++ in Ubuntu without any problem. People said it's very unlikely to be compiler's bug, but when compiled in debug moded(or disable optimization), the problem does disappear. I have been stuck with this problem for quite a few hours. Any help is appreciated. Thanks in advance. #include <iostream>#include <string>#include <boost/asio.hpp>#include <boost/algorithm/string.hpp> typedef boost::asio::buffers_iterator<boost::asio::const_buffers_1> iterator_t;typedef boost::iterator_range<iterator_t> range_t;static const std::string LINE_END_MARK = "\r\n"; int main(int argc, char* argv[]){ boost::asio::streambuf _buf; std::ostream os(&_buf); os<<"END\r\n"; iterator_t cursor = boost::asio::buffers_begin(_buf.data()); iterator_t end = boost::asio::buffers_end(_buf.data()); std::ostream_iterator<char> it(std::cout," "); std::copy(LINE_END_MARK.begin(), LINE_END_MARK.end(), it); range_t r(cursor, end); if(!boost::ends_with(r, LINE_END_MARK)) return 0; return 1;}

4 3

__MINGW32_MAJOR_VERSION confusing, and causing problems with boost thread
by Florian Burkart 01 Nov '12

01 Nov '12

Hi, __MINGW32_MAJOR_VERSION is confusing me at the moment. Where is it coming from? What does it stand for? Even though my compiler at the moment informs me of PS C:\Sys\boost\boost_1_50_0> g++ --version g++.exe (GCC) 4.6.3 20111208 (prerelease) is is defined as 3 when boost compiles. __MINGW32_MINOR_VERSION is defined as 11. I had to hard check that, no idea where those numbers are coming from. This leads to this statement from boost_1_50_0\libs\thread\src\win32\tss_pe.cpp #if defined(__MINGW64__) || (__MINGW32_MAJOR_VERSION >3) || \ ((__MINGW32_MAJOR_VERSION==3) && (__MINGW32_MINOR_VERSION>=18)) evaluating to false and this extern "C" const IMAGE_TLS_DIRECTORY32 _tls_used __attribute__ ((section(".rdata$T"))) = to compile in, which in turn produces c:/mingw-4.6.1/bin/../lib/gcc/mingw32/4.6.1/../../../libmingw32.a(tlssup.o):tlssup.c:(.tls+0x0): multiple definition of `_tls_used' /Sys/boost/MinGW32/boost_1_50_0/lib/libboost_thread-mgw46-mt-d-1_50.a(tss_pe.o):tss_pe.cpp:(.rdata$T+0x0): first defined here when trying to link to the static library. I fixed that by hacking the 18 in the source down to a 11 and recompiling boost with PS C:\Sys\boost\boost_1_50_0> .\b2.exe --prefix=c:\Sys\boost\MinGW32\boost_1_50_0 toolset=gcc address-model=32 link=static -s BZIP2_SOURCE=C:\Sys\bzip2-1.0.6 -s ZLIB_SOURCE=C:\Sys\zlib-1.2.7 install That seems to have solved my issue for now, but I don't know if my major or minor versions are set incorrectly or whether this might a bug in the code base? Thoughts? Florian

2 2