- Boost - lists.boost.org

Fwd: Markdown to Quickbook
by Mateusz Loskot 15 Nov '19

15 Nov '19

As boost-docs may not be as popular among subscribers as the development list, I'm bumping my chances for solution... ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 11 Nov 2019 at 21:25 Subject: Markdown to Quickbook To: <boost-docs(a)lists.boost.org> Hi, Is there an established known method for converting a Markdown document to Quickbook dokument? Best regards, Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting) -- Mateusz Loskot, http://mateusz.loskot.net

3 3

Removing old branches
by Edward Diener 15 Nov '19

15 Nov '19

I received an issue about Boost PP having lots of old branches which the issuer would like removed. I notice most other Boost libraries also have lots of old branches. Is there any policy about removing these old branches from a Boost library repository ? Many of these old branches are svn-branches, but most of them do not have any value any more and, of course, do not affect the current 'develop' or 'master' branch.

5 7

[preprocessor] Testing C++ standard macro examples
by Edward Diener 14 Nov '19

14 Nov '19

I have added to the 'develop' branch of Boost PP an 'explicit' test with the alias of 'test_iso' in the 'test' subdirectory. This test, depending on the compiler toolset and C++ standard setting used, will test a compiler's ability to expand correctly the macros listed in a C++ standard document's "Macro Replacement" section for C++ standards 2003, 2001, 2014, 2017, and 2020 ( N4835 ). The test uses the __cplusplus setting and the Boost PP BOOST_PP_VARIADICS setting to determine which C++ standard's set of macros to test. This is because the __cplusplus setting alone is misleading for a number of compilers, most notably vc++ and compilers who mimic vc++, who do not set the correct __cplusplus setting for the C++ standard level being used. There are really only three sets of macros from the C++ standard documents which can potentially be tested, despite five different standards being considered. This is because the set of macros to be tested for C++11, C++14, and C++17 are exactly the same. Some compilers do allow C++20 support but do not implement the full __VA_OPT__ support yet, so these compilers will fail the C++20 macro tests with compiler errors. Among these are gcc and vc++, who both document that they do not yet support the stringizing operator with the __VA_OPT__ parameter. Clang also supports C++20 and will run the test and succeed in that mode. You can of course test any compiler at any C++ level and view the results. These tests, unlike Boost PP, do not have any workarounds for any compilers. So the tests form a really good basis for reporting macro expansion preprocessor bugs to various compiler implementations. In the 'test' subdirectory of Boost PP you should be able to run: b2 toolset=atoolset cxxstd=astandard( optional ) test_iso to get the results for any compiler. Any failed results will show the test output, where the original expression, the expanded expression, and for individual failed tests the expected expanded expression will be shown. The actual macros being used are in the appropriate C++ Standard documents or can be seen in the test program which is called cpp_standard.cpp in the same 'test' subdirectory. After the upcoming release I will push this to the 'master' branch. Please note that the test is an 'explicit' test so it is not normally run when you just run the tests for Boost PP.

1 0

fixed_string: Request for review
by Krystian Stasiowski 13 Nov '19

13 Nov '19

Hi all, 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

2 1

Late fix for Boost PP
by Edward Diener 12 Nov '19

12 Nov '19

I had added support in the Boost PP library in C20 mode ( __cplusplus > 201703L ) for the __VA_OPT__ construct and enhanced an internal function used fairly extensively in the library to use this functionality in c20 mode when __VA_OPT__ was supported. I had tested this against the compilers which I knew could operate in c20 mode, gcc and clang, and all was well. I just discovered that the vc++ compiler can also work in c20 mode in Boost PP as defined above if you pass the '/std:c++latest' and the '/Zc:__cplusplus' command line switches and that vc++, in its usual non-standard way, blows up badly when doing so using the preprocessor library because it can not handle the rather simple code that checks for __VA_OPT__ support in c20 mode. I have a simple fix for this which is to turn off the __VA_OPT__ support and __VA_OPT__ support checking in c20 mode specifically for vc++ and removes which I have pushed to 'develop'. Can I push this fix to the 'master' branch now ? The fix needs to get in the coming release or else vc++ programmers specifying both the '/std:c++latest' and the '/Zc:__cplusplus' command line switched will not be able to use Boost PP and the many libraries which use Boost PP in the upcoming release. I apologize for the seeming aggressiveness of this change, which incorporated the c20 __VA_OPT__ support internally in some much-used Boost PP functionality when c20 mode is being used, but I did not anticipate that it would blow up on me, although maybe I should have. I can also remove that internal dependency with a very simple one-line change. I realize that Boost PP stability has to be maintained, even in c20 mode for the few compilers which support that mode and apologize again that I have endangered it there.

1 1

Re: [boost] [Boost][Proposal] library for enhanced switch syntax.
by рустам абдумаликов 12 Nov '19

12 Nov '19

Phil Endecott wrote: > Specifically thinking about strings, there are numerous ways > that it could be done. Starting with > (1): the obvious sequence of if-else-if: > ... > (2): binary search using nested switches: > ... > (3) character-by-character comparison using nested switches: > ... > (4) converting to a 64-bit integer, for strings of up to 8 characters: > ... Firstly my implementation was never particularly about string in "switch" it is just one of the applications. Secondly, example 3-4 assume additional implementation( can take quite a time to do it right ), it isn't like you have it out of the box, this is exactly what my statement was about( example 1-2 don't count, they are non-scalable ). Lets rather consider something that is more complex: -- Example_1 "Parse file by extension": switch( hash_it( get_file_extention( file_name ) ) ) { case "cpp"HASH: case "cc"HASH: case "c++"HASH: case "cxx"HASH: case "C"HASH: { ... } break; case "hpp"HASH: case "hh"HASH: case "h++"HASH: case "hxx"HASH: case "H"HASH: { ... } break; } // OR // I think this way it is much readable eswitch( get_file_extention( file_name ) ) >> case_( any_from( "cpp", "cc", "c++", "cxx", "C" ) ) >> [&]{...} >> case_( any_from( "h", "hpp", "hh", "h++", "hxx", "H" ) ) >> [&]{...}; // OR // even this could be possible( but not yet implemented ) eswitch( get_file_extention( file_name ) ) >> case_( "cpp", "cc", "c++", "cxx", "C" ) >> [&]{...} >> case_( "h", "hpp", "hh", "h++", "hxx", "H" ) >> [&]{...}; -- Example_2 "Parse HTTP header with Regex": // O_o too much boilerplate if( std::regex_match( line, "^.+ 200 .+$"_r ) ){...} else if( std::regex_match( line, "^.+ 404 .+$"_r ) ){...} else if( std::regex_match( line, "^.+: .+$"_r ) ){...} else { terminate(); } // OR // I think this way your intention is clearer eswitch( line ) >> case_( "^.+ 200 .+$"_r ) >> []{...} // match for "HTTP/1.1 200 OK" case_( "^.+ 404 .+$"_r ) >> []{...} // match for "HTTP/1.1 404 Not Found" case_( "^.+: .+$"_r ) >> [&]{...} >> // match for "key: value" default_ >> []{ terminate(); }; -- Example_2 "match in range of values": // Error prone approach if( value >= 1 && value <= 10 ){ Print("Value in a range[1,10]"); } if( value >= 11 && value <= 20 ){ Print("Value in a range[11,20]"); } else { Print('?'); }; /// OR eswitch( value ) >> case_( _1.in( 1, 10 ) ) >> []{ Print("Value in a range[1,10]"); } >> case_( _1.in( 11, 20 ) ) >> []{ Print("Value in a range[11,20]"); } >> default_ >> []{ Print('?'); }; // _1 it is lazy index mapping for the params in eswitch I my opinion "eswitch" looks more readable, more intuitive, less error prone and furthermore it is extensible. P.S. Here https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… I had described why I think it is important( just in case you've missed it ).

3 4

[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