- Boost - lists.boost.org

[multi-array] compiler errors with visual studio 2012
by nfarnsworth＠web.de 23 Mar '13

23 Mar '13

Hello, have this c++ example which compiles with Visual Studio 2010 but with Visual Studio 2012 I got this compiler errors: 1>------ Build started: Project: MultiArrayDemo, Configuration: Debug Win32 ------ 1> MultiArrayDemo.cpp 1>d:\sandbox\multiarraydemo\multiarraydemo\multiarraydemo.cpp(11):error C2059: syntax error : '<' 1> d:\sandbox\multiarraydemo\multiarraydemo\multiarraydemo.cpp(25) : see reference to class template instantiation 'Data<T>' being compiled 1>d:\sandbox\multiarraydemo\multiarraydemo\multiarraydemo.cpp(11):error C2238: unexpected token(s) preceding ';' ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== The example uses the boost 1.53 version. Here is the example code: #include "stdafx.h" #include <boost/multi_array.hpp> const int rows = 3; const int cols = 5; template<class T> struct Data { typedef boost::multi_array<T,2> data_type; typedef typename data_type::array_view<1>::type view_type; //here is the first error typedef typename data_type::index_range range; Data() :A(boost::extents[rows][cols]) { double tmp[] = {1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0}; A.assign(tmp,tmp+ (rows * cols)); } data_type A; }; int _tmain(int argc, _TCHAR* argv[]) { Data<double>* data = new Data<double>(); Data<double>::view_type myView = data->A[boost::indices[0][Data<double>::range()]]; delete data; return 0; } Does anybody know how to solve this problem? Best regards and thank you in advance Niklas

1 0

[gil] GIL_FORCEINLINE replaced with BOOST_FORCEINLINE?
by Mateusz Loskot 22 Mar '13

22 Mar '13

Hi, In boost/gil/gil_config.hpp, there is GIL_FORCEINLINE defined, but there is no easy way to undef/redefine it. Would it be a good idea to replace GIL_FORCEINLINE with BOOST_FORCEINLINE defined in boost/config/suffix.hpp? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 6

GSOC 2013
by David Bellot 22 Mar '13

22 Mar '13

Only 2 projects have been proposed so far for GSOC 2013: wake up Boost ! https://svn.boost.org/trac/boost/wiki/SoC2013 :-D

12 18

[thread] boost::async and launch::deferred - Runtime Error + PATCH
by Fernando Pelliccioni 22 Mar '13

22 Mar '13

Hi Vicente, hi all, The following code snippet throws an exception at runtime boost::future<int> f1 = boost::async( boost::launch::deferred, []() { return 123; }); int x= f1.get(); //exception thrown I am using Boost Trunk revision 83512 I attached a patch, but I'm not sure that's correct, I had no time to see the full future.hpp code I noticed that according to N3558, the future::is_ready() function should be called "ready". http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3558.pdf What do you think? Thanks and regards, Fernando.

2 2

Abstract STL Container Adaptors
by Andy Jost 21 Mar '13

21 Mar '13

Hi Boosters, Is there any interest in an abstract container adaptor library (I'll describe what I mean below)? I'm a little surprised if this has never come up in the context of Boost, but I couldn't find anything on the archives. I did find something on stack overflow (http://stackoverflow.com/questions/5329555/abstract-wrapper-for-stl-contain…) but it did not uncover an existing solution. Motivation: Sometimes we want to write functions that take a container as an argument. For instance, say I have a graph object implemented in terms of ``class Node``. I may expose an algorithm like this: void my_algorithm(Node & root, std::set<Node const *> const & marked); In this case, ``root`` is the root of a graph, and ``marked`` is a set of marked nodes. The problem with this approach is that it forces a particular choice of the set implementation onto the caller. He may, for example, prefer to use ``tr1::unordered_set``. We could get around that limitation by using a template parameter, like this: template<typename Set> void my_algorithm(Node & root, Set const & marked); The problem here is that it forces the implementer of ``my_algorithm`` to expose that code and, potentially, recompile it many times (for different Set types). In some cases, particularly when compile times are more critical than execution times, it would be preferable to let the caller choose the set implementation without losing the advantages of separate compilation. A simple solution is to write an adaptor that mimics the interface of ``set``. With that, the function call would appear as shown here: void my_algorithm(Node & root, abstract_set<Node const *> const & marked); Here, abstract_set<Node const *> is implicitly convertible from any type having the interface of std::set<Node const *>. It internally holds a reference to some implementation of a suitable set-like object and mediates interactions with the outside world through virtual methods. It seems the implementation of this would be a straightforward application of type erasure. It seems too easy, in fact, which makes me wonder whether I'm missing something. In any case, is this a good idea? -Andy

15 34

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

[container][intrusive] Treap for Boost.Container?
by Phil Endecott 20 Mar '13

20 Mar '13

Dear All, I have been playing with boost::intrusive::treap, and it seems like a useful thing. I think it would be helpful to create a boost::container::treap, i.e. a non-intrusive treap container, implemented using the intrusive version. That could make this useful data structure available to users who wouldn't otherwise need to learn how to use Boost.Intrusive. (While I'm here.... does anyone know about a list-like container that has lower memory overhead when the data type is small, i.e. ints or chars? I was considering something using chunks like a std::list< std::vector<T> >, but insertion would invalidate other iterators in the same chunk, which is unacceptable. Any ideas?) Regards, Phil.

4 3

[units] c++11 features to speed up compilation times
by Oliver Esser 20 Mar '13

20 Mar '13

Hi, I was wondering if there was a policy for boost including C++11 features into the libraries. Obviously there might be many projects out there that do not (yet) have access to a compiler implementing the new standard or choosing not to use such a compiler. Anyways I was looking for a dimensional analysis library for compile time units checking and found Boost.Units to be quite slow at compile time even for the relatively small example code in the quickstart documentation. So I've written a bit of code that follows the approach of Boost.Units but uses C++11 features (constexpr, variadic templates, suffix operator, auto). It is not a complete library that I would use in a production environment, but it looks promising, since compilation times are about a factor 2-3 faster on my machine. It would be great if some of you could take a look. https://github.com/legento/units Maybe one could add an implementation like that to Boost.Units as a C++11 compiler detected feature to speed things up. Maybe I am totally wrong and it is some coincidence that this compiles faster on my platform. I did just minimalistic 'ok it seems to work' testing and was about as thorough with measurements. So see this as an implementation sketch. Regards Oliver

3 2

C++Now 2013 is full [ 53 days before the conference ]
by Marshall Clow 19 Mar '13

19 Mar '13

Whoa. In the immortal words of W.C. Fields, "I expected this, but not so soon" We've set up a wait list in case we get any cancellations. -- 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

Re: [boost] [range][iterator] contiguous iterators
by Stefan Strasser 19 Mar '13

19 Mar '13

From [boost-users]: Am 18.03.2013 16:06, schrieb Jeffrey Lee Hellrung, Jr.: > On Sat, Mar 16, 2013 at 7:42 AM, Stefan Strasser <strasser(a)uni-bremen.de > is there any way to generically determine at compiletime whether an > iterator or a boost range refers to contiguous memory? > > is_contiguous<T *>::value == true > is_contiguous<vector<T>::iterator>::value == true > is_contiguous<std::list<T>::iterator>::value == false > AFAIK, not presently, but this has been discussed quite a bit in several > past threads on the Boost developers list. Then I'd like to suggest this again to the maintainers of Boost.Iterator and Boost.Range. I'd also like to suggest another addition to Boost.Range: a RangeOutputIterator, i.e. an OutputIterator that doesn't only accept single values, but assignment of ranges: template<class RangeOutputIterator> ... (...RangeOutputIterator out){ *out=range; where range can be any Boost.Range. You can find an implementation of this concept here, in the form of an back insert iterator that can insert entire ranges into a vector: http://pastebin.com/9M5rPDh9 Using these two things together can make generic algorithms as efficient as is possible, e.g. if the container that is being written to is a vector and the value type is a POD, there's one call to std::memcpy. think e.g. about file or database operations like database.get(1024*1024,out); This is in my "namespace detail" right now and I'd be willing to help make it public and document it. Stefan

2 8