- Boost - lists.preview.boost.org

Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
by John McFarlane 19 Oct '16

19 Oct '16

> > Date: Thu, 13 Oct 2016 20:41:27 +0000 (UTC) > From: Christopher Kormanyos <e_float(a)yahoo.com> > > > I discuss P0106R0 (a revision to N3352) in my paper, the latest draft of > > which is always available here: https://github.com/ > > johnmcfarlane/fixed_point/blob/master/doc/p0037.md#p0106 > > I'm honestly not sure which approach is preferable overall. The set of > > features and qualities requested during SG14 and SG6 meetings is large > and > > conflicting. It includes minimal build times, minimal run-time overhead, > > every rounding and overflow strategy listed in P0105, decimal radix and > > support for specialized fixed-point instructions on embedded > architectures. > Hi John. Thanks for visiting this thread. > > My recommendation would be to limit the scope of the proposal > to a realistic level in the SGs so that we can end up with anything > at all within a reasonable time scale. We could consider back porting > some (but probably not all) of SG14's specified interface to Boost > if that helps move anything along. > A second pair of implementor eyes would be a huge help. I should point out that although it hasn't seen much attention lately, P0106 may still be active. (Frankly, the evolution of my design has been largely a process of slowly copying or facilitating all the most popular from Lawrence's proposal!) One problem P0037 faces - even if it were to be standardized - would be that alone, it only provides fixed-point arithmetic. It's designed to work with types that also solve arbitrary width, rounding and overflow but those types are not part of any proposal. In particular, without an arbitrary-width integer type, it's very difficult to use fixed_point<> safely. > > I was also wondering about decimal radix, but I don't know if it > might simply be better to identify those 80% of the most popular use cases and simply specify these. At least it would get the library > moving forward and people could use fixed-point in C++. This is basically what we tried to do with the GSoC project. > That makes sense. I at least want to have a solution which doesn't close the door on decimal in future additions. Here's my current plan: https://github.com/johnmcfarlane/fixed_point/blob/master/doc/p0037.md#non-b… > > >> In your work I've been experiencing some trouble with>> the division > routine. > > Can you elaborate? Was this recently? I've been trying out numerous > > strategies for arithmetic operators. My current preferred approach is to > > pad the left-hand operand before performing the division but that's only > > been checked in for a few months. > > I'm not sure about the design, and error on my side is a likely possibility. But division operator in the master branch seems like it does not pad before divide. This might give the wrong result. > I hope that's not the case but it's a tough operator to get right - especially with 32-bit operands. If you ever find a good example of this happening I'd be very interested in it. At least when using the elastic alias, precision loss should be avoidable (beyond inevitable approximation of rational numbers and x/0). tl;dr: The details of padding in the division operator follow... The padding is done on this line: https://github.com/johnmcfarlane/fixed_point/blob/91c3f2e272f9fd5e33ffb4dc2… It's on display in this test: https://github.com/johnmcfarlane/fixed_point/blob/1cc7ceaaff5422667ae962995… In the above test, the two operands have a single fractional digits. If operator/ did not pad the LHS, then the integer operation would be 126/8 which would lose precision. Instead, the LHS is promoted and shifted left by 8 bits. Then, integer division occurs and the value is stored with (hopefully!) no further shifts. > For division, I have used the following approach. * handle sign * extend n bits to 2n bits > * shift left by radix split plus one round bit * divide 2n / n -> n bits > * handle round and sign > So you're right this requires 64-bit extension for a 32-bit fixed-point unless you tackle the problem of two-component division, which I have done using a simplified version of Knuth long division. At the moment, this is only in develop branch. The compiler switch is BOOST_FIXED_POINT_DISABLE_WIDE_INTEGER_MATH. > This is core to the difference in approach between P0037 and P0106. I guarantee to use built-in integer math for any type specialized on built-in integers. I believe that types with arbitrary width can then be built upon this foundation using novel integer types. Here is an example using Boost.Multiprecision to express a Googol: http://johnmcfarlane.github.io/fixed_point/#boost fixed_point<> uses the same algorithm regardless of whether the `Rep` integer is an uint8_t or a 400-bit custom type. > > >> I also had some problems compiling on VC12 (but you don't target that > >> compiler anyway). So that's no big deal. > > > You will need a C++11-compliant compiler as sg14::fixed_point<> creates > > literal types. Lack of support for features like constexpr constructors > is > > the main obstacle to compiling under VC++ 2013 and earlier. > I actually agree with that approach. Either it uses C++11 or it does not. I don't see the need to cater to a specific older compiler for new library work. > It's a pragmatic choice. Three reasons are: * C++11 has everything I need to implement (with difficulty) a literal type. In particular, I can write most of my unit tests using `static_assert` which is the best thing ever! * Once you start returning novel specializations from your arithmetic operators, `auto` type deduction is essential to usability. * Many of my target users in SG14 are stuck with compilers which are behind the curve. > >> In your work you are using wrapped versions of elementary transcendental > >> functions designed for built-in float. You might appreciate our > hand-crafted > >> functions designed to be highly efficient in several digit ranges. > > > Yes! I would be very interested in seeing if I could adapt those > function. > We worked hard on these. And there are many good algorithms available in boost/fixed_point/fixed_point_negatable_cmath.hpp > > Having spent a non-trivial amount of time writing the simplest sqrt I could find, I appreciate the effort this must have involved. > Mine are placeholders and I've deliberately postponed the non-trivial task > > of adding cmath equivalents. It's come up - maybe a couple of times - > > whether these functions are desired and the response has been to just > keep > > the proposal narrow so they are not included. > > > There are interesting questions regarding how to implement some > functions. > > For example, you surely don't always want the same inputs and outputs > from > > functions involving angles. And hopefully these functions can be > constexpr > > - unlike existing functions. > I agree. > > Also, how have you approached the trade-off between speed and accuracy? I > > went for a very simple sqrt function which is adequate if the value is > > calculated at compile time but is likely not desirable at run-time. This > > isn't a problem that floating-point variants face. > > The elementary transcendental functions use many techniques including polynomial approximation, Pade approximation, Taylor series, > Newton iteration. For low digit counts, mostly polynomial approximation. We > express the coefficients directly as integral values of the fixed_point > representation and avoid as much as possible full division and multiply, > favoring integer div and mul. These functions are quite efficient. We have > not constexpr-ed them. But it looks like there is potential for that. > Writing constexpr functions in C++11 can be a big challenge. > > >> I have also benched our fixed_point on bare-metal embedded systems both > >> 8-bit and 32-bit with very satisfying efficiency results. This is a key > >> feature for our embedded users that might also be interesting for SG14. > > > My current aim is to match integer performance for common arithmetic > > operations when using built-ins. This leads to some situations where > > overflow is a big problem - but no worse than dealing with raw integers. > > I'm curious how you deal with multiplying two int-sized values together > > without resorting to wider, slower types.I was under the impression that > > P0106 types always widen to fit their values. > We have resorted to wider integer for internal mul and div or used higher > level algorithms when the compiler switch BOOST_FIXED_POINT_DISABLE_WIDE_INTEGER_MATH > is activated as mentioned above (develop branch only). > In our approach, full multiplication requires: * sign conversion > * left shift for round bit > * multiply n*n --> 2n bits * right shift and round * sign conversion > On a 32-bit system, a full 32*32 -> 64 mul is required. > This full multiplication approach can not achieve your desired efficiency > goal on 8-bit and 32-bitCPUs. Division uses similar approach. > > Multiplication and division with plain int or unsigned can achieve the > efficiency goal --- if it were not for handling rounding and overflow. > > In my current branch, I'm actually trying to get even closer to integer-level efficiency. No longer does 32-bit multiplication result in 64-bit results on systems with 32-bit integer. This means that overflow on 32-bit arithmetic operations is even more common. The solution is explicit casting to 64-bit or use of an integer type which auto-widens: http://johnmcfarlane.github.io/fixed_point/#elastic This is the toughest design issue I face - especially when combined with division. > > >> Thank you and best regards, Chris > > And thank you. Keep up the good work! > > John > Thanks again and best regards, Chris > > Cheers, John

4 7

[serialization]
by alainm 19 Oct '16

19 Oct '16

Hi, I have a few blocking compilation/link problems on the develop branch for which to fixes are pending (46 (3 lines) & 45(1 line)). 45 is a bug in the code I thin, 46 probably works just fine on most platform, but not on mine (recent Intel compiler on CentOS 6.5, which mean advanced features, but old headers). Boths are breaking are breaking some tests on Boost.MPI. Could someone have a look at it ? Regards Alain

1 0

[Serialization] check failed ???
by alainm 17 Oct '16

17 Oct '16

Hi, If I got on: https://github.com/boostorg/serialization/pull/46 I see a message "All checks have failed". If I follow the link "details" I see stuff regarding rake (?) and unfound "rakefiles", What is this all about ? Regards -- Alain Miniussi Pole Génie Logiciel Scientifique Observatoire de la Côte d'Azur Blv de l'Observatoire, Nice

1 0

Read only attributes in C++ (class proposal)
by Daniel Illescas Romero 17 Oct '16

17 Oct '16

Hello, I wanted to make some read only attributes on C++ so I made a class, named ReadOnly. This class will contain an internal private value, only “friend” classes could change this internally. Description: · A read only object will contains an internal value that can’t be changed outside the class. For example: ReadOnly<string> name = “Daniel”; To access its value: object.name, if you try: object.name = “other”, it won’t change it’s value because it’s a read only variable; you can change it’s value only inside the class the object is declared, you could change it like: name.value = “whatever”; · To set a value (outside the class) to a read only attribute you MUST specify a setter function (which can be static and contained inside the class), like: ReadOnly<int> age {ReadOnly::setAge, 1}; (optionally you can also set a default value to the attribute). Example of setter function: static bool setAge(const int& value) { return (value > 0 && value <= 150); } So if you you have an object and you want to change its value like this: object.age = 100; it will change its internal value only if the setter function (which is called internally) returns true. · The idea of doing all of this instead private variables and getters & setters is because this approach is closer to OOP than what is normally used; I mean if you have an object and you want to get an attribute value, what you need to do in most cases is something like: object.getAttribute(), you are calling a function to just take a look at an attribute, that shouldn’t make sense in OOP, that’s why I made all of this. It’s also similar to how you manage getters and setters in Swift, because they are embedded in the attribute and you don’t need to make other functions. :) I uploaded the project to github so everyone can take a look: https://github.com/illescasDaniel/ReadOnly <https://github.com/illescasDaniel/ReadOnly> — I wanted to know your opinion about the idea of the class and also about the implementation, I’d love to upload it to boost libraries but I want to know people opinion and make the class better. Thank you!

2 1

How can I detect if a template static member function exists?
by Vinnie Falco 16 Oct '16

16 Oct '16

I'd like to write a trait: template<class T> struct has_content_length : std::integral_constant<bool, ...>{}; which detects whether or not a template static member function is present in T. Here's a typical T: struct X { template<bool isRequest, class Body, class Headers> static std::uint64_t content_length( message<isRequest, Body, Headers> const& m); }; How can I detect if X::content_length(m) is callable for any m of type message template?

2 1

Re: [boost] [config] Changes to reflect Visual C++ "15" preview 5
by Tom Kent 15 Oct '16

15 Oct '16

I've now added a runner to the test suite with msvc-15.0 (preview 5 installed), it should show up in a couple hours as "teeks99-09o-win2012R2-64on64" (the far right column). The run only took a few minutes instead of an hour or two, so I'm expecting it to look pretty broken. Just glancing at the logs it looks like the compiler isn't even being found. Does this require b2 updates? Tom

2 1

[algorithm] New search algorithms
by Зайцев Александр 14 Oct '16

14 Oct '16

Hello. Now in Boost. Algorithm there are 3 algorithms for searching: Knuth-Morris-Prata, Boyer-Moore, Boyer-Moore-Horspool. They are good algorithms, but there are other efficient algorithms like Turbo-Boyer-Moore, Quick Search, etc. You can find some more here: http://www-igm.univ-mlv.fr/~lecroq/string/index.html Now i am working on new search algorithms for Boost.Algorithm. Maybe are there anybody,who familiar with string search algorithms? -- Best regards, Alexander Zaitsev

1 0

[program_options] -d directory is falling into positional input-files 1_62_0
by Roger Martin 14 Oct '16

14 Oct '16

Hi, Pulled this from a larger application to isolate to the problem: -d ./tmp or -d "./tmp" doesn't go to directory string but is with the positionals: #include <stdlib.h> #include <iostream> #include <exception> #include <string> #include <cstring> #include <memory> #include <fstream> #include "boost/program_options.hpp" int main(int argc, char** argv) { try { boost::program_options::positional_options_description p; p.add("input-file", -1); std::string directory = "./"; boost::program_options::options_description visible("Allowed options"); visible.add_options() ("input-file", boost::program_options::value<std::vector<std::string>>(), "input files can be *.xml, *.pdb, *.mol2, *.mtz, *.cif, *.csv, and *.sdf. Csv and sdf formats are for NMR calculations. csv lists the atoms for which the shifts will be computed. 1st line containts the Header: \"Chain\",\"Residue ID\",\"Sequence\",\"Atom Name\",\"Unbound ppm\",\"Bound ppm\". Then atoms may be listed i.e \"A\",\"MET\",231,\"CE\",10.30,10.50. sdf file contains the ligands for a CSP calculation. ") ("directory,d", boost::program_options::value<std::string>(&directory)->implicit_value("./"), "Directory for publishing output.") ; boost::program_options::options_description all("Allowed options"); all.add(visible);//.add(hidden); boost::program_options::variables_map vm; boost::program_options::store(boost::program_options::command_line_parser(argc, argv).options(all).positional(p).run(), vm); boost::program_options::notify(vm); std::vector<std::string> fileList = vm["input-file"].as < std::vector < std::string >> (); for (unsigned int fileListIndex = 0; fileListIndex < fileList.size(); fileListIndex++) { std::cout<<" "<<fileList[fileListIndex]<<" "<<std::endl; } } catch (std::exception& e) { std::cout << e.what() << std::endl; } return 0; } Built with g++ 4.9.0 on Linux frodo.quantumbioinc.com 2.6.32-573.7.1.el6.centos.plus.x86_64 #1 SMP Wed Sep 23 03:02:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux g++ -fPIE -std=c++11 -I${BOOST_HOME}/include -Wl,--allow-multiple-definition -MT main.o -MMD -MP -O3 -c -o main.o main.cpp g++ -pie -Wl,--allow-multiple-definition -o main main.o -L${BOOST_HOME}/lib -lboost_program_options -lc -lm -lpthread -lz -lstdc++ -ldl -lrt And run as ./main 2-aminoethanol.pdb -d ./tmp which results in 2-aminoethanol.pdb ./tmp This code had been working with 1_57_0. Some change in the API I need to adjust for?

1 0

[algorithm] Longest palindromic substring in Boost.Algorithm
by Зайцев Александр 14 Oct '16

14 Oct '16

Hello I want to add to Boost.Algorithm algorithm for finding all palindromes in a sequence in O(N). https://en.wikipedia.org/wiki/Longest_palindromic_substring Is it useful algorithm for Boost? Have you any suggestions? -- Best regards, Alexander Zaitsev

3 2

Re: [boost] [fixed_point] First presentation from GSoC 2015 and more
by John McFarlane 13 Oct '16

13 Oct '16

Hi Christopher. I'm actually the main culprit behind P0037. :) Date: Wed, 12 Oct 2016 18:32:26 +0000 (UTC) > From: Christopher Kormanyos <e_float(a)yahoo.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 > and more > Message-ID: <1026507022.4306136.1476297146580(a)mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > > I'm a bit surprised I didn't see this work before. > > Are you aware that SG14, the gamedev, real-time simulations, embedded > > software and financing study group for the standard > > is working on fixed point real proposal too? > > Here is a version of the proposal:>http://johnmcfarlane > .github.io/fixed_point/papers/p0037r2.html and>http://johnmcfarlane.githu > b.io/fixed_point/papers/p0381r0.html > > I will notify SG14 in case they missed your work too. > Thanks for the information. > We became aware of your work unfortunately very late inthe project. Much > of our fixed_point work stems from myearly prototyping dating from 2011 - > 2013. > I see a lot of similarities in the two bodies of work.Maybe we could > identify the strengths of each work.I don't know if it makes sense to > combine them,but maybe share some concepts or interface ideaswould make > sense. > I discuss P0106R0 (a revision to N3352) in my paper, the latest draft of which is always available here: https://github.com/ johnmcfarlane/fixed_point/blob/master/doc/p0037.md#p0106 I'm honestly not sure which approach is preferable overall. The set of features and qualities requested during SG14 and SG6 meetings is large and conflicting. It includes minimal build times, minimal run-time overhead, every rounding and overflow strategy listed in P0105, decimal radix and support for specialized fixed-point instructions on embedded architectures. > > In your work I've been experiencing some trouble withthe division routine. Can you elaborate? Was this recently? I've been trying out numerous strategies for arithmetic operators. My current preferred approach is to pad the left-hand operand before performing the division but that's only been checked in for a few months. > I also had some problems compilingon VC12 (but you don't target that > compiler anyway).So that's no big deal. > You will need a C++11-compliant compiler as sg14::fixed_point<> creates literal types. Lack of support for features like constexpr constructors is the main obstacle to compiling under VC++ 2013 and earlier. > In your work you are using wrapped versions of elementarytranscendental > functions designed for built-in float.You might appreciate our hand-crafted > functionsdesigned to be highly efficient in several digit ranges. > Yes! I would be very interested in seeing if I could adapt those function. Mine are placeholders and I've deliberately postponed the non-trivial task of adding cmath equivalents. It's come up - maybe a couple of times - whether these functions are desired and the response has been to just keep the proposal narrow so they are not included. There are interesting questions regarding how to implement some functions. For example, you surely don't always want the same inputs and outputs from functions involving angles. And hopefully these functions can be constexpr - unlike existing functions. Also, how have you approached the trade-off between speed and accuracy? I went for a very simple sqrt function which is adequate if the value is calculated at compile time but is likely not desirable at run-time. This isn't a problem that floating-point variants face. > I have also benched our fixed_point on bare-metalembedded systems both > 8-bit and 32-bit with verysatisfying efficiency results. This is a key > featurefor our embedded users that might also be interestingfor SG14. > My current aim is to match integer performance for common arithmetic operations when using built-ins. This leads to some situations where overflow is a big problem - but no worse than dealing with raw integers. I'm curious how you deal with multiplying two int-sized values together without resorting to wider, slower types.I was under the impression that P0106 types always widen to fit their values. > > Thank you and best regards, Chris > > And thank you. Keep up the good work! John > > On Tuesday, October 11, 2016 11:37 PM, Klaim - Jo?l Lamotte < > mjklaim(a)gmail.com> wrote: > > > On 6 October 2016 at 12:07, Paul A. Bristow <pbristow(a)hetp.u-net.com> > wrote: > > > > -----Original Message----- > > > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of > > Christopher Kormanyos > > > Sent: 05 October 2016 23:07 > > > To: boost(a)lists.boost.org > > > Subject: Re: [boost] [fixed_point] First presentation from GSoC 2015 > and > > more > > > > > > >> A partial implementation of fixed-point in a Boost-like > > > >> style based on proposal N3352 is now available. > > > > > > > ... But your links don't work, > > > > Indeed :-( ( > > > > The correct link to the docs for some years used to be > > > > https://dl.dropboxusercontent.com/u/43940943/modular-boost/ > > libs/fixed_point/doc/html/index.html > > > > but sadly this no longer works for reasons that so far escape me (but I > > suspect some change at Dropbox?). > > > > Meanwhile here is a PDF version to whet your appetite until I get a html > > version publicly available. > > > > https://dl.dropboxusercontent.com/u/43940943/modular-boost/ > > libs/fixed_point/doc/fixed_point.pdf > > > > Boost.Fixed_point ? > > =============== > > > > A partial implementation of fixed-point in a Boost-like style based on > > proposal N3352 is now available. > > > > This work is the result of developments from 2013-2016, including efforts > > from GSoC 2015. > > > > The source code is available at: https://github.com/ > > BoostGSoC15/fixed_point > > > > (The master branch will be stable for a while but the develop branch may > > be updated in the light of your feedback). > > > > Preliminary docs are available at: > > > > https://dl.dropboxusercontent.com/u/43940943/modular-boost/ > > libs/fixed_point/index.html > > > > We are potentially interested in submitting this work for inclusion in > > Boost. > > > > We are now requesting comments and suggestions for improvements, > > corrections and any > > further test results if these become available. > > > > Some key library features include: > > > > * proper C++ header-only implementation > > * full numeric_limits and <cmath> functions > > * flexible template choice of split between resolution and range > > * automatic selection of underlying integral representation > > * portability and high efficiency for bare metal microcontrollers > > * interoperation with Boost.Math > > * seamless extension to high-precision using Boost.Multiprecision > > * extensive test suite > > > > Thank you for your consideration. > > Best regards, > > > > Christopher Kormanyos > > > > And apologies from Paul. > > > > > Hi, > > I'm a bit surprised I didn't see this work before. > Are you aware that SG14, the gamedev, real-time simulations, embedded > software and financing study group for the standard > is working on fixed point real proposal too? > Here is a version of the proposal: > http://johnmcfarlane.github.io/fixed_point/papers/p0037r2.html and > http://johnmcfarlane.github.io/fixed_point/papers/p0381r0.html > I will notify SG14 in case they missed your work too. > > Jo?l Lamotte > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman > /listinfo.cgi/boost > > > >

2 1

Re: [boost] : Curiousity question
by Brian Wood 13 Oct '16

13 Oct '16

Edward Diener writes: > I would like to ask a design question for any Boost developers or anyone > on this mailing list who might care to answer. > > You are designing or working on a library, perhaps for Boost, perhaps > for fun, and part of the design of the library has some public > functionality taking a shared pointer as input. You: > > 1) Use boost::shared_ptr > 2) Use std::shared_ptr > 3) Use both boost::shared_ptr and std::shared_ptr with the same > functionality > 4) Use neither, you roll your own shared pointer-like functionality > 5) You don't lke shared pointers and use raw pointers instead > > I really am curious about this. I haven't put any limitation on your > library or made any presumption on who your library is for, on purpose. > Thanks for anyone answering ! I avoid shared pointers. I'll use a unique_ptr if a raw pointer won't work. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

[qvm] Doesn qvm contain any sse/avx etc optimizations?
by Viktor Sehr 12 Oct '16

12 Oct '16

If not, is it planned for utilizing it? /Viktor

2 1

Boost library incubator URL address
by Edward Diener 12 Oct '16

12 Oct '16

Is the Boost Library Incubator web site down or removed ? I cannot get to it anymore via a URL. I have this URL, http://www.rrsd.com/software_development/blincubator/index.htm, but it just hangs on me.

2 1

Announcing version 3 of the cxx_dual library
by Edward Diener 11 Oct '16

11 Oct '16

I have created version 3 of the cxx_dual library. version 3 is a large rewrite of the documentation to simplify the use of the library, as well as a change in the directory structure so that the basic usage of the library is through a single header file and the use of a namespace alias, and not through the macro interface. As in: #include <boost/cxx_dual/regex.hpp> void SomeFunction() { cxxd_regex_ns::regex re("A regular expression etc."); bool result(cxxd_regex_ns::regex_match("Some string...",re)); // etc. } What ! No macros ! Actually a few macros still exist for testing which dual library has been chosen and overriding the dual library chosen, but the basic functionality means almost no macros in user code. The library is available at https://github.com/eldiener/cxx_dual.git. What is it ? The Cxx Dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while allowing the end-user to use the same code to program either choice. An implementation is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. An 'implementation' is called a 'mod' for short and each of the possible Boost or C++ standard implementations for that mod are called a 'dual library'. The Cxx Dual library does this by automatically choosing either the Boost library or the C++ standard library for a particular mod, including the correct header file(s) needed for the dual library chosen, and creating a namespace alias for the namespace of the dual library chosen. CXXD also provides a macro-based solution for distinguishing between the Boost version and the C++ standard version of a dual library so that specific code for a particular dual library choice may be written in those cases where the public interfaces diverge.

1 0

Announcing version 3 of the cxx_dual library
by Edward Diener 11 Oct '16

11 Oct '16

I have created version 3 of the cxx_dual library. version 3 is a large rewrite of the documentation to simplify the use of the library, as well as a change in the directory structure so that the basic usage of the library is through a single header file and the use of a namespace alias, and not through the macro interface. As in: #include <boost/cxx_dual/regex.hpp> void SomeFunction() { cxxd_regex_ns::regex re("A regular expression etc."); bool result(cxxd_regex_ns::regex_match("Some string...",re)); // etc. } What ! No macros ! Actually a few macros still exist for testing which dual library has been chosen and overriding the dual library chosen, but the basic functionality means almost no macros in user code. What is it ?

1 0

Re: [boost] [beast] Request for Discussion
by Vinnie Falco 10 Oct '16

10 Oct '16

There's some great programming and design discussion related to Beast and HTTP going on in the GitHub issues for the project. And there are some interface changes looming. Stakeholders and interested parties should consider participating in these discussions if they would like to influence the outcome: Some of the discussions: HTTP 1 versus 2 namespacing https://github.com/vinniefalco/Beast/issues/121 HTTP/2 design https://github.com/vinniefalco/Beast/issues/122 Expect: 100-continue https://github.com/vinniefalco/Beast/issues/123 `basic_headers` to make better use of allocators and string_ref https://github.com/vinniefalco/Beast/issues/124

1 0

[git] some fetch errors
by Raffi Enficiaud 09 Oct '16

09 Oct '16

Hi all, I see the following errors: """ Fetched in submodule path 'libs/python', but it did not contain 0ca7db361b8a70540c5683ae3ba2219c3352f721. Direct fetching of that commit failed. """ while my agents were checking out version aa407db3a22120496d6c49d2e3bc0b494b5ceb76 of the boost superproject. Does anyone know why am I seeing this? I cannot find rev 0ca7db361b8a70540c5683ae3ba2219c3352f721 in libs/python Thanks, Raffi

5 6

[python] Missing test file.
by Rene Rivera 09 Oct '16

09 Oct '16

FYI.. The testing CI sanity check is failing with this missing file error: error: Unable to find file or target named error: 'printer.py' error: referred to from project at error: '../libs/python/test' <https://travis-ci.org/boostorg/boost/jobs/166196326#L6960> Please fix ASAP. -- -- 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

Re: [boost] [beast] Request for Discussion
by Vinnie Falco 09 Oct '16

09 Oct '16

To get this topic hopping again, I'll share a bit of news. With help from Howard Hinnant I've opened an issue against the Networking TS to make sure that its algorithms do not place unnecessary requirements on user-defined types: http://cplusplus.github.io/LWG/lwg-active.html#2779 This will affect Beast's buffer sequence adapters (such as buffer_cat).

1 1

Boost.Python NumPy extension
by Stefan Seefeld 09 Oct '16

09 Oct '16

Hello, I'm happy to announce that I just merged the NumPy C++ wrappers from https://github.com/ndarray/Boost.NumPy into Boost.Python's development branch. (Online documentation for it can be browsed here: http://boostorg.github.io/python/develop/doc/html/numpy) I'd very much like to be able to merge this into the master branch for the next Boost release (version 1.63). At present I'm using SCons to build Boost.Python (stand-alone, against a separately installed Boost), which is also the infrastructure I use for CI testing (https://travis-ci.org/boostorg/python) I would like to ask for help with integrating the new NumPy extension into the Boost.Build-based build system, such that this will also be picked up by the regular Boost infrastructure. Please refer to https://github.com/boostorg/python/issues/89 if you'd like to help with this. Many thanks ! Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

Build: Trying to get Boost.Build to see my OpenSSL on Windows
by Vinnie Falco 07 Oct '16

07 Oct '16

I'm trying to build the Asio SSL examples but bjam can't find my OpenSSL installation on Windows (using Visual Studio 2015). Everything else builds. And I am having the dickens of a time finding any information on the web about mixing Windows, OpenSSL, and bjam. As a last resort I've thrown a hail mary to StackOverflow: http://stackoverflow.com/questions/39800333/how-do-i-get-bjam-to-set-includ… I'm not clear on what this line does on Windows using MSVC: lib ssl ; The line appears in Asio Jamfiles that use OpenSSL. Any help is appreciated, thank you.

7 38

[doc] Doc directory for a library
by Edward Diener 07 Oct '16

07 Oct '16

If a library does not have a 'doc' subdirectory, because the doc is not buildable but is rather hardcoded into an HTML file, what is the best way to satsify Boost and the boost_check_library regression test for that library ?

2 2

Upcoming changes to _MSC_VER
by Gabriel Dos Reis 07 Oct '16

07 Oct '16

Hi, This is a heads up. I spoke with Beman at CppCon about this: the upcoming release of Visual Studio (VS "15") has some changes to how _MSC_VER will be defined at every (future) update. These changes are already implemented in 'VS "15" Preview 5'. The full details are here https://blogs.msdn. microsoft.com/vcblog/2016/10/05/visual-c-compiler-version/ Internal testing showed that some components of Boost source code needed a few changes to use inequalities instead of equalities with _MSC_VER. Thanks, PS: The formal documentation of _MSVC_LANG is coming. -- Gaby

3 3

Review request: Beast
by Vinnie Falco 04 Oct '16

04 Oct '16

Can Beast please be added to the review queue? Michael Caisse has volunteered to act as the review manager. Beast provides C++11, header-only implementations of the HTTP and WebSocket protocols using Boost.Asio and presenting a consistent, modern synchronous and asynchronous interface style. Beast project repository https://github.com/vinniefalco/Beast HTML documentation http://vinniefalco.github.io/beast Boost incubator link: http://blincubator.com/bi_library/beast-2/?gform_post_id=1579 Thanks!

3 3

Extending Boost.Python with NumPy support
by Stefan Seefeld 04 Oct '16

04 Oct '16

Hello, I'm presently working on a few improvements to the Boost.Python module. As part of this I'm refactoring the numeric API to actually support NumPy. There has been quite a lot of effort we put into this in the past (notably a GSoC project I mentored a few years ago), but we never managed to include this into the Boost master branch, so it's never been formally released. As I'm now getting ready to polish this work off, I wonder whether any of this would require a formal submission as a new Boost library, or whether it can just be done under the Boost.Python umbrella ? I reckon this is somewhat of a gray area, so I'd like to clarify whether there are concrete rules for what changes / additions require a formal review process. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

5 8