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

[python] Crash right after initialization after ubgrading from 1.48 to 1.54
by Richi Lists 30 Oct '13

30 Oct '13

I upgraded from boost 1.48 to .154 and I thought I was done after all the compiler errors and unit tests were ironed out. But now when I start our application, it terminates immediately. This only happens with the debug build. The release build is fine. I verified that it properly links to boost-python-vc100-mt-gyd-1_54.lib and python27_d.lib The python version (2.73) is still the same that we used with boost 1.48. I tracked it down to here: Py_Initialize(); m_mainModule = boost::python::import(__main__); <-- crash here With the debugger I found out that the string object is invalid. More specifically, ob_type is 0xffffffff. So I added this exception which always throws now: Py_Initialize(); const boost::pathon::str someRandomString("someRandomString"); if(reinterpret_cast<void*>(0xffffffff) == someRandomString.ptr()->ob_type) throw std::runtime_error("Python problem"); What could be going on here? Rgds Richard

1 0

[Geometry] Compilation errors after moving to 1.55b1
by Szymon Gatner 29 Oct '13

29 Oct '13

Moving to 1.55b1 from 1.54 gives: Error 1 error C2976: 'boost::geometry::strategy::transform::translate_transformer' : too few template arguments offending line is: typedef strategy::transform::translate_transformer<Point, Point> Translate; Regards, Szymon Gatner

3 3

[Asio] Compilation errors after switching to 1.55 b1
by Szymon Gatner 29 Oct '13

29 Oct '13

I am getting very weird error after moving from 1.54 to 1.55b1: 2>C:\devel\boost_1_55_0b1\boost/asio/detail/impl/socket_ops.ipp(2224): error C2653: 'Windows' : is not a class or namespace name (..\..\lib\hexine.cpp) and many more in that file, then: 2>C:\devel\boost_1_55_0b1\boost/asio/detail/buffer_sequence_adapter.hpp(36): error C2653: 'Windows' : is not a class or namespace name (..\..\lib\hexine.cpp) Than, many errors later: 2>C:\devel\boost_1_55_0b1\boost/asio/detail/winrt_async_manager.hpp(62): error C2039: 'IAsyncAction' : is not a member of 'Windows::Foundation' (..\..\lib\hexine.cpp) This looks like C++/CLI implementation. I assume this is related to "Implemented a limited port to Windows Runtime. This support requires that the language extensions be enabled." Does it mean that switch from 1.54 to 1.55 requires changes in project settings? Visual Studio 2012 Update 3, Windows 7 Regards, Szymon Gatner

2 1

[date_time] Not built with Visual Studio 2013
by Szymon Gatner 29 Oct '13

29 Oct '13

Hi, I just built boost 1.55 beta1 with recently released VC2013 on Win7 and for some reason date-time library was not built. I didn't sepcify it when building (just hit b2 to get everything). Regards, Szymon Gatner

2 3

[Boost-users] {exception][boost::throw_exception][BOOST_NO_EXCEPTIONS] implications
by Jeff Flinn 28 Oct '13

28 Oct '13

The project I've joined [ab]uses BOOST_NO_EXCEPTIONS in 1.55b as a means to intercept exceptions thrown via boost::throw_exception() and translate them to the project's single exception type derived from std::exception, leaving me a bit queasy. That queasiness is reinforced by #ifdef BOOST_NO_EXCEPTIONS #error This header requires exception handling to be enabled. #endif in ...\boost_1_55_0b1\boost\exception\detail\exception_ptr.hpp. This implies that BOOST_NO_EXCEPTIONS is used for more that just allowing client code to supply it's own throw_exception. Does boost and/or C++ provide a better customization point to safely translate exceptions thrown by boost? (note: we're using vs2013, generally the latest gcc, and clang) Thanks, Jeff

2 1

Boost Iterator Adaptor, with a mutable member variable is optimized out incorrectly
by Jonas Hörsch 28 Oct '13

28 Oct '13

hello everyone, i am not sure if this is actually a question about boost usage. but in the attached code i'm stuck with the unlikely situation, that gcc optimizes away my code and produces garbage for -On (n>=1), while it works like intended with -O0. attached is the minimal code, with which i could reproduce the problem: on linux i686 g++ version 4.6.3 and x86_64 g++ version 4.7.2, using packaged boost_1_54_0 in both instances, i see the following: when i compile the code with optimization (-O1) % ./iterator_adaptor_weirdness -1219536795 -1219536795 and without (-O0) % ./iterator_adaptor_weirdness 4 2 is this a bug in gcc? is it wrong to use mutable variables in conjunction with iterator_adaptor? any insight is appreciated, jonas P.S.: I know, that this particular instance of the problem, might be better solved using a transform_iterator, but unfortunately that approach doesn't scale.

2 2

[Asio] Example of the "passing the buck" pattern
by Sorin Fetche 28 Oct '13

28 Oct '13

Hi all, Although the pattern of "passing the buck" has been mentioned in several places in the context of Boost.Asio, I didn't find any self-contained example that demonstrates it in a reusable manner. So, after going through all the information I could find, I tried to create such an example that demonstrates it using C++03.I would like to ask for feedback related to the attached sample code (its "Test Infrastructure" and "Test Code" sections) and double check that it does indeed depict what "passing the buck" means. For future reference I'm listing here the all the sources of information I could find related to the pattern of "passing the buck". it also turned out that a helper utility is needed in order to wrap boost::bind created handlers and have the wrapper integrate with the Asio customization points. - N3388 paper: Using Asio with C++11 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3388.pdf Chapter 7 describes this strategy to develop efficient and generic composed operations by letting their caller decide via the provided completion handler how the intermediary handlers should interact with the Asio customization points. - Thinking Asynchronously: Designing Applications with Boost.Asio https://github.com/boostcon/2011_presentations/raw/master/mon/thinking_asyn… The "Managing Complexity" chapter references the "pass the buck" strategy with slides 113 and 114 showing invocation and allocation hooks that call the hooks of a nested handler. - The implementation of higher level functions from Boost.Asio like async_read or async_write. The problem with them being an example of the pattern is that they are using custom classes for the intermediary operation handlers instead of relying on boost::bind to build them on the fly. - Asio Samples project http://sourceforge.net/projects/asio-samples For example its handler wrapper: context_alloc_handler and its usage in the echo server implementation. Thank you, Sorin Fetche

1 0

Preprocessor Recursion
by Mitch Besser 27 Oct '13

27 Oct '13

I'm trying to create a 'C' macro that will define and initialize static data. For example: STATIC_CONST_STRUCT ( A, a, MEMBER_DATA(CONST_STR, a, "Hello, a") MEMBER_DATA(CONST_STR, b, "Hello, b") MEMBER_STRUCT ( C, c, MEMBER_DATA(CONST_STR, d, "Hello, d") MEMBER_DATA(CONST_INT, e, 1) ) ); Would cause the 'C' preprocessor to create: static const struct A { CONST_STR a; CONST_STR b; struct C { CONST_STR d; CONST_INT e; } c; } = {"Hello, a", "Hello, b", {"Hello, d", 1}}; If I could use C++, this would be easy, but I'm using 'C' and it would be very helpful to have the initialization along with the declaration. I can't quite figure out how to make this work. My macros stop expanding. I suspect the recursive nature of the problem having an arbitrarily deep nesting is why. If it helps, I do have a maximum depth for the nesting. I've tried reading the docs and learn more about recursion, but I can't seem to find a solution. I suspect I'm close. Here's what I have so far (not claiming this is a good solution, so feel free to suggest anything that would make this better): #define MEMBER_DATA_TAG 0 #define MEMBER_STRUCT_TAG 1 #define MEMBER_TAG(MEMBER) BOOST_PP_SEQ_ELEM(0, MEMBER) #define MEMBER_DATA_TYPE(MEMBER_DATA) BOOST_PP_SEQ_ELEM(1, MEMBER_DATA) #define MEMBER_DATA_NAME(MEMBER_DATA) BOOST_PP_SEQ_ELEM(2, MEMBER_DATA) #define MEMBER_DATA_VALUE(MEMBER_DATA) BOOST_PP_SEQ_ELEM(3, MEMBER_DATA) #define MEMBER_STRUCT_TYPE(MEMBER_STRUCT) BOOST_PP_SEQ_ELEM(1, MEMBER_STRUCT) #define MEMBER_STRUCT_NAME(MEMBER_STRUCT) BOOST_PP_SEQ_ELEM(2, MEMBER_STRUCT) #define MEMBER_STRUCT_MEMBER_SEQ(MEMBER_STRUCT) BOOST_PP_SEQ_ELEM(3, MEMBER_STRUCT) #define MEMBER_DATA(TYPE, NAME, VALUE) ((MEMBER_DATA_TAG)(TYPE)(NAME)(VALUE)) #define MEMBER_STRUCT(TYPE, NAME, MEMBER_SEQ) ((MEMBER_STRUCT_TAG)(TYPE)(NAME)(MEMBER_SEQ)) #define IS_MEMBER_STRUCT(MEMBER_SEQ_ELEM) BOOST_PP_EQUAL(MEMBER_TAG(MEMBER_SEQ_ELEM), MEMBER_STRUCT_TAG) #define MEMBER_STRUCT_DECLARE(TYPE, NAME, MEMBER_SEQ) \ struct TYPE \ { \ BOOST_PP_SEQ_FOR_EACH(MEMBER_ELEM_DECLARE, BOOST_PP_EMPTY(), MEMBER_SEQ) \ } NAME #define MEMBER_ELEM_DECLARE(_r, _data, MEMBER_SEQ_ELEM) \ BOOST_PP_IIF \ ( \ IS_MEMBER_STRUCT(MEMBER_SEQ_ELEM), \ MEMBER_STRUCT_DECLARE \ ( \ MEMBER_STRUCT_TYPE(MEMBER_SEQ_ELEM), \ MEMBER_STRUCT_NAME(MEMBER_SEQ_ELEM), \ MEMBER_STRUCT_MEMBER_SEQ(MEMBER_SEQ_ELEM) \ ), \ MEMBER_DATA_DECLARE \ ( \ MEMBER_DATA_TYPE(MEMBER_SEQ_ELEM), \ MEMBER_DATA_NAME(MEMBER_SEQ_ELEM), \ MEMBER_DATA_VALUE(MEMBER_SEQ_ELEM) \ ) \ ); #define MEMBER_DATA_DECLARE(TYPE, NAME, VALUE) TYPE NAME #define MEMBER_VALUE_INIT(MEMBER_SEQ) \ BOOST_PP_SEQ_FOR_EACH_I(MEMBER_VALUE_INIT_DECLARE, BOOST_PP_EMPTY(), MEMBER_SEQ); #define MEMBER_VALUE_INIT_DECLARE(_r, _data, i, MEMBER_SEQ_ELEM) \ BOOST_PP_COMMA_IF(i) \ BOOST_PP_IIF \ ( \ IS_MEMBER_STRUCT(MEMBER_SEQ_ELEM), \ {MEMBER_VALUE_INIT(MEMBER_SEQ_ELEM)}, \ MEMBER_DATA_VALUE(MEMBER_SEQ_ELEM) \ ) #define STATIC_CONST_STRUCT(TYPE, NAME, MEMBER_SEQ) \ static const MEMBER_STRUCT_DECLARE(TYPE, NAME, MEMBER_SEQ) = \ { \ MEMBER_VALUE_INIT(MEMBER_SEQ) \ } Thanks. -- "лось и белка"

2 1

[geometry] Difference problem using boost geometry in 1.47
by Macumber, Daniel 26 Oct '13

26 Oct '13

I am using boost geometry in 1.47 and am pretty happy with it. However, I am having a problem performing an intersection that I can't figure out how to solve. When I difference two geometries, I am sometimes left with a result that uses reverse winding to subtract a piece of the result rather than providing a "clean" polygon with winding in one direction only. I've posted an image here that demonstrates this: http://oi42.tinypic.com/2elfp0o.jpg I get the feeling that if I were to use the right models this might somehow be fixed? If not is there an algorithm that can clean up the result? Here is the code I am using: typedef boost::geometry::model::d2::point_xy<double> BoostPoint; typedef boost::geometry::model::polygon<BoostPoint> BoostPolygon; typedef boost::geometry::model::ring<BoostPoint> BoostRing; BoostRing facePolygon; BoostRing otherFacePolygon; std::vector<BoostPolygon> faceDifferenceResult; .... boost::geometry::difference(facePolygon, otherFacePolygon, faceDifferenceResult); Any ideas are much appreciated, thanks a lot, Dan

2 1

MFC ASSERT in dllinit.cpp line 703 when using Boost.Log
by Simon Martin 25 Oct '13

25 Oct '13

Hi, I receive an assertion, when I try to use Boost.Log in one of my DLLs. I have a tools.dll, which contains my logging facility and I tried to implement to logging stuff with Boost.Log. This tools.dll is referenced by another helper.dll and both DLLs are used in the application. However, when I start the application, I get the famous ASSERT. This happens with Boost 1.54 and Boost.Log as well as with Boost 1.48 and Boost.Log 1.1. I've digged through lots of mailing lists and old postings today. What I understood so far, there's an issue with _pRawDllMain pointer in Boost.Thread, some suggested commenting it out in #include <boost/thread/detail/tss_hooks.hpp>, but this leads to memory leaks? This thread http://lists.boost.org/threads-devel/2009/06/0476.php said it would be fixed after 1.40, but I don't know, if this has been done. Dynamic linking to Boost as suggested here http://stackoverflow.com/questions/5355931/adding-include-boost-thread-mute… did not help. Any hints, what I should check? Thanks Simon

1 0