- Boost - lists.boost.org

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

09 Mar '16

>> >> >> >> 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? > > Global objects, whether functions or data, increases the chances for > name clashes. Also accessing global data increases the chances for > errors in a multi-threaded environment. > > Free functions can be in a namespace, as the standard library functions > are in the 'std' namespace. This helps greatly in avoiding name > conflicts. By global variables, I mean defined at the namespace level, not solely at the global namespace level. So functions using BOOST_FIT_STATIC_FUNCTION can be defined within a namespace. Also, the function objects are `const` so there isn't an issue from multithreaded environments. > >> >> >> >> > >> > >> >> >> >> 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. > > I mean that for local objects I do not see the reason why I would ever > use BOOST_FIT_STATIC_LAMBDA instead of initializing local objects in the > normal C++ way(s). If this is not the case you need to explain what > problem(s) BOOST_FIT_STATIC_LAMBDA solve in initializing local data > which ordinary C++ initialization of local data could encounter. If > there aren't any problems BOOST_FIT_STATIC_LAMBDA solves in initializing > local data I see no purpose for its existence. > Well, they can still be passed to constexpr functions, even if they are local, I probably shouldn't discuss BOOST_FIT_STATIC_LAMBDA in the Quick Start guide because its usage is not quite as a common. >> >> 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. > > I would hope to convince you that a good Overview of your library should > come first and then all the Quick Start guides, tutorials, examples etc. > would make much more sense once your end-user understands what your > library really does in terms of at least the main general functionality. I usually start with the Quick Start guide with a library in order to get an understanding of what components are in the library and what they can do, then I start delving into the other components from there. Thats what I am showing in the Quick Start guide. I guess people have different ways of learning a library. I wonder what is needed to be explained better in a initial overview of the library. > >> >> >> > 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? > > Your terminology is fine, but I always think of variadic in terms of > variadic templates or variadic macros. After all your not making the > print function variadic in the sense of taking a variable number of > arguments. Yes, I am, so I probably need to make that more clear in the documentation. > The simple_print functionality is any of 3 different lambda > functions, with 'conditional' picking the first one that is callable and > > 'fix' passing in the callable as the first parameter. So I really > don't > understand what 'by' does here in printing each argument irregardless of > > your 'Variadic' terminology. You need invoking examples and then show > what the output would be for each invocation, and then it would be > easier for me and others to understand what 'by' does in this situation. > Yep, that part needs to go into more in-depth. >> >> >> > >> > >> >> >> >> 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? > > Global/static function, member function, std::function, boost::function, > Boost Phoenix and/or Boost lambda function objects, instantiated > template functions. My point is that you should show your library > functionality working with as many types of Callables as possible. > Instead your doc suggests that function objects and lambda functions are > the only type which can be passed to your library's functionality and > you enforce this view by your examples. I'll try to do that. > >> >> > >> > >> >> >> >> 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++. > > I call that a function template. Which is a family of functions. > My definition for 'function' is not the > > same as yours. I know you feel differently but please realize that the > term 'function', to mean any and every type of callable in C++, is not a > > universally agreed on terminology. I would bet that for the vast > majority of C++ programmers a function is: > > ReturnType FunctionName(ZeroOrMoreFunctionParameters); Yes, which can happen at class scope or namespace scope, and it can also be templated.

5 7

Re: [boost] 2 regression test failing at under 1.60 (John Maddock)
by Steven Kelso 09 Mar '16

09 Mar '16

On Tue, Mar 8, 2016 at 3:42 AM, <boost-request(a)lists.boost.org> wrote: > Date: Mon, 7 Mar 2016 19:21:26 +0000 > From: John Maddock <jz.maddock(a)googlemail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] 2 regression test failing at under 1.60 > Message-ID: <56DDD4B6.6030603(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > On 07/03/2016 17:04, Steven Kelso wrote: > > I've just started trying to install version 1.60 of boost using the gcc > > 5.3.0 compiler. With a vanilla download and no chnages it all seems to > > compile correctly, but I have a problem with 2 library regressions tests > > not terminating. They have both run for over 18 hours before I had to > kill > > them. I was using the options and configuration "out of the box" so > > optimization was -O3. > > I'm unable to reproduce on Ubuntu x64, all the Math lib tests pass fine > for me with gcc-5.3.0 in both C++03 and C++11 modes. > > So you'll need to debug and supply a patch if you're able, > > Thanks, John. > I'm trying to find out what exactly is causing the issue here. Would it be possible for you to show me the 'gcc -###' output so that I can compare to my version of gcc. Since the failure occurs only with optimization turned on i'm now leaning towards a compiler issue since I compiled gcc from source for this test. I'm hoping it's something obvious when I look closer. So far this has failed on a RHEL6.5 system running a locally compiler gcc 5.3.0 as well as a RHEL 7.2 based system compiled with the same gcc 5.3.0. Many thanks for your help, S

1 0

Re: [boost] [C++-sig] Trouble building boost with Visual Studio 2010
by Stefan Seefeld 09 Mar '16

09 Mar '16

Hi David, On 09.03.2016 05:04, David Aldrich wrote: > > Hi > > > > I am trying to build Boost 1.60 with Visual Studio 2010 Professional > on Windows 10. > > > > I use the command: > > > > b2 toolset=msvc-10.0 --with-python link=shared > > > > and get the following error: > > > > python34.lib(python34.dll) : fatal error LNK1112: module machine type > 'x64' conflicts with target machine type 'X86' > Just a quick guess: is it possible that your "libpython34.dll" file is a 64-bit binary, when the command really requires it to be a 32-bit binary ? > > > I guess this means I have a conflict of 32-bit and 64-bit libraries. > I want to target 32-bit (X86). > > > > Do I need to install a 32-bit version of Python? I wonder if that can > co-exist with the current version of Python? > I'm unfortunately unable to answer your question, as the question seems more about the build system than Boost.Python itself. Therefore I'm including the Boost mailing list in my reply, hoping that some Boost.Build expert may be able to help. Regards, Stefan > > > Best regards > > > > David > > > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig(a)python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig -- ...ich hab' noch einen Koffer in Berlin...

1 0

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

09 Mar '16

> On Tuesday, March 8, 2016 11:39 PM, Gavin Lambert <gavinl(a)compacsort.com> wrote: > > On 9/03/2016 10:43, paul Fultz wrote: >>> I would hope to convince you that a good Overview of your library > should >>> come first and then all the Quick Start guides, tutorials, examples > etc. >>> would make much more sense once your end-user understands what your >>> library really does in terms of at least the main general > functionality. >> >> I usually start with the Quick Start guide with a library in order to get > an >> understanding of what components are in the library and what they can do, > then >> I start delving into the other components from there. Thats what I am > showing >> in the Quick Start guide. >> >> I guess people have different ways of learning a library. I wonder what is >> needed to be explained better in a initial overview of the library. > > I suspect part of the problem is that the Introduction appears under the > ToC at the top level instead of on its own page above the Quick Start. > Thus someone not scrolling down is likely to miss the Introduction and > > start with the Quick Start. > > Still, even the Introduction is a little light on the things an Overview > generally needs to cover: "why should I consider using this library and > what types of problems does it solve?" (Sometimes some of this is split > to a separate Motivation section.) Yea, I think adding Motivation section will be helpful. > > Quick Starts / Tutorials are more for answering "now that I've already > decided to (probably) use this library, how do I do XXX?" > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1

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

09 Mar '16

> On Tuesday, March 8, 2016 6:52 PM, Steven Watanabe <watanabesj(a)gmail.com> wrote: > > AMDG > > On 03/06/2016 09:39 PM, Paul Fultz II wrote: >> >> On Sunday, March 6, 2016 at 3:44:31 AM UTC-6, Vicente J. Botet Escriba >> wrote: >>> >>> Le 06/03/2016 06:16, paul Fultz a écrit : >>>> >>>>> On Saturday, March 5, 2016 10:50 PM, Steven Watanabe < >>> watan...(a)gmail.com <javascript:>> wrote: >>>>> >>>>> #ifndef BOOST_FIT_NO_EXPRESSION_SFINAE >>>>> #ifdef _MSC_VER >>>>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 1 >>>>> #else >>>>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 0 >>>>> #endif >>>>> #endif >>>> This is can be configurable, whereas Boost.Config it is not. >>> I'm not sure this is true. >>> >>> > http://www.boost.org/doc/libs/1_60_0/libs/config/doc/html/index.html#boost_… >> >> >> That doesn't seem easily configurable by the user. I think I would > prefer >> to make it configurable by the library and use Boost.Config for the default > >> value. >> > > Why does it need to be easily configurable? > No one is ever going to care about it except > when Boost.Config is wrong. Well, I guess its mainly only useful for development then. I like to use the "no expression sfinae" path on clang as I can get better diagnostics. It seems kind of complicated to change this with Boost.Config, so I would prefer to have it easily configurable, and then use Boost.Config for the default value.

1 0

[property_tree] Two pull requests removing rtti and exception dependencies
by Chris Glover 09 Mar '16

09 Mar '16

Hi, I have two pull requests against property tree that I haven't heard anything about.. The first replaces usage of typeid(Type).name() in exception messages with boost::typeindex::type_id<Type>().pretty_name(). The second uses macros from no_exception_support.hpp to replace try catch blocks. I was hoping these might get into 1.61 so I don't need to carry local changes for too long -- is there any chance of that? Links: https://github.com/boostorg/property_tree/pull/20 https://github.com/boostorg/property_tree/pull/21 Thanks, -- chris

1 0

[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

[coroutine] Broken on all compilers.
by Rene Rivera 08 Mar '16

08 Mar '16

Coroutine on master branch seems broken across all the master tested compilers in the same way. Would be nice if it gets fixed. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[release] Reminders..
by Rene Rivera 07 Mar '16

07 Mar '16

Boost was closed for "major changes" last Wednesday. Boost will be closed for all change this Wednesday (9th). If all goes well.. Boost will reopen for bug fixes only on the 17th. Please consult the calendar, and subscribe, to the calendar for such dates < http://www.boost.org/development/index.html>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 6

[BGL] Multiple Start Vertices in Dijkstra Shortest Path
by Matthias Fuchs 07 Mar '16

07 Mar '16

Hi folks, I am interested in adding support for multiple start vertices for the Dijkstra Shortest Path Algorithm. Having such functionality would improve both performance and clarity of code I wrote. In a prove of concept I implemented such functionality using iterators for dijkstra_shortest_paths_no_color_map. Is there interest for such a feature? Or would it be a waste of my time working on that? If there is interest what should be the preferred way? * Using iterators (first_start_vertex, last_start_vertex) * Using ranges What about unit tests? AFAICT there are only few tests, which do not seem to be run automatically. What about documentation? Thanks for reading, Matthias

1 0