March 2016 - Boost-users - lists.preview.boost.org

Boost python - pointers
by Daniel Burchardt 09 Mar '16

09 Mar '16

Hi, I have problem with pointer in function return. My code: using namespace boost::python; v8::Platform* InitializePlatform() { v8::Platform* platform = v8::platform::CreateDefaultPlatform(); return platform; } BOOST_PYTHON_MODULE(hello) { def("InitializePlatform", InitializePlatform, return_value_policy<manage_new_object>()); } Python code: import hello x = hello.InitializePlatform() Building is ok, but when i try call InitializePlatform i have error: Segmentation fault gdb: (gdb) run test.py Starting program: /usr/bin/python test.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff45b8700 (LWP 21739)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4924640 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

1 0

numeric_cast<float> throws for double infinity
by Dmitry Volosnykh 09 Mar '16

09 Mar '16

When I try to cast variable of type double (which is equal to std::numeric_limits<double>::inifinity()) to float I get exception: std::bad_cast: bad numeric conversion: positive overflow. I expected to get std::numeric_limits<float>::inifinity(). The same is true for negative infinity. Is it intended behavior or bug? In case this should be considered as bug, maybe it was fixed in more recent versions of Boost? PS. I am using stock Boost 1.54 on Ubuntu 14.04 Regrads, Dmitry.

1 0

Re: [Boost-users] [boost] [Fit] formal review starts today
by Paul Fultz II 09 Mar '16

09 Mar '16

On Monday, March 7, 2016 at 2:52:09 AM UTC-6, Edward Diener wrote: > > On 3/7/2016 12:15 AM, Paul Fultz II wrote: > > > > > > On Sunday, March 6, 2016 at 9:42:19 PM UTC-6, Edward Diener wrote: > >> > >> On 3/3/2016 6:43 AM, Vicente J. Botet Escriba wrote: > >>> Dear Boost community, sorry for the late anounce > >>> > >>> The formal review of Paul Fultz II's Fit library starts today, 2nd > March > >>> and ends on 13th March. > >>> > >>> Fit is a header-only C++11/C++14 library that provides utilities for > >>> functions and function objects. > >> > >> These are some comments/queries about the Fit documentation. > >> > >> Introduction > >> > >> The introduction says that Fit "provides utilities for functions and > >> function objects." But it seems as if Fit works only with lambda > >> functions and function objects. > > > > > > Fit works with any generalized Callable: > > > > http://en.cppreference.com/w/cpp/concept/Callable > > Please document this. A generalized Callable is a much bigger set of > functionality than just lambda functions and function objects. > > > > > > >> The term 'function' normally encompasses > >> a much larger definition in C++ which includes global functions, static > >> functions, member functions, and lambda functions. > > > > > > Which is what Callable encompasses, but I used "function" since more > > people are familiar with that than Callable. > > A 'function' and a Callable in C++ are two entirely different things. > Use the one that is precise and don't worry what people are familiar > with. Explain what a Callable is early on ( I know you explain it later > ) if you feel that people do not know what it means. > > > > > > >> Fit needs to be more > >> precise in what it says it works with. It repeatedly refers to function > >> objects and lambda functions as 'functions'. I think this vagueness of > >> terminality is really confusing in the documentation. > >> > > > > Perhaps, I should refer to the Callable concept early on then. > > See above. > > > > > > >> > >> Quick Start:Function Objects > >> > >> "We can make it behave like a regular function if we construct the > class > >> as a global variable." > >> > >> What about a non-global > >> > >> sum_f sum = sum_f(); > >> > >> makes 'sum' not behave like a regular function other than the fact that > >> the variable 'sum' may eventually go out of scope ? > >> > > > > In C++, a regular function is always global, there is no such thing as > local > > function(sans gcc extensions). > > My point is that the non-global 'sum' in my example above behaves just > as much like a regular function as your global 'sum'. You may want to > promote the idea of global function objects but I think that this is > personally a bad idea. IMO global variables of any kind are to be avoided. It is quite common in several modern C++ libraries to declare functions as global objects. There are many advantages to this. Why do you believe it should be avoided? Especially since it has the same effect as a free function. DO you believe free function should be avoided as well? > > > > > > > >> > >> Quick Start:Lambdas > >> > >> Why do we need both BOOST_FIT_STATIC_LAMBDA and > >> BOOST_FIT_STATIC_LAMBDA_FUNCTION ? I would seem that > >> BOOST_FIT_STATIC_LAMBDA_FUNCTION would be adequate and > >> BOOST_FIT_STATIC_LAMBDA is just redundant, mimicking lambda syntax to > no > >> purpose. > >> > > > > BOOST_FIT_STATIC_LAMBDA_FUNCTION and BOOST_FIT_STATIC_FUNCTION both > define a > > function at global scope, and can only be used at global scope, whereas > > BOOST_FIT_STATIC_LAMBDA can be used to constexpr initialize local > variables > > as > > well. > > It might be good to add that when the end-user first encounters > BOOST_FIT_STATIC_LAMBDA, because the name does not suggest > initialization of local objects. Furthermore I cannot imagine why one > would want to use it to initialize a local object, Really? You just said that you would prefer avoiding global functions. > so you might want to > explain the benefit of doing so as opposed to the normal syntax for > creating a lambda function. > Maybe the quick start guide isn't the place for this in the first place. > > > In fact, BOOST_FIT_LIFT uses this since it is not always clear what > > context the user might call BOOST_FIT_LIFT. > > > > > >> > >> Quick Start:Overloading > >> > >> The overloading adaptors show two or more lambda functions. Can they > >> also work with function objects ? Or a mix of lambda functions and > >> function objects ? In fact all the reamining Quick Start topics show > >> examples with lambda functions. Do they also work with function objects > ? > >> > > > > Yes it can be used with function objects. I probably should show an > example > > of > > that as well. I used the lambdas because of the terseness of them. > > Evidently the adaptors can be used with any Callable. I think you should > make that point very strongly and show that in examples also. > Agreed. > > > > > > >> > >> Quick Start:Variadic > >> > >> I do not understand what 'We can also make this print function > varidiac, > >> so it prints every argument passed into it.' means ? > >> > > > > I'll try to explain that better, but basically it will print each > argument, > > so: > > > > print("hello", 5); // Will print "hello" and 5 > > I wouldn't associate that with the word 'Variadic' but I do think you > need to explain that more clearly. > I always understood variadic to mean taking a variable number of arguments. What do you understand variadic to mean? > > > > > > >> > >> I do not think the Quick Start explains very much since it is dealing > >> with adaptors of which we know almost nothing and the explanation for > >> these adaptors and what they actually do is very terse. > > > > > > Probably can expand the explanation of adaptors a little more. > > Good idea. What do adaptors create ? They create a function. > Different function objects I would > imagine ? In that case how about the explanation that adaptors take > Callables as input and generate function object types that adapt the > original functionality of one or more Callables to some other purpose. > The examples are already show taking Callables. Are you suggesting I show an example taking a member function or something? > > > > >> > >> In the 'Signatures' section of the Overview I read: > >> > >> "All the functions are global function objects except where an explicit > >> template parameter is required." I honestly don't know what this is > >> supposed to mean. Does this refer to when function objects are referred > >> to as parameters to the adaptors, functions, and utilities of the > library > >> ? > >> > > > > I don't understand what you are asking. It means that the function is > > written > > like this in the documentation: > > > > template<class IntegralConstant> > > constexpr auto if_(IntegralConstant); > > > > But its actually a function object like this in the code: > > > > struct if_f > > { > > template<class IntegralConstant> > > constexpr auto operator()(IntegralConstant) const; > > }; > > const constexpr if_f if_ = {}; > > > > However, `if_c` is written like this in the documentation: > > > > template<bool B, class F> > > constexpr auto if_c(F); > > > > It requires the bool `B` template parameter explicity. So in the code it > is > > written as a function and not as a function object. > > I don't understand to what you are referring when you say 'function'. > Are you talking about adaptors in your library, functions in your > library, or what ? I am talking about all functions that are defined in the library, that includes adaptors as well. I am not sure how to make that clearer. > Please try to understand that your use of the word > 'function' is very broad but that the word 'function' in C++ has a much > narrower meaning. > By function, I mean something like in the example: template<class IntegralConstant> constexpr auto if_(IntegralConstant); I think everyone agrees that is a function in C++.

5 5

Command Line Options Questions
by Jon Lederman 09 Mar '16

09 Mar '16

Hi, I have two questions re: the boost command line options library: 1) I am compiling a dynamic library that links to the boost command line options library as a shared library. When I try to unload the dynamic library, I find that it isn’t properly unloaded and the boost library seems to be causing the issue. I did find that things were helped somewhat when I linked to the boost static libraries. However, it still feels unstable. Are there any particular things I should know about in this context in terms of how my makefile should be linking to boost? Or are there other things I should look at. 2) When using program options, I am getting the following error. For some reason this seemed to work with the dynamic libraries (or it may be a coincidence). Am I required to implement the << and >> operators? It had been compiling previously and stopped. After googling this issue there seems to be a lot of confusion. Any help would be greatly appreciated. in file included from /usr/include/boost/any.hpp:27:0, from /usr/include/boost/program_options/value_semantic.hpp:12, from /usr/include/boost/program_options/options_description.hpp:13, from /usr/include/boost/program_options.hpp:15, from /usr/local/src/freeswitch/src/mod/applications/mod_sc_dsp/mod_sc_dsp.cpp:23: /usr/include/boost/lexical_cast.hpp: In instantiation of 'struct boost::detail::deduce_target_char_impl<boost::detail::deduce_character_type_later<dsp_type> >': /usr/include/boost/lexical_cast.hpp:415:89: required from 'struct boost::detail::deduce_target_char<dsp_type>' /usr/include/boost/lexical_cast.hpp:674:92: required from 'struct boost::detail::lexical_cast_stream_traits<std::basic_string<char>, dsp_type>' /usr/include/boost/lexical_cast.hpp:2363:19: required from 'static Target boost::detail::lexical_cast_do_cast<Target, Source>::lexical_cast_impl(const Source&) [with Target = dsp_type; Source = std::basic_string<char>]' /usr/include/boost/lexical_cast.hpp:2543:50: required from 'Target boost::lexical_cast(const Source&) [with Target = dsp_type; Source = std::basic_string<char>]' /usr/include/boost/program_options/detail/value_semantic.hpp:89:38: required from 'void boost::program_options::validate(boost::any&, const std::vector<std::basic_string<charT> >&, T*, long int) [with T = dsp_type; charT = char]' /usr/include/boost/program_options/detail/value_semantic.hpp:170:55: required from 'void boost::program_options::typed_value<T, charT>::xparse(boost::any&, const std::vector<std::basic_string<charT> >&) const [with T = dsp_type; charT = char]' /usr/local/src/freeswitch/src/mod/applications/mod_sc_dsp/mod_sc_dsp.cpp:484:1: required from here /usr/include/boost/lexical_cast.hpp:388:13: error: static assertion failed: Target type is neither std::istream`able nor std::wistream`able BOOST_STATIC_ASSERT_MSG((result_t::value || boost::has_right_shift<std::basic_istream<wchar_t>, T >::value), desc.add_options() ("help", "Generates help message") ("dsp_type", po::value<dsp_type>(&params.dsp_type)->required(), “") where dsp_type is this: struct dsp_type { dsp_type() {} dsp_type(std::string const& val): value(val) { } std::string value; }; and I have a validator defined as this: void validate(boost::any& v, std::vector<std::string> const& values, dsp_type* /* target_type */, int) { using namespace boost::program_options; //namespace po = boost::program_options; // Make sure no previous assignment to 'v' was made. validators::check_first_occurrence(v); // Extract the first string from 'values'. If there is more than // one string, it's an error, and exception will be thrown. std::string const& s = validators::get_single_string(values); if (s == "ladspa" || s == "audioweaver" || s == "gstreamer" || s == "lv2") { v = boost::any(dsp_type(s)); } else { throw validation_error(validation_error::invalid_option_value); } } /usr/local/src/freeswitch/build/modmake.rules:214: recipe for target 'mod_sc_dsp.lo' failed make[1]: *** [mod_sc_dsp.lo] Error 1

3 4

[Fit] review - ends next 13th Mars
by Vicente J. Botet Escriba 08 Mar '16

08 Mar '16

Hi, we are on the middle of the Fit review stated on 2 Mars and that ends 13th Mars. We have not received a lot of comments, only 4 or 5 people have commented and only a formal review (reject now). I understand that the documentation needs a lot of improvements, nevertheless, this review is the occasion to give as much feedback as possible. If you want to improve this library, please take the time to do a review and share your point of view. Best, Vicente

1 0

Re: [Boost-users] [boost] [Fit] formal review starts today
by Paul Fultz II 07 Mar '16

07 Mar '16

On Sunday, March 6, 2016 at 9:42:19 PM UTC-6, Edward Diener wrote: > > On 3/3/2016 6:43 AM, Vicente J. Botet Escriba wrote: > > Dear Boost community, sorry for the late anounce > > > > The formal review of Paul Fultz II's Fit library starts today, 2nd March > > and ends on 13th March. > > > > Fit is a header-only C++11/C++14 library that provides utilities for > > functions and function objects. > > These are some comments/queries about the Fit documentation. > > Introduction > > The introduction says that Fit "provides utilities for functions and > function objects." But it seems as if Fit works only with lambda > functions and function objects. Fit works with any generalized Callable: http://en.cppreference.com/w/cpp/concept/Callable > The term 'function' normally encompasses > a much larger definition in C++ which includes global functions, static > functions, member functions, and lambda functions. Which is what Callable encompasses, but I used "function" since more people are familiar with that than Callable. > Fit needs to be more > precise in what it says it works with. It repeatedly refers to function > objects and lambda functions as 'functions'. I think this vagueness of > terminality is really confusing in the documentation. > Perhaps, I should refer to the Callable concept early on then. > > Quick Start:Function Objects > > "We can make it behave like a regular function if we construct the class > as a global variable." > > What about a non-global > > sum_f sum = sum_f(); > > makes 'sum' not behave like a regular function other than the fact that > the variable 'sum' may eventually go out of scope ? > In C++, a regular function is always global, there is no such thing as local function(sans gcc extensions). > > Quick Start:Lambdas > > Why do we need both BOOST_FIT_STATIC_LAMBDA and > BOOST_FIT_STATIC_LAMBDA_FUNCTION ? I would seem that > BOOST_FIT_STATIC_LAMBDA_FUNCTION would be adequate and > BOOST_FIT_STATIC_LAMBDA is just redundant, mimicking lambda syntax to no > purpose. > BOOST_FIT_STATIC_LAMBDA_FUNCTION and BOOST_FIT_STATIC_FUNCTION both define a function at global scope, and can only be used at global scope, whereas BOOST_FIT_STATIC_LAMBDA can be used to constexpr initialize local variables as well. In fact, BOOST_FIT_LIFT uses this since it is not always clear what context the user might call BOOST_FIT_LIFT. > > Quick Start:Overloading > > The overloading adaptors show two or more lambda functions. Can they > also work with function objects ? Or a mix of lambda functions and > function objects ? In fact all the reamining Quick Start topics show > examples with lambda functions. Do they also work with function objects ? > Yes it can be used with function objects. I probably should show an example of that as well. I used the lambdas because of the terseness of them. > > Quick Start:Variadic > > I do not understand what 'We can also make this print function varidiac, > so it prints every argument passed into it.' means ? > I'll try to explain that better, but basically it will print each argument, so: print("hello", 5); // Will print "hello" and 5 > > I do not think the Quick Start explains very much since it is dealing > with adaptors of which we know almost nothing and the explanation for > these adaptors and what they actually do is very terse. Probably can expand the explanation of adaptors a little more. > I realize that > is why it is called a 'Quick Start' is because it is just giving the > end-user a quick review of the sort of functionality that the library > entails, but I would much rather see a good Overview first before I look > at anything else in the documentation. > > More Examples > > The more examples section looks at useful cases for the library. Since I > haven't had an overview for the library yet it is disappointing that > this section comes before I really understand how the library is > organized with at least general functionality. I am now given a series > of some highly complicated library syntax without the least idea of why > any of this syntax should be as it is, what it means, or how it works. > That doesn't convince me to use the library at all. It just convinces me > that the library has some showy functionality which does clever things > for particular use cases which the library author wants to convince me I > am going to encounter in my own programming. > Probably more explanation about each of the components used to build the example will be helpful. > > Overview > > The overview section consists of explaining what a function adaptor, > static function adaptor, and decorator are. It also give me some notes > about the syntax of the documentation. I would call this section > 'Definitions' and "Documentation Syntax'. One thing it is not is an > overview of the Fit library as far as I can understand what an overview > is. I also note that following large scale sections deal in Adaptors, > Decorators, Functions, and Utilities. Since 'Functions' and 'Utilities' > are not "defined" in this Overview I am left to wonder if 'Functions' > and 'Utilities' just mean anything in the library which is not an > adaptor or a decorator, and what distinguishes a function from a utility. > This is a good point, the current overview should be called "Definitions". > > In the 'Signatures' section of the Overview I read: > > "All the functions are global function objects except where an explicit > template parameter is required." I honestly don't know what this is > supposed to mean. Does this refer to when function objects are referred > to as parameters to the adaptors, functions, and utilities of the library > ? > I don't understand what you are asking. It means that the function is written like this in the documentation: template<class IntegralConstant> constexpr auto if_(IntegralConstant); But its actually a function object like this in the code: struct if_f { template<class IntegralConstant> constexpr auto operator()(IntegralConstant) const; }; const constexpr if_f if_ = {}; However, `if_c` is written like this in the documentation: template<bool B, class F> constexpr auto if_c(F); It requires the bool `B` template parameter explicity. So in the code it is written as a function and not as a function object. > > The rest of the general About section is fairly straightforward. I still > have no idea of the general functional of the library and why I should > use it. I will only gain an idea of what the library does by reading the > specifics of each adaptor, decorator, function, and utility. This seems > to be the gist of the documentation to me. If I want to understand what > the library does for me in working with function objects and lambda > functions I have to read the specific documentation of each entity in > the library and then go back to the Quick Start and More Examples > sections to further understand how some of these entities are used. > > I think the library documentation would have been much better if there > were a discussion of what the adaptors, decorators, functions, and > utilities of the library were meant to do to enhance user programming > rather than give examples here and there of usage and then leave it up > to the end-user to figure out what, why, and how these entities are to > be used. Quite frankly I don't have a use for a library that does not > attempt to present itself as offering functionality that would be useful > for me in the domain in which the library operates. if I have little or > no idea of that domain I see no reason to think of using a library. > > Since Boost has a number of other libraries dealing with function > objects, most notable the Boost Phoenix library, which is a sort of > successor to the Boost Lambda library, I would think it would be > advantage to the library author to stress functionality in the Fit > library which goes beyond, improves on, or is different from the > functionality in Boost Phoenix, in order to 'sell' end-users on the use > of the Fit library in their code. I do realize that the Fit library > deals with C++11/C++14 idioms, which means that it may be difficult for > many end-users to understand, but I don't think it presents its > documentation in such a way that makes its functionality easier to > understand and I think it should do so. This does not mean that I will > vote right now for Fit to be accepted or not accepted as a Boost > library. I have to look much more carefully at the individual > functionality of the adaptors, decorators, functions, and utilities of > the library to understand what it actually does, before I can vote one > way or another. But I hope my comments and questions about the > documentation to the library will aid the library author in improving > the documentation for end users like me, who are very interested in > library enhancements to function object/lambda function functionality, > but who find the documentation difficult and limiting in certain ways. > Thanks for your feedback, and it will be very helpful in improving the documentation.

1 0

Re: [Boost-users] [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
by Vicente J. Botet Escriba 07 Mar '16

07 Mar '16

Le 06/03/2016 09:59, Andrey Semashev a écrit : > On 2016-03-06 05:21, Vicente J. Botet Escriba wrote: >> >> Others could be considered also as function.hpp, lambda.hpp and >> lift.hpp, as the macros are there to workaround some missing language >> features, but those are much more specialized (Boost.Core?) > > I don't think Boost.Core is the right place for them as this library > is for small generally useful components used by many libraries. The > components you pointed out seem too specialized to me, and Boost.Fit > looks like the right place for them. > |Andrey, I was thinking in Boost.Core as these are language-like emulation features, like e.g. addressof, enable_if, explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, scoped_enum, typeinfo. IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue (pending issue 2104 in CWG) identified by Eric Nibler, with the a solution based on proposal's Eric (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html) The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for any data variable. I would like something that solves this problem in Boost. BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas. I suspect that Boost.Hana should have something like that. Louis, could you tell us how do you manage with these issues? IMO, The fiw of those issues is independent from a functional utilities library, even if Fit can not work without them.|| This is way I believe that it should be extracted and Boost.Core seems the good place to me. Best, Vicente |

3 3

Visual Studio C++ and Boost Multiprecision float128
by Michel Lamoureux 06 Mar '16

06 Mar '16

Hi, I use « Visual Studio Express 2013 for Desktop » to do my C++ programming. When I come tu use Boost Multiprecision header « float128.hpp », I get the following message : Fatal error C1189 : #error : « Sorry compiler is neither GCC, not Intel, don’t know how to configure this header. » However, when I use Boost Multiprecision header « cpp_dec_float », it works well but much slowly. I guess « float128.hpp » is faster : Am I right? Is it possible to fix « float128.hpp » to suit C++ from Visual Studio? Thank you for your answer. Michel Lamoureux Envoyé par Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour Windows 10

2 1

[Fit] review - github issuess
by Vicente J. Botet Escriba 06 Mar '16

06 Mar '16

Hi, we have started to create some issues in https://github.com/pfultz2/Fit/issues, and sometimes there are some interesting discussion. I will try to add post on the MLs the issues that are conflicting so that other are aware of the discussion. Anyway, if you are curious you can always take a look at and participate also. If you want to receive the updates I believe that you just need to click on watch (top right). Best, Vicente

1 0

Re: [Boost-users] [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
by Glen Fernandes 06 Mar '16

06 Mar '16

On Sat, Mar 5, 2016 at 9:21 PM, Vicente J. Botet Escriba wrote: > Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as > the macros are there to workaround some missing language features, but those > are much more specialized (Boost.Core?) > Boost.Core is where we move code from existing Boost libraries that enables breaking cyclic dependencies between different Boost libraries. I'm not so sure new libraries will need to (or want to) put code there. Glen

1 0