- Boost - lists.boost.org

[format] Any interest in decoupling it from std::basic_string?
by news.gmane.org 06 Jul '12

06 Jul '12

I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.

5 11

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[exception] [type_traits] warning: unrecognized #pragma GCC system_header
by Krzysztof Czainski 06 Jul '12

06 Jul '12

Hello, Below is a list of files, that contain: #if defined(__GNUC__) #pragma GCC system_header #endif which causes a warning on my TI compiler. E:\boost\include\boost-1_50_0\boost\exception\all.hpp E:\boost\include\boost-1_50_0\boost\exception\current_exception_cast.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\error_info_impl.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\exception_ptr.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\is_output_streamable.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\object_hex_dump.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\type_info.hpp E:\boost\include\boost-1_50_0\boost\exception\diagnostic_information.hpp E:\boost\include\boost-1_50_0\boost\exception\errinfo_errno.hpp E:\boost\include\boost-1_50_0\boost\exception\exception.hpp E:\boost\include\boost-1_50_0\boost\exception\get_error_info.hpp E:\boost\include\boost-1_50_0\boost\exception\info.hpp E:\boost\include\boost-1_50_0\boost\exception\info_tuple.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string_stub.hpp E:\boost\include\boost-1_50_0\boost\throw_exception.hpp E:\boost\include\boost-1_50_0\boost\type_traits\is_virtual_base_of.hpp In other files, i.e. boost\integer.hpp, I've found this #pragma guarded against __GNUC__ >= 4: #if defined(__GNUC__) && (__GNUC__ >= 4) #pragma GCC system_header #endif which doesn't cause a warning on my compiler, because it defines __GNUC__ to 3. Could this be fixed in the files on the list above, or are there some __GNUC__ 3 compilers, that need this pragma to be enabled? Regards, Kris

3 5

[1.50.0] Release candidates available for testing
by Beman Dawes 05 Jul '12

05 Jul '12

Release candidate files for 1.50.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

Re: [boost] [cfe-dev] Using c++11 features in clang
by Marshall Clow 05 Jul '12

05 Jul '12

On Jul 5, 2012, at 12:41 PM, Joseph Galbraith wrote: > On 07/05/2012 12:29, Marshall Clow wrote: >> In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: >> http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html >> >> I don't know if this should be a FAQ entry for Boost, or for clang. >> Suggestions/comments/edits welcome. > > Isn't one of both of -std=c++11 and -stdlib=libc++ an ABI change? > > If so, it should probably be noted that all code should be build with > the same settings for these flags. Yes. > In particular, I think that you can't pass a std:: classes from libstdc++ > built code to libc++ code without bad things happening. I would expect that also, but libc++ has versioned namespaces that _should_ prevent that from happening (I.e, cause linker errors). > I'm not sure whether just turning whether the following is safe or not: > > clang++ -c -stdlib=libc++ x.cpp > clang++ -c -stdlib=libc++ -std=c++11 y.cpp > clang++ -stdlib=libc++ x.o y.o I would expect either: * It would "just work" * It would fail to link depending on what the contents of x.cpp and y.cpp were. If you can come up with a good way of explaining this, I'll be happy to add it to my post. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[interprocess] Problem building i386 binary on x86_64 MacOSX machine
by Walter Horsten 05 Jul '12

05 Jul '12

Hello, I have a program that uses boost::interprocess::message_queue, it used to compile correctly as a universal binary (i386 & x86_64) with boost version 1.47, however compiling for i386 fails with version 1.49 and 1.50. The most important parts of the error message are: - no matching function for call to 'boost::interprocess::message_queue_t<boost::interprocess::offset_ptr<void, int, long unsigned int, 0u> >::try_receive(void*, size_t, size_t&, unsigned int&)' - no matching function for call to 'get_rounded_size(long unsigned int, const unsigned int&)' ... is this a bug or is my code incorrect? (I suspect the size of the void* might have something to do with it?) The sample code in the attachment reproduces the problem on my MacBook Pro running OSX Snow Leopard (edit the boost prefix variable in the scripts to your own needs). Kind regards, Walter

1 0

[fusion] g++-4.6, deque, and c++0x compile error
by Karsten Ahnert 05 Jul '12

05 Jul '12

The following trivial program does not compile with g++-4.6.1 and std=c++0x enabled. #include <boost/fusion/container.hpp> int main( int argc , char *argv[] ) { } Seems like a bug, or should I configure something via macros?

3 5

[stratified] library for micro-/userland-threads
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, some of the community members ask me to provide a micro-/userland-thread library based on boost.context - I hope boost.stratified is a sufficient implementation. The library contains classes and interfaces similar to boost.thread. Examples and documentation (not finished and needs some updates/correction) is included. I hope I get some feedback from you. best regards, Oliver source: http://olk.bplaced.net/boost-stratified.zip documentation: http://olk.bplaced.net/boost/libs/stratified/doc/html/

9 24

[c++11] compile_if utility
by Lorenzo Caminiti 04 Jul '12

04 Jul '12

Hello all, I was thinking how to program assertion requirements in C++11. I need to program something like this if "has_equal_to<T>" then "assert(back() == value)" else do nothing, don't even compile "assert(back() == value)" Using C++11 lambdas, I was able to program a compile_if utility to do the following: compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); // compiled and executed iff has_equal_to<T> }); Any interest in adding compile_if to Boost.Utility? It could be renamed exec_if if compile_if is too "strong". I didn't play with compile_if much so there might cases where it doesn't work... but I wanted to share it with the ML anyway: #include <boost/type_traits.hpp> #include <cassert> #include <vector> #include <iostream> template< bool Boolean > struct compile_if_c { template< typename UnaryFunc > compile_if_c ( UnaryFunc f ) { std::cout << "compiling" << std::endl; f(); } }; template< > struct compile_if_c <false> { compile_if_c ( ... ) { std::cout << "not compiling" << std::endl; } }; template< class BooleanMetafunc, class UnaryFunc > void compile_if ( UnaryFunc f ) { compile_if_c<BooleanMetafunc::value> compile(f); } template< typename T > class vector { public: typedef typename std::vector<T>::const_reference const_reference; public: void push_back ( T const& value ) { vector_.push_back(value); compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); }); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; struct x {}; // no operator== int main ( void ) { vector<x>().push_back(x()); // no == so skip assertion back() == value vector<int>().push_back(123); // has == so assert back() == value return 0; } Thanks. --Lorenzo P.S. Eh, if C++11 lambda had constant captures [const&](){ assert(this->back() == value; } I could have even made the assertion constant-correct...

3 4

[Review Request] Inclusion of the Boost.Polygon Voronoi Library
by Andrii Sydorchuk 04 Jul '12

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. Features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86