- Boost - lists.boost.org

[test][pull#151] Fix warning: BOOST_CLANG is not defined, evaluates to 0
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, I've submitted a tiny fix for this annoyance: https://github.com/boostorg/test/pull/151 May I ask the library maintainers to merge it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

GNOME outreachy
by Pranam Lashkari 26 Aug '18

26 Aug '18

GSoC just finished and it helped grow the community by adding few new students and maybe mentors to our Boost community. I was hoping why don't we also apply for GNOME outreachy also it is also similar to GSoC and can also help our community to grow. and by appearing in end of year internship in GNOME outreachy we can keep a flow of new contributors and motivate people to contribute to opensource throughout the year. Thank you, Pranam Lashkari

14 26

[regex] Drawing attention to link issue
by Antony Polukhin 24 Aug '18

24 Aug '18

Hello, The build flags for shared libraries are changing right now in b2. See https://github.com/boostorg/boost/pull/190 for more info. The thing is that Boost.Regex fails to link with those new flags, probably because of the https://github.com/boostorg/regex/issues/49 issue. If there's no simple solution for the above case, then please merge the https://github.com/boostorg/regex/pull/66/ . It should help. Thanks in advance!

2 2

[MSM] Still maintained?
by Christophe Henry 24 Aug '18

24 Aug '18

>Hi Boost-list, > >because I realized that my simple PR for Boost.MSM [1] (which makes it >compilable with C++17) and an even older one did not receive any >attention, I wonder if Boost.MSM is still actively maintained. > >The latest changes seem to be from around December 2017. > >Does anyone know, if Christophe is still active? > > >Best regards, >Deniz Hi Deniz, Sorry, I didn't have time to do it before vacations, I only merged your change to develop now. Thanks, Christophe

2 1

[type_traits][core] modularisation and moving stuff about (again)
by John Maddock 23 Aug '18

23 Aug '18

So... I have a couple of PR's to move some of type_traits into config so it can be used by core. It's a modest proposal so I can go with that I guess... but this moving stuff about all over the place just to satisfy dependencies does wind me up a bit - I know that I sometime struggle to figure out where stuff is on Github - half of Integer is in Config for example. How on earth would an end user figure that out in order to file a PR or a bug report? I know... "calm down dear" and all that ;) So radical suggestion - does type_traits just belong in core and lets be done with it? What would happen to the file history if we moved it (can I still "git blame")? DARFC, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 16

Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
by Glen Fernandes 23 Aug '18

23 Aug '18

Andrey Semashev wrote: > I would rather encourage people use type traits, the official > interface. Boost.Config or Boost.TypeTraits could provide macros that > allow users to detect whether is_final is emulated or is the real > deal. One thing about this suggestion: If Boost.Config was to provide macros that tell users whether Boost.TypeTraits' boost::is_final<T>::value is emulated or the real deal, then the compiler detection logic currently in Boost.TypeTraits for detecting __is_final would already have to be duplicated in Boost.Config. That does not sound like a great idea. Right now TypeTraits provides both, which is better. i.e. It provides boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the latter if it is defined, or is always false if not defined. If BOOST_IS_FINAL(T) and all its compiler detection logic lives in TypeTraits, then that all that compiler detection logic should not be duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or similar feature detection macro. Glen

5 13

[test] I want my core dumped
by Alain Miniussi 22 Aug '18

22 Aug '18

Hi, I have assert in my library code, but when the assert fire in a test, the main function in minimal.hpp intercept the signal and explains that, yes, you asked for an abort, but no: [...] ../../../boost/test/minimal.hpp(136): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char **)' Is there a way to avoid that behavior ? I need that core file. Thanks Alain

3 2

[multiprecision] Design question on variable precision types.
by John Maddock 22 Aug '18

22 Aug '18

Folks, I have a tricky design question that Boost.Multiprecision has been dodging relating to variable precision types - these have just expanded somewhat now that we support complex numbers via mpc as well as mpfr's reals etc. The basic use case is this: We have a set of numbers at very high precision, some calculations are performed on those directly, others we want to temporarily drop precision, get an approximate answer and perhaps later refine it. Generally speaking, performance trumps everything, on a really long running calculation 10-20% speedup can actually make a big difference (in $$'s in some cases if the CPU time is from the cloud). Up till now Boost.Multiprecision has been dodging this issue - it's actually pretty hard to program in a sane and consistent way, so the message has been "don't mix precisions" when using a type like boost::multiprecision::mpfr_float - just set what default you want and get on with it. But we really should do better than that. So... with the help of Danielle Brake I've been trying to nail this down in develop, what we have at present is: * Copy construction or move assignment copies the precision of the source. * Regular assignment retains the precision of the target variable. This is efficient in that assignment doesn't reallocate to a new precision, and provides an easy way to up/down sample precision when required. But it breaks equality after assignment. It does match what MPC/MPFR do in mpfr_set etc though. The fact that move assignment behaves differently from regular assignment bother me too - it's too easy to write code that triggers move semantics without noticing. The trouble is, being able to assign while retaining precision of source is sometimes useful too, so having move-assign behave differently provides a useful back door, but maybe one that's just too cute for it's own good? And then.... we get on to arithmetic. * Currently temporaries are created at current default precision. So it's easy to shoot yourself in the foot by not noticing that temporaries are being created in an expression and not having the default precision set correctly. I actually think this one might be solvable, but it's a huge job involving banning default constructors in all the backends to our number types, and then catching all the cases where they might have been used. * What should happen in "a = expression", where the variable used in "expression" are at different precision to a? The uncontroversial answer might be to adjust the result to the precision of a. But hold on... we have expression templates, and these can use variable a as working space while evaluating the expression... so the change in precision might occur *during* the computation and not after it. * Should we try to ban mixed precision arithmetic altogether? It's a tempting idea, but I can't see how to enforce it in code without also banning mixed precision assignment. Thanks for your consideration, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[MSM] Still maintained?
by Deniz Bahadir 22 Aug '18

22 Aug '18

Hi Boost-list, because I realized that my simple PR for Boost.MSM [1] (which makes it compilable with C++17) and an even older one did not receive any attention, I wonder if Boost.MSM is still actively maintained. The latest changes seem to be from around December 2017. Does anyone know, if Christophe is still active? Best regards, Deniz [1] https://github.com/boostorg/msm/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Oliver Fietz Board of Management: Stephan Schröder, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

1 0

Increasing BOOST_PP_VARIADICS_SIZE
by Damien Buhl 20 Aug '18

20 Aug '18

Dear Edward, In comparison to BOOST_PP_SEQ, BOOST_PP_VARIADICS is limited to 64 elements while BOOST_PP_SEQ is limited 255. Is there a reason for the choice of 64 or could I patch BOOST_PP_VARIADICS to go as BOOST_PP_SEQ to a limit of 255 ? Or asked differently do you think there are in newer compilers/standards a way to have an unbounded BOOST_PP_VARIADICS implementation nowadays ? Warm Regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 2