- Boost - lists.boost.org

[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

[ratio] error in template specialization: template parameter n1 depends on another template parameter
by Krzysztof Czainski 04 Jul '12

04 Jul '12

Hello, In order to use Boost.Ratio with my poor compiler from TI, I had to apply the attached fix. I suspect a more general fix would be desirable, should such a fix be added to Boost. However, before investigating further, I'd like to ask, if such a fix would be welcome, or is my compiler too poor to be supported by Boost.Ratio? Regards, Kris

2 3

boost.stratified -> boost.fiber
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, as requested I've renamed boost.stratified to boost.fiber. archive is avialble at : http://olk.bplaced.net/boost-fiber.zip for those in Japan, Korea, etc please use http://www.hidemyass.com/ (proxy) to circumvent http 403 from the web-hoster. regards, Oliver

1 0

[type_index] C++03 implementation in boost?
by Agustín K-ballo Bergé 03 Jul '12

03 Jul '12

After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11. It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values? I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code. Agustín K-ballo Bergé.- http://fusionfenix.com

3 6