Page 2 of 2

boost::bind + boost::math::quantile

Posted: April 5th, 2015, 6:31 pm
by Cuchulainn
Small remark; auto tends to camouflage the structure of the problem. Which is not to everyone's liking for sure.Are you proposing autos 'everywhere' or will there be auto-free zones in your code?

boost::bind + boost::math::quantile

Posted: April 5th, 2015, 6:44 pm
by Polter
Taken a look at Josuttis, I see; in C++14, I'd use generalized return type deduction for his `returnLambda` example.As for the quantification -- this is a good question; call can be an order of magnitude slower than non-virtual function -- slowdown can be (significantly!) greater or lower depending on the compiler (worth reading all of the answers):http://stackoverflow.com/questions/1467 ... templateAs a rule of thumb, since both do type erasure, I'd consider `std::function`'s call overhead to be comparable to that of virtual functions.// E.g., take a look at the comments on the MSVC11's implementation here -- note the mention of vtable: VC11, std functional bind/function, big performance hit under x64However, `std::function` may be somewhat faster than virtual function, if implemented as in Boost.Function (see links below). Thus, if I _need_ run-time polymorphism , I'd actually prefer `std::function` to virtual functions & inheritance. This has in fact (arguably more important) "higher-level" / design / maintenance reasons: You can get pretty nice, modular & composable code this way; I recall we've talked about this.Overall, for me this is not a question about "V1 versus V2", but about the overall design -- I'd use run-time polymorphism under very specific circumstances / when actually needed (and not by default), otherwise it's a bit apples/oranges.See also: * std::function and Its Costs: http://www.drdobbs.com/cpp/efficient-us ... 059?pgno=2* Boost.Function docs:- 5. How much overhead does a call through boost::function incur?: http://www.boost.org/doc/libs/release/d ... /faq.html- Miscellaneous Notes - Performance: http://www.boost.org/doc/libs/release/d ... /misc.html

boost::bind + boost::math::quantile

Posted: April 5th, 2015, 7:10 pm
by Cuchulainn
QuoteHowever, `std::function` may be somewhat faster than virtual function, if implemented as in Boost.Function (see links below). Thus, if I _need_ run-time polymorphism , I'd actually prefer `std::function` to virtual functions & inheritance. This has in fact (arguably more important) "higher-level" / design / maintenance reasons: You can get pretty nice, modular & composable code this way; I recall we've talked about this.That's putting it mildly. C# has delegates which is the same idea.To give an idea, I used boost::function to model the PDE for the recent Anchoring article using ADE with Alan and Paul. So, I had 7 functions for that 2-factor convection-diffusion-reaction PDE with mixed derivatives. It was super-fast.I did a test while back; if C function take 1 unit, then boost::function is 1.3, virtual is 4 (!AFAIR)And std::function ==> no class hierarchies are needed !!! OO developers use delegates idea??This is the way I did PDE (it reminds me of the good ole' COM days). I can't see much badness here; 7 objects in memory und??

boost::bind + boost::math::quantile

Posted: April 6th, 2015, 4:56 am
by Cuchulainn
Question: if we were to design an experiment to 'put numbers on item #5' how would I go about it? It seems that this has not been published? Maybe in the style of this useful benchmark edit: Item #6 brings 'auto' back down to earth. It can misbehave. And that's one reason I replaced it with the specific type. In general, the compiler errors (all 65 of them) are unreadable.

boost::bind + boost::math::quantile

Posted: April 6th, 2015, 6:32 pm
by Polter
Yeah, Boost.Accumulators offers The Statistical Accumulators Library.Haven't used it for quantiles (although it appears several algorithms for these are present), but it was very handy for several statistical benchmarks (where the on-line aspect simplified tracking considerably).http://theboostcpplibraries.com/boost.a ... ators.html

boost::bind + boost::math::quantile

Posted: April 6th, 2015, 6:59 pm
by Cuchulainn
We're finished the discussion about auto???

boost::bind + boost::math::quantile

Posted: April 7th, 2015, 4:42 pm
by Cuchulainn
QuoteOriginally posted by: outrunauto helps prevent implicit type conversion.regarding auto and the overhead of std::function, virtual functions etc., the most interesting remark is: "I'd use run-time polymorphism under very specific circumstances / when actually needed (and not by default)"That remark is only one side of the coin. The real open question for me is auto vs std::function + how much faster is it. Dynamic polymorphism is probably like whipping a dead horse at this stage. But many production systems use it ('inheritance from the 1990s'). I'll ask the games developers next Thursday in Amsterdam for views.http://www.meetup.com/the-dutch-cpp-group/

boost::bind + boost::math::quantile

Posted: April 7th, 2015, 5:03 pm
by Cuchulainn
Quoteauto helps prevent implicit type conversion.Is it possible to give an example? Normally, you get a compiler error.

boost::bind + boost::math::quantile

Posted: April 7th, 2015, 6:35 pm
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteauto helps prevent implicit type conversion.Is it possible to give an example? Normally, you get a compiler error.Egint i = std::pow(2.3, 2);instead ofauto d = std::pow(2.3, 2);orauto i = static_cast<int>( std::pow(2.3, 2) );auto forces you to make that conversions explicit.LHS and RHS have different types. Code inspection.Won't you get a warning in these cases? ====edit: in VS property setting, a) level 4 warning b) and treat warning as errors. Then these implicits won't get through.

boost::bind + boost::math::quantile

Posted: April 8th, 2015, 5:49 am
by Cuchulainn
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteauto helps prevent implicit type conversion.Is it possible to give an example? Normally, you get a compiler error.Egint i = std::pow(2.3, 2);instead ofauto d = std::pow(2.3, 2);orauto i = static_cast<int>( std::pow(2.3, 2) );auto forces you to make that conversions explicit.LHS and RHS have different types. Code inspection.Won't you get a warning in these cases? ====edit: in VS property setting, a) level 4 warning b) and treat warning as errors. Then these implicits won't get through.Configuring tools to help detect bugs is not as good as adopting coding conventions that prevent these types of potential errors, no?Using both is better ("braces and belt"). What happens if the developer forgets to use 'auto'?The acceptance and testing team would check this.