November 2019 - Boost - lists.preview.boost.org

[release] 1.72.0 closed for Beta
by Michael Caisse 11 Nov '19

11 Nov '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_72_1.q…> Thanks, -- The Boost Release Team

4 4

[Boost][Proposal] library for enhanced switch syntax. Request for Comments
by рустам абдумаликов 11 Nov '19

11 Nov '19

Hi All, I wrote a library *eswitch* which provides enhanced functionality for* C++ switch*. Please take a look and leave your comments. *=====================* *Motivation:* *=====================* To overcome "*native switch*" limitations: - one parameter per "*native switch*" - the parameter restricted to only *integral *types( int, char, enum ... ). "*eswitch*" supports any number of parameters and almost without restriction on their *type*, as long as the *type *is comparable( i.e. has* operator==* ). *=====================Why it is important?=====================* Here is the most viewed questions on the *stackoverflow*: FEATURE VIEWS Multiple conditions in switch case <https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement> 850k Switch for string <https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-…> 693k Case match in range <https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu…> 133k Over a million views indicate how many people out there are disappointed with limited functionality of "*native switch*". Building parallels with such operators as "*if*"/"*while*"... it is expected by default that "*native switch*" should have the same possibilities: - be able to work with *non-integral* types as well - be able to compose complex conditions like we do in other operators " *if*"/"*while*"... Unfortunately it is not the case up till now. There was a proposal in 2013 *Relax switch statement <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html>*, and committee agreed about importance of this topic. There also was *StringSwitch <http://llvm.org/doxygen/classllvm_1_1StringSwitch.html>* implementation by *LLVM *and *Case ranges <https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html>* non-standard extension which is supported by *gcc*, *intel C/C++* and *clang*. Nevertheless, we still don't have common and universal solution. People want to overcome current "*native switch*" limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed *eswitch <https://github.com/rabdumalikov/eswitch_v4>* functionality part of the *Boost-Library *will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. *=====================repository:=====================* https://github.com/rabdumalikov/eswitch_v4 *=====================References:=====================/// "switch for non-integral" on stackoverflow* 1. https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-… 2. https://stackoverflow.com/questions/16388510/evaluate-a-string-with-a-switc… 3. https://stackoverflow.com/questions/5452188/switch-case-statement-in-c-with… 4. https://stackoverflow.com/questions/19273092/character-in-switch-statement-c 5. https://stackoverflow.com/questions/4165131/c-c-switch-for-non-integers 6. https://stackoverflow.com/questions/27536575/switch-case-on-char */// "Multiple conditions" on stackoverflow* 7. https://stackoverflow.com/questions/8644096/multiple-conditions-in-switch-c… 8. https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement */// "Ranges in case" on stackoverflow* 9. https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu… */// "Case ranges" - non-standard extension* 10. https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html */// LLVM "StringSwitch"* 11. http://llvm.org/doxygen/classllvm_1_1StringSwitch.html */// "Relax switch statement" proposal* 12. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html */// "N3627 Relaxed switch statement" c++ committee status* 13. https://cplusplus.github.io/EWG/ewg-active.html *Best Regards.*

7 7

[Boost][Proposal] library for enhanced switch syntax. Request for Comments #2
by рустам абдумаликов 09 Nov '19

09 Nov '19

Hi All, First attempt kind of failed due to alignment:( So this is another one) So I wrote a library eswitch which provides enhanced functionality for C++ switch. Please take a look and leave your comments. Motivation: To overcome native switch limitations: 1) one parameter per switch 2) the parameter restricted to only integral types( int, char, enum ... ) Whereas "eswitch" supports any number of parameters and almost without restriction on their type, as long as the type is comparable( i.e. has operator== ). Why it is important? Because people want to overcome current switch limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed eswitch functionality part of the Boost-Library will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. Full proposal here: https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… Repository: https://github.com/rabdumalikov/eswitch_v4 Best Regards Rustam Abdumalikov

2 1

Re: [boost] fixed_string: Request for review
by Ggh 09 Nov '19

09 Nov '19

First: 1)wonderful documentation! 2) A few ideas => 2.1)find_count_of =>find number of occurences of 'argument' 2.2)get_sequence_of =>return sequence of 'begin'=>'end' 2.3)set_sequence_of => set sequence of 'begin'=>'end' with 'arg' 2.4)set_slice_of => ~= 2.3) 2.5)get_slice_of => ~= 2.2) 6)char_traits<T> here but =>> also for any type/class? Quoting Krystian Stasiowski via Boost <boost(a)lists.boost.org>: Good work! Please regard this as constructive critism, Ty G > Hi a > ,y > My name Is Krystian Stasiowski. I'm currently attending college as a > Computer Science major, am active on the C++ Language Slack, and starting > to contribute to ISO C++. Vinnie offered for me to take the lead on > submitting Boost.FixedString for a formal review, so here I am! > > Applicable links: > Github: https://github.com/18 > Repo: https://github.com/18/fixed_string > Docs: https://18.github.io/doc/fixed_string > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Tell me, and I forget. Ask me, and I discover...

1 0

[container] static_string ?
by Vinnie Falco 09 Nov '19

09 Nov '19

Beast has static_string which someone has asked to be move, is there any interest in moving this to Boost.Container? See: <https://github.com/boostorg/beast/issues/1691> <https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552…> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

19 50

[Metrics] - library idea reviews
by cpijcke.wall＠laposte.net 08 Nov '19

08 Nov '19

Hi, Two years ago, I have created a library who handle metrics type (distance, speed, flow rate, ...). I have simply applied the principle of chrono library (std:: one from clang in my case) and have applied it to other types. I have decided some weeks ago to make it public on github. This project also manage inter-type conversion(speed to distance, or volume to flow rate for example). Before going much further in this project, I would like to get your though about it. Maybe some of you already have had a similar idea, maybe even in a more advanced state, or with another principle of conversion between types? Here is the project link: https://github.com/xtofpic/metrics if you are interested. In this case, don't blame me for the state of the code actually, I know it still need a huge works to do on testing and code reducing by better c++ templates. But if you can just let me know what you think of the idea? And if there is an opportunity to eventually integrate this project into boost afterwards? Best regards, Christophe Pijcke.

2 2

How to make boost write_xml not escape angle brackets?
by Ananya Maiti 07 Nov '19

07 Nov '19

Hi all, I am trying to write some data in a xml file using boost write_xml() function. My data has some angle brackets in it e.g. <![CDATA[name]]> . But when I use boost::property_tree::write_xml() to write the data node to xml file it escapes the angle brackets to < and > tags. I even tried using unicode \x3C , \x3E but still it escapes them. Is there any way to tell boost to not escape the characters in a non html safe way ? Regards, Ananyo Maiti

1 0

[1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests
by John Maddock 07 Nov '19

07 Nov '19

This change: https://github.com/boostorg/test/commit/1c4533f7654d4c049cc6a34a43a5c10cde5… To Boost test (which I'm sure has been long signaled, I just wasn't aware of it), breaks one Math lib test (develop and master), and quite a number of Fibre tests (also develop and master), the Math failure should be fixed in develop (https://github.com/boostorg/math/commit/1d04bf714e809d386088ce135e3f9ea04ca…) and will get merged to master once CI is green. Not sure if anything is in the works for Fiber. Just a wee heads-up. Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 8

Best Boost to use for boost::python with Python 3.7/3.8?
by Kacvinsky, Tom 06 Nov '19

06 Nov '19

Subject is the question. Any recommendations? Looking at the boost documentation for boost::python, it doesn't look like the copyright has changed since 2015, but compiling boost 1.6.9.0, for instance, points out there have been code changes.

1 0

[Test] log_level (was RE: [1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests)
by Peter Bartlett 05 Nov '19

05 Nov '19

>I think it is very counter-intuitive that messages only emerge to the normal output if there is an error or --log_level="message" > >And that > > #define BOOST_TEST_LOG_LEVEL "message" > >does not appear to have the same effect as --log_level="message" > >which is also surprising, and in my book a buglet? > >I suggest that this behaviour should be changed so that BOOST_TEST_MESSAGE >*always* produces output. > >BOOST_AUTO_TEST_CASE(test_message) >{ > BOOST_TEST_MESSAGE("\nTest BOOST_TEST_MESSAGE.\n"); } // BOOST_AUTO_TEST_CASE(test_message) > >Otherwise I am sure I will not be the only person confused. > >At the very least the documentation should highlight that ones expectation may not match what actually happens. Hi, I think it would be a bad idea to change the default value of --log_level (in your suggestion, from "error" to "message"). The default has been "error" for a long time (I don't like to count how long, because it makes me feel old!). And I'm sure that a lot of parsing tools have been built around the world assuming Boost.Test output is of a certain form. I know I've had to 'teach' various CI systems Boost.Test-speak over the years. > #define BOOST_TEST_LOG_LEVEL "message" BOOST_TEST_LOG_LEVEL is supported as an environment variable, not as a macro. Supporting it as a macro would be a bad idea for similar reasons as above - the layout and volume of the output should be for the *user* to control not the author of the tests, or otherwise the user can't rely on what the test output is going to look like from one library to the next. If you, personally, always want the log_level to be 'message', then you should set the environment variable BOOST_TEST_LOG_LEVEL permanently on your system. Hope that helps, Pete

1 0