- Boost - lists.preview.boost.org

Terminology check.
by Larisse Voufo 14 Oct '12

14 Oct '12

Hello -- What would happen to be the C++ word for: name lookup + overload resolution? I would have thought it was "name resolution", but the standard seems to be suggesting otherwise. Thanks, -- Larisse.

2 1

[iterator] [documentation] need help generating
by Jeffrey Lee Hellrung, Jr. 13 Oct '12

13 Oct '12

I'm a n00b regarding Boost's documentation generation. I've gone through https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted to set up my system (Windows 7, MSVC9, try to do everything from the Windows command line). I then navigate to trunk\libs\iterator\doc and run b2 (the b2 I have from the 1.51.0 release; would that matter?). I get -------- don't know how to make <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml ...found 37 targets... ...updating 5 targets... ...can't find 1 target... ...can't make 2 targets... common.mkdir ..\..\..\bin.v2\libs\iterator\doc common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0 common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml Generating Output File: ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml quickbook\iterator.qbk:24: warning: Quickbook version undefined. Version 1.1 is assumed quickbook\concepts.qbk:159: warning: line breaks generate invalid boostbook (will only note first occurrence). quickbook\facade.qbk:491: warning: in column:6, unexpected character: ` [...lots more warnings of this nature...] quickbook\facade.qbk:612: warning: in column:52, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:44, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:12, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:15, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:46, unexpected character: ` ...skipped <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook... ...skipped 2 targets... ...updated 6 targets... -------- Then I run it again: -------- ...found 37 targets... ...updating 2 targets... xslt-xsltproc.windows ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading -multi\iterator.docbook xslt-xsltproc-dir.windows html\standalone_HTML.manifest Error: no ID for constraint linkend: indirecct. ...updated 2 targets... -------- This seems to throw everything into trunk\libs\iterator\doc\html. However, these generated html documents don't seem to be the same as those in the Boost releases. For example, the table of contents is deeper in the generated index.html than the 1.51.0 release one (which looks be identical to trunk/libs/iterator/doc/index.html), and it lacks documentation for function_input_iterator. It seems like I'm doing something wrong, and I'm not really sure what to make of the various errors and warnings I'm getting. Would anyone be kind of enough to help me out here? Oh, my user-config.jam file, located in "C:/Users/Jeffrey/", looks like -------- using xsltproc : C:/Users/Jeffrey/boost-tools/libxslt-1.1.26.win32/bin/xsltproc.exe ; using boostbook : C:/Users/Jeffrey/boost-tools/xml/docbook-xsl-1.77.1 : C:/Users/Jeffrey/boost-tools/xml/docbook-xml-4.2 ; using quickbook : %BOOST_ROOT%/dist/bin/quickbook ; -------- BOOST_ROOT refers to my Boost 1.51.0 installation, and C:/Users/Jeffrey/boost-tools/bin is part of my path. Let me know if other information is needed. TIA, - Jeff

2 3

[addressof] Intel C++ 13 Warning (Cannot be suppressed)
by Joshua Boyce 13 Oct '12

13 Oct '12

addressof.hpp causes a warning under Intel C++ 13 when using the highest warning level, which cannot be suppressed using the regular #pragma directives. This causes problems when compiling user code with warnings as errors, as the header causes an error which cannot be disabled. The root of the issue seems to be that ICC thinks that an rvalue is being passed to a function which takes a non-const ref, however in this case I think it's a false positive (ICC apparently isn't smart enough to notice and analyze the implicit conversion operator). My simple workaround is to turn the temporary into an lvalue and pass that instead. After making this change I tested under MSVC 12, GCC 4.7, ICC 13, and Clang 3.1 (all under Windows) and recorded no changes in number of failed compiles or tests. Is this an acceptable change that could be merged into trunk? Thanks.

1 1

[contract] toward N3351 concepts
by Lorenzo Caminiti 13 Oct '12

13 Oct '12

Hello all, I'm reading N3351: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf It's a bottom-up approach to define concepts starting from what's needed by STL algorithms. So far so good--I like it probably more than C++0x concept proposals--N331 is simpler :) However, N3351 STL design is not fully compatible with the current STL specifications--maybe N3351 is better, more mathematically sound? In N3351, concepts are boolean constants: ``We can define concepts as simple (constant) Boolean expressions. This is useful when building constraints predicated on non-syntactic and non-semantics properties of types.`` So I can implement concepts in C++11 as boolean meta-functions using expression SFINAE to check the requirements and enable_if to disable generic algorithms when the instantiated types don't model the concepts (i.e., the concept's boolean meta-function is false). For example, that's the case for the bool{a== b} and bool{a!=b} expressions of the EqualityComparable concept below. However, N3351 says that axioms should not be checked by the compiler... ``Axioms express the semantics of a concept’s required syntax; they are assumed to be true and must not be checked by the compiler beyond conformance to the C++ syntax. Any additional checking is beyond the scope of the compiler’s translation requirements. The compiler must not generate code that evaluates axioms as preconditions, either. This could lead to program errors if the evaluated assertions have side effects. For example, asserting that distance(first, last) > 1 when the type of those iterators is istream_iterator will consume the first element of the range, causing the assertion to pass, but the algorithm to have undefined behavior.'' So what am I supposed to do with axioms? Do nothing? Axioms are just "comments" that document the semantic? For example: `` concept EqualityComparable<typename T> = requires (T a, T b, T c) { bool { a == b }; bool { a != b }; axiom { a == b <=> eq(a, b); } // true equality axiom { a == a; // reflexive a == b => b == a; // symmetric a == b && b == c => a == c; // transitive } axiom { a != b <=> !(a == b); } // complement }; So, EqualityComparable<T> is true if T 1. has == and != with result types that can be converted to bool 2. == compares for true equality 3. == is reflexive, symmetric, and transitive 4. != is the complement of == However, the compiler can only check the first of these conditions. The rest must be verified through other means (i.e. manually). '' Thanks, --Lorenzo

16 82

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 13 Oct '12

13 Oct '12

On Sat, Mar 10, 2012 at 2:06 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: >> I can look at it once I've finished my new setup. >> >> I had to reset my computer after a partial crash years ago. I never >> got around to recreating my programming setup. My computer had been >> at its maximum Operating System level back then, which is now 3 >> versions behind. For the past few months, I've had my sister's old >> laptop, with Windows Vista, and am trying to add a programming setup >> to it now. > > Hi Daryle, > > Any updates on these two? > > https://svn.boost.org/trac/boost/ticket/3030 > https://svn.boost.org/trac/boost/ticket/5970 Mr Walker? Have you gone missing in action again? :( -- Olaf

1 0

[1.52] compile errors with xcode / apple llvm 4.1
by Jochen Wilhelmy 13 Oct '12

13 Oct '12

Hi! Had anybody success in compiling an own project that uses boost with xcode 4.5.1 / apple llvm 4.1? I get this error: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits.hpp:35: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_operator.hpp:42: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_post_decrement.hpp:34: .../boost/type_traits/detail/has_postfix_operator.hpp:143:109: error: expected expression BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); ^ .../boost/config/suffix.hpp:392:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ -Jochen

1 0

build err Boost 1.51.0 for PPC64 - is this a real error?
by david.hagood＠gmail.com 12 Oct '12

12 Oct '12

I have a reproducible error attempting to build Boost 1.51.0 for a PPC64 system: libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: junk at end of line: `@plt' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: junk at end of line: `@plt' I've seen one other person report this online, but I've seen no follow-ups. 1) Is this a known issue in 1.51.0? 2) Is there a patch? 3) Should I try the 1.52.0 Beta instead? I'd rather not spend all the time building it to find there is an issue. I have 1.51.0 for PPC32, i686, X86_64, and ARM - it's just the PPC64 that fails.

2 2

Augmented trees
by Phil Endecott 12 Oct '12

12 Oct '12

Dear Experts, I find myself in need of an augmented tree. My problem is something like [but not exactly] this: - Say I have a line of text, i.e. a sequence of characters, in a variable-width font; each character stores its width in pixels. - I need to efficiently insert and remove characters. - I need to efficiently find the range of characters that spans a given range of pixels. It seems to me that an augmented tree lets me do all of those operations in log(N) time - and no other data structure offers the same performance. I'm aware of two augmented trees that have been proposed here. Francisco Jose Tapia has proposed "Countertree", but this only stores the count of elements not the sum of a property of the elements (i.e. the widths in my example). Vadim Stadnik has proposed stl_ext_adv, which is a doubly-augmented B+ tree. Has anyone looked at Vadim's code since it was proposed last year? I have a couple of concerns about Vadim's proposal: 1. It uses B+ trees, and in the discussion it was suggested that these are inferior to red-black trees in some way. 2. In order to get the property to be accumulated (i.e. the widths in my case) it requires that arithmetic can be done on the stored type itself; this is fine for e.g. a sequence of ints, but if the stored type is a struct it is necessary to add various "unnatural" operator overloads. I think I would prefer it to have some sort of user-supplied accessor to get the property to be accumulated. Is there any other work that I've overlooked? Is there a "friendly" red-black tree implementation somewhere that could be augmented relatively easily? Regards, Phil.

8 9

[1.52.0] Beta1 release available
by Daniel James 11 Oct '12

11 Oct '12

Boost release 1.52.0 beta 1 is now available from SourceForge See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8

[thread] call_once doesn't call even once
by Kim Barrett 11 Oct '12

11 Oct '12

In boost 1.52.0 beta1 In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet: #ifdef SIG_ATOMIC_MAX typedef sig_atomic_t uintmax_atomic_t; ... #else ... #endif Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.] POSIX says "Possibly volatile-qualified integer type ...". This led to boost::call_once never calling the function, because there is a comparison in call_once (epoch<this_thread_epoch) where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type. I bet there are other places that get confused by this being an unexpectedly signed type. I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause. The relevant code is new code, introduced since boost 1.51. This is a serious regression that should be a blocker for the 1.52 release. I've filed a bug for this: https://svn.boost.org/trac/boost/ticket/7499

2 1

[coroutine] new versions
by Oliver Kowalke 11 Oct '12

11 Oct '12

I've uploaded two re-factored versions - I think most of the suggestions from the review are implemented (namespace is not corrected and documentation not updated yet). 1.) http://ok73.ok.funpic.de/boost-coroutine-self.zip 2.) http://ok73.ok.funpic.de/boost-coroutine-coro.zip Version 1) requires that coroutine-fn has only one argument == coroutine<>::self_t. Other arguments are accessed via coroutine<>::self_t::get< int >() and results via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coro_t::self_t & c) { int x = c.get< 0 >(); int y = c.get< 1 >(); c.yield( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Version 2) requires that coroutine-fn has only one argument too == coroutine<> with inverted signature. Other arguments are access via coroutine<>::get(). interface provides input/output iterators. typedef coroutine< int( int, int> > coro_t; int fn( coroutine< tuple< int, int >( int) & c) { int x = c.get().get< 0 >(); int y = c.get().get< 1 >(); c( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get(); Both implementations are not optimized - I think we should get a small and clean interface first. Comments? regards, Oliver

5 19

[preprocessor] Variadics suggestion
by Kitten, Nicholas 11 Oct '12

11 Oct '12

Hi Folks, First of all, I'd like to say "thank you" to Edward Diener and Paul Mensonides for incorporating variadics support into Boost.Preprocessor, which has been on my wishlist for a long time. In fact, I wanted it badly enough that I've been using my own slightly modified version of the library assuming variadics for a while now, and I was interested to see what a cross-platform version would look like (mine was only tested on MSVC). I think the chosen approach of converting variadics to non-variadics is probably superior to the breaking algorithm changes I made in my own version, and I would humbly suggest a few more additions in the same spirit. The reason I chose to use variadics in the first place was to simplify the user interface for the common case of manipulating what I'll call a "variadic sequence," (a series of concatenated tuples), which I wanted to look similar to the following: #define FILTER_PARAMETERS (A, int, 3)\ (B, float, 2.0f)\ (C, const char*, "Howdy!") Of course, without variadics you need either a set of macros for each tuple size, or else double parenthesis around each tuple, which becomes even more burdensome when users are also required to parenthesize inner arguments, leading to gems like this one: #define FILTER_PARAMETERS ((A, (TypeConverter<double, float>), (TypeConverter<double,float>())) My solution admitting the preferred format was to replace most private SEQ_*(X) macros with SEQ_*(...), which also required modifying SEQ_ELEM() and SEQ_HEAD() to return (X) instead of X. However, it occurs to me now that a conversion function to go from variadic to regular sequences would've been easier to implement and backwards compatible; see the attached file, which I've tested in basic cases on MSVC 10 and gcc-4.3.4. The usage would be: #define SEQ (a,b,c)(1,2,3,4) BOOST_PP_VARIADIC_SEQ_TO_SEQ( SEQ ) // expands to ((a,b,c))((1,2,3,4)) I'm submitting this because I couldn't find a way to use some combination of TUPLE/VARIADICS and SEQ transformations to do the same thing succinctly, but if I'm just missing something, please let me know. Next, I would suggest having a documented IS_EMPTY(...) function for detecting an empty variadic list. Since is_empty.hpp already exists for single arguments (though undocumented), I would guess the variadic version would look quite similar. My own (MSVC) version is attached. Finally, I would suggest using the preceding IS_EMPTY(...) function to allow VARIADIC_SIZE(...) to return 0, i.e. something along the lines of: # define BOOST_PP_VARIADIC_SIZE(...) BOOST_PP_IIF( BOOST_PP_IS_EMPTY(__VA_ARGS__), 0, BOOST_PP_VARIADIC_SIZE_I( __VA_ARGS__ ) ) where BOOST_PP_VARIADIC_SIZE_I is the current definition of BOOST_PP_VARIADIC_SIZE. Thanks, -Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

9 29

[GIL] interleaved_ptr as part of API?
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, I wonder, why the definitions of interleaved_ptr [1] and and interleaved_ref [2] are provided as examples, instead of included as part of the Boost.GIL API? IMO, these make useful general-purpose utility and it could be easily copied into <boost/gil/utilities.hpp>, couldn't it? Or, into official set of Boost.GIL extensions, at least. [1] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ptr.hpp [2] http://www.boost.org/doc/libs/release/libs/gil/example/interleaved_ref.hpp Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[GIL] interleaved_ptr not advances correctly
by Mateusz Loskot 11 Oct '12

11 Oct '12

Hi, Recently, I suggested [1] to include interleaved_ptr as part of Boost.GIL API. Unfortunately, I have been experienced problems while using interleaved_ptr. I posted Christian with a small code example and brief testing suggests interleaved_ptr does not advance correctly, what leads to images corruption. I assumed using interleaved_ptr would be a nice way to avoid reinterpret_cast when attaching raw bytes buffer into image views. Despite the cast is perfectly fine, it potentially raises red alert questions (not uncommon already, here or on StackOverflow). The simple test is to iterate over pixels and rewrite from input array (vector bitmap) to output array (vector bitmapOut) using views created in two ways: 1) cast to pixel type pointer 2) using interleaved_ptr Here are two images of what I get generated into bitmapOut array: Case 1) gives correct output http://www.flickr.com/photos/mloskot/8074130396/ Case 2) gives incorrect output http://www.flickr.com/photos/mloskot/8074130218/ Here is code [2] of the sample test: (there is no load_image() provided as it would bloat the example with too specific details) /// BEGIN /////////////////////////////////////////////////////////////////////////////////////////////////// // How to use Boost.GIL views attached to bytes array with interleaved_ptr, // versus view constructed with cast to pixel type ////////////////////////////////////////////////////////////////////////////////////////////////////// std::size_t w = 512; std::size_t h = 256; std::size_t sizeRow = 1536; // 24 bits per pixel, Windows DIB std::size_t sizeImage = sizeRow * h; std::vector<unsigned char> bitmap(sizeImage); std::vector<unsigned char> bitmapOut(sizeImage); // here bitmap is filled with data (e.g. read from file, generated in memory, etc.) // bitmap = load_image() // 1) //////////////////////////////////////////////////////////////////////////////////////////////// auto src = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t const*>(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, reinterpret_cast<boost::gil::rgb8_pixel_t*>(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Simple rgb8_pixel_t to rgb8_pixel_t assignment dstIt[x] = srcIt[x]; } } assert( boost::gil::equal_pixels(src, dst) ); // 2) //////////////////////////////////////////////////////////////////////////////////////////////// typedef interleaved_ptr<unsigned char*, rgb_layout_t> rgb8_interleaved_ptr; typedef interleaved_ptr<const unsigned char*, rgb_layout_t> rgb8c_interleaved_ptr auto src = boost::gil::interleaved_view(w, h, gil::rgb8c_interleaved_ptr(&bitmap[0]), sizeRow); auto dst = boost::gil::interleaved_view(w, h, gil::rgb8_interleaved_ptr(&bitmapOut[0]), sizeRow); assert( !boost::gil::equal_pixels(src, dst) ); // loop taken from boost::gil::transform_pixels for (std::ptrdiff_t y=0; y<src.height(); ++y) { auto srcIt=src.row_begin(y); auto dstIt=dst.row_begin(y); for (std::ptrdiff_t x=0; x<src.width(); ++x) { // Interleaved_ref points to first channel of current pixel, right? // Is this access and assignment of colour components incorrect? dstIt[x][0] = srcIt[x][0]; // R dstIt[x][1] = srcIt[x][1]; // G dstIt[x][2] = srcIt[x][2]; // B } } assert( boost::gil::equal_pixels(src, dst) ); // This assertion fails! // 1/2 to 1/3 of bitmapOut is black (pixels with value 0) /// END ////////////////////////////////////////////////////////////////////////////////////////////////////// Perhaps the access to pixels and colour components should be realised with srcIt[x * num_channels]; My e-mail is not a request for help, in fact, but a kind of bug report or warning. Because the interleaved_ptr is not part of Boost.GIL but provided as an example, I don't think it's worth a ticket on Trac. I just thought it may be worth to archive this issue in the list and make the interleaved_ptr authors and other users aware of the problem. [1] http://lists.boost.org/Archives/boost/2012/10/197199.php [2] https://gist.github.com/3866213 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Windows 8 Apps]
by Johannes Sartisohn 11 Oct '12

11 Oct '12

Hello everyone, I've searched the boost website and the mailing list archives back to january and didn't find any helpful information on my subject. My question is whether there are plans to support compiling the boost library for Windows 8 using only the WinRT APIs. That is, to support boost for Windows Store/Metro Style apps in Windows 8. Or is there already a way (e.g. via preprocessor direcitve) that I didn't find, to disable the unsupported Win32 API calls when compiling on Windows? Cheers Johannes

3 3

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[boost-python, boost-build] building "hello" boost-python tutorial sample with python 3.2 on Archlinux
by Roland Puntaier 10 Oct '12

10 Oct '12

Hello! Today I have tried boost-python tutorial with Arch Linux and Python3.2. In case somebody else tries this, here are the problems that I've encounter: - I've created ~/user-config.jam with this line using python : 3.2 : /usr/bin/python ; - the current boost-build of arch is 2.0_m12-3 This still uses "print" without "(" in boost-build/tools/python.jam The nightly build of boost-build has it corrected: local full-cmd = $(python-cmd)" -c \"from sys import *; print('"$(format:J=\\n)"' % ("$(exprs:J=,)"))\"" ; - Arch has python3.2 includes in /usr/include/python3.2mu (I wonder why!) This is not detected by b2 / bjam. I worked around this by changing boost-build/tools/python.jam: includes ?= $(prefix)/include/python$(version)mu ; - the sample jamroot file in the tutorial http://www.boost.org/doc/libs/1_51_0/libs/python/example/tutorial/Jamroot assumes a boost root folder. Since boost include and lib are separate with the arch boost installation, I've commented out "use-project". Then I had to give a direct reference to libboost_python3.so. diff -u Jamroot.org Jamroot =========================== --- Jamroot.org 2012-10-10 22:21:32.928426203 +0200 +++ Jamroot 2012-10-10 22:23:15.318762363 +0200 @@ -13,14 +13,13 @@ # Specify the path to the Boost project. If you move this project, # adjust this path to refer to the Boost root directory. -use-project boost - : ../../../.. ; +#use-project boost : ../../../.. ; # Set up the project-wide requirements that everything uses the # boost_python library from the project whose global ID is # /boost/python. project - : requirements <library>/boost/python//boost_python ; + : requirements <library>/usr/lib/libboost_python3.so ; # Declare the three extension modules. You can specify multiple # source files after the colon separated by spaces. It would be great to have comments pointing to the right solution for python 3.2 and an installed boost directly in the tutorial's sample jamroot file. - Roland

1 0

[graph] Bug in metric_tsp_approx_tour?
by Morten Strandberg 10 Oct '12

10 Oct '12

Hello, I have an application where I need to approximately solve the traveling salesman problem. I tried metric_tsp_approx_tour_from_vertex, just following the boost test code. The function works as long as the provided start vertex is zero, but given any other vertex I get rubbish back. For example, given a graph with ten vertices, the returned tour can be of length 4. I am using the following graph type: typedef adjacency_matrix<undirectedS, no_property, property<edge_weight_t, double> > Graph; and the following call: metric_tsp_approx_tour_from_vertex(graph, start_v, back_inserter(tour)); Am I doing something wrong, or is this a bug? Regards, /Morten

2 1

Gauging interest in time code for broadcasters...
by Joseph Van Riper 10 Oct '12

10 Oct '12

I'd like to know if anyone might take interest in a header library that supports working with time code (as in, 01:00:00:00 which is 107892 drop-frames, or 108000 frames at 30 fps). The library would simply convert between frames (as a long) and boost::posix_time::time_duration types according to the kind of time code, and would parse or output strings according to the kind of time code. From there, you'd just leverage boost::posix_time::time_duration for any calculations you need. I realize this is kind of a special-interest library, but the broadcasting field seems so wide that something like this might be useful to quite a few people, so I thought I'd ask. - Trey

3 7

[contract] first attempt to N3351 concepts
by Lorenzo Caminiti 10 Oct '12

10 Oct '12

Hello all, I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now): http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concep… This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues. Thanks a lot! --Lorenzo

4 9

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[1.52] error on WinCE
by Jochen Wilhelmy 10 Oct '12

10 Oct '12

Hi! on WinCE I get errors of this type: boost/smart_ptr/detail/sp_counted_base_w32.hpp(73) : error C3861: 'InterlockedIncrement': identifier not found BOOST_USE_WINDOWS_H is not defined _WIN32_WCE is 0x600 therefore there is only _InterlockedIncrement (with leading underscore) in boost/detail/interlocked.hpp -Jochen

2 1

[math] build failure with BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS
by Kim Barrett 10 Oct '12

10 Oct '12

I'm attempting to upgrade from boost 1.49 to boost 1.52 beta1, and have run into a problem building the math libraries. It seems that defining BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS no longer works, leading to build failures if it is defined. This worked in boost 1.49, where I was defining it in $BOOST_ROOT/boost/math/tools/user.hpp as described in the comments therein. I've filed a ticket for this problem: https://svn.boost.org/trac/boost/ticket/7485

2 1

[1.52] release branch reopened for bug fixes ONLY
by Eric Niebler 09 Oct '12

09 Oct '12

Now that we have released the first beta, the release branch is open for bug fixes. Only bug fixes, please.[*] No new features. No new libraries. You do not need a release manager's approval to merge a bug fix. The earlier you can merge your bug fixes, the better. The branch will close again for final release preparations on Oct 29. As usual, you can see the release calendar here: http://www.boost.org/development/index.html [*] Changes to documentation are always allowed. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0

[config] Handle upcoming XP-target toolset of VC11
by Lars Viklund 09 Oct '12

09 Oct '12

Hi list. Microsoft are testing their update system for Visual Studio 2012 [1], which includes a v110_xp toolset [2] for "restoring" support for building software that may run on Windows XP. In essence, it uses a repurposed Windows 7 SDK with the VS 2012 compiler, instead of the Windows 8 SDK used in the normal v110 toolset. What implications do you think this has for Boost.Config and all the things predicated on MSC_VER, as this decorrelates the compiler version from the Windows SDK it uses. Has anyone installed these pre-release bits and given it a shot? (I've mailed boost-build@ about the Boost.Build implications.) [1] http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/08/visual-studio-20… [2] http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx -- Lars Viklund | zao(a)acc.umu.se

3 2