May 2015 - Boost - lists.preview.boost.org

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 07 May '15

07 May '15

Sorry about the README file, I pretty much just uploaded what I had to github so people can grab the source. Admittedly, things there are lacking. I'll work on filling out the readme with some instructions hopefully today. The main difference between this and a container of boost:any is that the container of boost::any still is a container of one data type, just being that one data type is a very flexible one. This container natively supports insertion of different data types. So, you could do, int my_int = 5; double my_double0 = 9342.132; double my_double1 = 987.654; std::string my_string("This is a string."); std::vector<double> my_vec; my_vector.push_back(123.456); omni my_container; my_container.push_back(my_int); my_container.push_back(my_double); my_container.push_back(my_string); my_container.push_back(my_vector); and the container happily stores the data. You can then access the data through iterators //access all doubles for (auto itr = my_container.begin<double>(); itr != my_containert.end<double>(); ++itr) { std::cout << *itr << std::endl; } or through specifying the data type and index //get the 0th element string std::cout << my_container.at<string>(0) << std::endl; -- James Armstrong

9 27

[lambda] Addressing pull requests
by Edward Diener 07 May '15

07 May '15

The maintainer for lambda in the libs/maintainer.txt list is Jaako Jarvi, who is the original author. But I see others who have made changes to the library. So I am wondering if anyone is still actively maintaining the library. There are a number of pull requests for lambda, related to updating the code for type_traits Version2, by John Maddock and myself. Is someone handling these ?

5 6

Re: [boost] Arguing about names in Boost libraries
by Vicente J. Botet Escriba 06 May '15

06 May '15

Le 25/04/11 15:21, Edward Diener a écrit : > What is wrong with the people commenting on libraries for Boost who > are so concerned about the names being used ? We are talking only > about C++ identifiers and yet there are now endless discussions where > people disagree on names or argue that some name is not what they want > or that they like some other name, with a list of names that they find > adequate. > > This is irrelevant. There is something mentally wrong about all those > peoples spending endless amounts of time around this issue. I notice > this does not happen nowadays for just one library but for ever single > library, or proposed library, which is mentioned on this mailing list. > > Is this the way all of you people actually work in your daily jobs, or > on your own projects, spending hours and days arguing with others > about C++ identifiers for every little thing ? Are you not aware of > the absurdity of your endless remarks ? > > Grow up ! Surely there are better things to do than carry on endlessly > about some name, that is should be x or y or z or some other inane > preferable list. > > It's time for somebody to say this, so I will do it. A C++ identifier > name, as long as it is vaguely about what the functionality entails, > is perfectly adequate. It does not have to satisfy everyone in the > universe. Period ! > Hi, I'm really surprised to read such a post on this forum. Vicente

4 4

C++11 compilers and fenv
by Damian Vicino 06 May '15

06 May '15

Hi, I’m implementing the safe_float library (on c++11) proposed for the GSOC . I was planning to access FENV for detecting unsafe operations on the native floating point types and include some custom pre-post conditions for testing other floating types safety conditions. Conditions come from policies passed as template parameter to give users the possibility of chose their own set of safety conditions to be enforced. An example of the conditions that can be asked is enforcing overflows to infinite does not happen. An overflow to infinite can be detected by the FE overflow flag or because the addition of two finites numbers result in an infinite one. I just found today that clang++ does not support the pragma to use FENV yet. warning: pragma STDC FENV_ACCESS ON is not supported Googling a little I found out that neither does gcc. How are c++11 boost libraries dealing with these compiler issues? I got some options in mind: — Implement everything using custom detections, this will work in every compiler, but it will run slower for everyone too. — Finding a compiler with the support, implementing the library using the FENV, and assuming compilers will support it when the library is finished and reviewed. — Detect somehow the FENV pragma was not processed and have 2 implementations. No idea how to detect something like this. Had someone dealt with similar problem already? Is there a common approach? Best regards, Damian Vicino

4 5

[ boost ] [ Trie ]
by Cosmin Boaca 06 May '15

06 May '15

Hello, I am interested in working at the Boost.Trie project which was started during GSoC 2013 and I am searching for someone who can give me some advice about what should I change / add to the current implementation, because I'm not too experienced in developing library code. However, I do not want do this during GSoC because I won't be available during the summer. I want to contribute during my spare time. If anyone thinks that can help me with this, please reply to this email. Thank you, Cosmin

8 90

BenPope x86_64 Ubuntu issue at link time
by Vicente J. Botet Escriba 06 May '15

06 May '15

Hi, I'm getting this link error /usr/bin/ld: error: /home/ben/development/boost/test/build/results/boost/bin.v2/libs/thread/test/thread__constr__FArgs_p_lib.test/clang-linux-3.7~asan~c14_libc++/debug/threading-multi/threads/thread/constr/FArgs_pass.o: multiple definition of 'operator delete(void*)' /usr/bin/ld: /home/ben/development/llvm/trunk/install/release/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan_cxx-x86_64.a(asan_new_delete.cc.o): previous definition here at http://www.boost.org/development/tests/develop/developer/output/BenPope%20x… I define it as follows #if defined _GLIBCXX_THROW void* operator new(std::size_t s) _GLIBCXX_THROW (std::bad_alloc) #elif defined BOOST_MSVC void* operator new(std::size_t s) #else void* operator new(std::size_t s) throw (std::bad_alloc) #endif { std::cout << __FILE__ << ":" << __LINE__ << std::endl; if (throw_one == 0) throw std::bad_alloc(); --throw_one; return std::malloc(s); } Is this a compiler issue, or is my definition of the operator new incorrect? Vicente

2 2

[move] unique_ptr converting constructor
by Peter Dimov 06 May '15

06 May '15

While looking at https://svn.boost.org/trac/boost/ticket/11259 I found that after implementing a converting shared_ptr constructor that takes a boost::movelib::unique_ptr, the straightforward code in the ticket still fails (with g++ in C++03 mode): namespace mystd { using boost::shared_ptr; using boost::make_shared; using boost::movelib::unique_ptr; using boost::movelib::make_unique; } mystd::unique_ptr<int> load_thing() { return mystd::make_unique<int>(1); } mystd::shared_ptr<int> get_thing() { return load_thing(); } So, out of curiosity, I looked at how unique_ptr itself implements its converting constructor. It turns out that it, too, doesn't work. mystd::unique_ptr<int const> get_thing_2() { return load_thing(); } Furthermore, the two possible ways to make the shared_ptr code work: mystd::shared_ptr<int> get_thing() { mystd::shared_ptr<int> r( load_thing() ); return r; } mystd::shared_ptr<int> get_thing() { mystd::unique_ptr<int> r( load_thing() ); return boost::move( r ); } fail for the unique_ptr<int const> case.

4 8

Re: [boost] Interest in a container which can hold multiple data types?
by Brian Wood 06 May '15

06 May '15

Joaquin M Lopez Munoz writes: > I wrote something on this some time ago, maybe worth having a look at: > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html> > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html> I look forward to someone implementing these things. Any progress? -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

Fwd: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1)
by Marshall Clow 06 May '15

06 May '15

---------- Forwarded message ---------- From: <mark.incley(a)synx.com> Date: Wed, Apr 8, 2015 at 1:29 AM Subject: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1) To: mclow.lists(a)gmail.com Hi Marshall, Please excuse the direct mail, but my mailing list posting wasn't picked up on by anyone. I believe I've found a problem in Boost.Python that causes build errors if the user has Python 3.0 or later on their system. This change appears to have been introduced after 1.58 Beta 1. Using: bjam address-model=32 runtime-link=shared toolset=msvc-12.0 --stagedir=./stage/x86 C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xtgmath.h(206) : warning C4273: 'round' : inconsistent dll linkage C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(516) : see previous definition of 'round' libs\python\src\exec.cpp(91) : error C2664: 'FILE *_Py_fopen(PyObject *,const char *)' : cannot convert argument 1 from 'char *' to 'PyObject *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast call "C:\Users\MARK~1.INC\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj.rsp" ...failed compile-c-c++ bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj… The problem appears to be this Boost.Python code that was changed some time after 1.58 Beta 1 and appears in 1.58 RC1 within boost\libs\python\src\exec.cpp at around line 91: 1.58 beta 1: FILE *fs = fopen(f, "r"); 1.58 RCs: FILE *fs = _Py_fopen(f, "r"); ← f is a char *, hence the error shown above. It expects a PyObject * as the first parameter. This code occurs within a test for #if PY_VERSION_HEX >= 0x03000000 which may explain why no-one else has reported it – I have Python 3.3.0 on my HDD. Cheers, Mark. _____________________________________ Sent from http://boost.2283326.n4.nabble.com

13 31

Interest in a container which can hold multiple data types?
by James Armstrong 06 May '15

06 May '15

Hello forum, I was wanting to gauge interest in a container I developed which can natively handle multiple data types (as opposed to using a container of boost::any). I have the templated source hosted on my github account at https://github.com/armstrhu/omni There is some documentation on the current functions under omni/doc/html/index.html. main.cpp has some example codes on inserting, retrieving, and manipulating the data within the container. The one caveat to using the container is that the function destroy<T>() must be called for all data types inserted into the container, I currently have an assert in the destructor which will hit if destroy<T>() is not called for a data type. Also, this requires using a modified version of boost/core/typeinfo.hpp, so you will need to replace the original with the one I provide. The changes simply keep the boost functionality even when C++ typeinfo is available. I am trying to guage interest in this, and if there is interest, get some feedback on additional functionality to include. The iterators I have now work, but they are inefficient and that will be fixed eventually. Currently, I'm calling the container an omni, but don't really like that name and am looking for suggestions for something better :) Thanks -- James Armstrong

5 5