- Boost - lists.boost.org

thread_specific crashes the application when it is in a .so file
by George Georgiev 03 Dec '15

03 Dec '15

Hi, Is there a known issue about boost::thread_specific when a global thread_specific object is in a .so file? The exact same code replacing it with thread_local boost::unique_ptr<Foo> works. By the way is there a macro that determines is thread_local supported from the compiler or not? Thanks, George

3 3

Documentation for boostbook
by Soul Studios 02 Dec '15

02 Dec '15

I've seen the existing documentation, and wasn't impressed- is there a better site for details on this? Something with at minimum, a copy of the DTD and an example .xml file? Thanks, Matt

1 0

compilation errors with ublas / cppad
by Peter Caspers 30 Nov '15

30 Nov '15

Hi, I think this has been asked before, but since I am not aware of any answer, I would like to bring up the topic again: When using CppAD::AD<double> with boost ublas, certain compilation errors show up. I attach a small example (ublas_cppad.cpp) and the (start of the) error messages I get (compilation_errors.txt, produced with boost 1.59.0, g++ 4.9.3, CppAD-20151124). The problem is in matrix_assign.hpp; when changing template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { return norm_inf (e1 - e2) < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } to template<class E1, class E2, class S> BOOST_UBLAS_INLINE bool equals (const matrix_expression<E1> &e1, const matrix_expression<E2> &e2, S epsilon, S min_norm) { S tmp = norm_inf (e1 - e2); return tmp < epsilon * std::max<S> (std::max<S> (norm_inf (e1), norm_inf (e2)), min_norm); } the example code compiles without errors. Can someone point out, how this should be fixed (either on boost or CppAD side)? In general, are there requirements for a type T to cooperate with ublas matrices one should be aware of? Thank you Peter

2 3

Is master branch open for bug fixes?
by Vicente J. Botet Escriba 30 Nov '15

30 Nov '15

Hi, the calendar says that master branch is open for bug fixes, but not mail has been sent to to notify it. Could some release manager confirm that? Best, Vicente

2 2

[program_options] empty string argument
by Benedek Thaler 30 Nov '15

30 Nov '15

Hi, I have the exact same problem: http://boost.2283326.n4.nabble.com/ProgramOptions-explicit-empty-string-arg… --compression '' gave me a specified, empty compression switch value, as expected, on boost 1.58. However, on 1.59, the empty string counts against the positional arguments, and causes regressions. Also, --compression='' gives: The argument for option '--compression' should follow immediately after the equal sign. What is the recommended workaround? Is it planned to be fixed/changed? Thanks, Benedek

1 0

[Boost.LLVM] Synopsis now available
by Andy Jost 29 Nov '15

29 Nov '15

I've created a new GitHub repository for this project and uploaded a synopsis of the proposed interface. I redesigned the interface, so it differs slightly from the prototype code and examples I gave before. Please take a look and provide feedback if you can! https://github.com/andyjost/Boost.LLVM/blob/master/boost_llvm.cpp -Andy

1 0

Interest in an LLVM library?
by Andy Jost 26 Nov '15

26 Nov '15

Is there interest in an LLVM library? My motivation is to simplify the dynamic creation of functions, modules, and programs by defining an EDSL modeled after the C language. LLVM provides an API based exclusively on function calls that is verbose and difficult to use. The EDSL is more expressive and easier to use. (This may remind some people of Boost.Python and indeed these libraries are similar in motivation.) The scope of this proposal is limited. The proposed library does not compile, link, optimize, save, or load anything, for example, since the LLVM API is suitable for that. Also, it may not support obscure features, even if they seem to be within its purview, since one can always make direct calls to the LLVM API. I have written about 6500 lines of prototype code in the context of another project (a compiler for the language Curry, if anyone is interested). It is not a complete solution, but is by no means trivial, either. I'll discuss that next, but since the discussion is somewhat lengthy, let me first explain what I'm looking for by sending this. I think this EDSL would make a good Boost library. If others agree, then the next step is to review the design. I need second opinions and help from more knowledgeable people to improve the design. There are a few places in particular where I think a redesign is necessary. After that, I'm happy to implement the final library (and would gladly accept help, if anyone is interested). Now, I'll show a few examples and provide links to the prototype code. First, here's how to create a module and put it in scope: module const example_module("example"); scope _ = example_module; The scope object sets the insertion point for types, functions, and global variables. We can create a type as follows: type i32 = int_(32); i32 is a 32-bit integer. It is easy to build more complex types, e.g., i32[2] is an array type, *i32 is a pointer type, and i32(i32,i32) is a function type. An expression like i32(42) produces a constexpr. As you might guess at this point, the prototype makes heavy use of SFINAE. I've gone to a lot of effort to make this work with everything I can think of, particularly multi-dimensional arrays and initializer_lists. So, an expression like (i32[3][2])({{1,2,3},{4,5,6}}) works! (Note: i32[3][2] is the C++ type int32_t[2][3] because that's the only sensible way to interpret successive calls to operator[]). We can create a struct from a sequence of types like this: type foo = struct_("foo", {i32, *i32}); Or, we can leave out the sequence to get an opaque struct. A function prototype can be created as follows: function const f = extern_(i32(i32), "f", {"i"}); This function, f, takes an i32 (named "i") and returns an i32. The function is placed in example_module, since the code appears in its scope. There are two other linkage-specifying functions: static_ and inline_. extern_ and static_ are also used to create global variables (i.e., if the type is not a function). To define the body, we create another scope: { scope _ = f; // code for f. } To understand this, we have to discuss scopes in more depth. There are three nested levels of scope: the current module, the current function, and the current basic block. The code above sets the current function to f and the current basic block to f's entry point. Generally speaking, within a function body we write statements that generate instructions. Those instructions are inserted into the current function at the end of the current basic block. To define the body, we can declare values and operate on them. For example: value i = arg("i"); Here, "arg" is a special function that fetches the named function parameter. We can add instructions to f using operators or special methods. For example: value j = i + 1; return_(j); Branches manipulate the current basic block. Here's an if statement: label true_path, false_path; if_(i, true_path, false_path); { scope _ = true_path; // code for true. } /* else */ { scope _ = false_path; // code for false. } // new basic block here. This generates instructions to test i, take the appropriate branch, and then continue to a new basic block in the right places (which depends on whether the paths terminate with a branch instruction). It also updates the scope so that statements following if_() are inserted into the new basic block. Believe me when I say it is not trivial to do this with the LLVM API. Although it is sometimes necessary to pre-declare labels as shown above, we can usually employ C++11 lambdas to simplify the encoding: if_(i , []{ /* code for true */} , []{ /* code for false */ } ); The prototype code can be found under https://github.com/andyjost/Sprite-3/tree/master/include/sprite/backend. Also, there are many examples under https://github.com/andyjost/Sprite-3/tree/master/examples. Other parts of the Sprite-3 project are unrelated to this proposal. A good example to start with generates the Fibonacci numbers (https://github.com/andyjost/Sprite-3/blob/master/examples/fib.cpp) Here's the interesting part: // Create a new module and associate it with this lexical scope. module const fib_module("fib"); scope _ = fib_module; // Declare types. auto const char_ = types::char_(); auto const i32 = types::int_(32); auto const i64 = types::int_(64); // Declare external functions. auto const printf = extern_(i32(*char_, dots), "printf"); // Define the @fib function. auto const fib = extern_(i64(i64), "fib", {"n"}); { scope _ = fib; value n = arg("n"); if_(n <(signed_) (2), []{return_(1);}); return_(fib(n-2) + fib(n-1)); } // Define the @main function. auto const main = extern_(i32(), "main"); { scope _ = main; value const x = fib(5); printf("fib(5)=%d\n", x); return_(0); } After this code runs, fib_module contains an intermediate representation of the program. The LLVM API can be used to save that to disk, compile it to assembly, link in the C library (to get printf), or JIT compile any of the functions, among other things. Thanks to everyone who made it this far :) I'm looking forward to your feedback. -Andy

9 21

[trippels-ppc64le][math] Missing quadmath.h errors
by Andrey Semashev 24 Nov '15

24 Nov '15

Hi, I'm seeing some test failures on the trippels-powerpc64le-gcc-6.0 tester that amount to Boost.Math failing to build because the quadmath.h header is missing. http://www.boost.org/development/tests/develop/developer/output/trippels-po… I understand that gcc 6.0 is an unreleased compiler, but the error is probably not a consequence of a compiler bug. Besides, another tester, Flast-FreeBSD10-gcc-6.0.0~gnu++11, passes. Is it possible that the header is not provided for powerpc64le? Or is an optional dependency whose presence is misdetected? Is this a known problem?

3 5

[teeks99][test] Test failures on MSVC 8-11
by Andrey Semashev 23 Nov '15

23 Nov '15

Hi, I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed? [1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html

6 18

[Config] boost::uint32_t != std::uint32_t on some targets
by Louis Dionne 23 Nov '15

23 Nov '15

Dear Boost, I recently fell into a trap where a program wouldn't compile because of a difference between `boost::uint32_t` and `std::uint32_t`. Specifically, I was trying to cross-compile from OS X to ARM, and the following program wouldn't compile #include <boost/cstdint.hpp> #include <cstdint> #include <type_traits> static_assert(std::is_same<std::uint32_t, boost::uint32_t>::value, ""); int main() { } I was building with arm-none-eabi-g++ -I /path/to/boost -std=c++11 -c main.cpp I have asked a question on StackOverflow [1], and I now understand why the two types are not required to be the same. However, I think it is a QOI issue that those two types are not the same, since it makes interoperating between `std::uint32_t` and `boost::uin32_t` more difficult. Is there a reason for this difference, and if not would it be reasonable to ensure that `boost::uint32_t == std::uint32_t` whenever the latter is defined, i.e. in C++11 and above? Regards, Louis [1]: http://stackoverflow.com/q/33857554/627587

3 2