Re: [Boost-users] Regarding a Vulnerability in Boost.Regex library

[John Maddock via Boost-users]

On 18/04/2024 07:52, kamallochan Jena via Boost-users wrote:

Hello everyone,
Hope you all are doing well.

There is a Vulnerability reported on Boost library as mentioned 
below.  Any guidance or assistance or reply to this mail would be 
greatly appreciated.


*Vulnerability ID:* BDSA-2018-2656
*Vulnerability Details:*
          Boost has a flaw in the function 
boost::re_detail_NUMBER::basic_regex_creator which can lead to a 
buffer over-read. An attacker can craft and send a malicious file 
which will trigger the buffer over-read, leading to a denial-of-service.


Few query w.r.t boost::re_detail_NUMBER::basic_regex_creator() function:

1. Does Boost.Regex library or any Boost library internally use this 
function?

Yes, of course.

2. If the answer is yes, Which all libraries use this function?

No idea.
3. Is this a known vulnerability and is it fixed in the latest Boost 
version? please provide some insights like (any change list or file 
name etc).


If you follow the links to 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6708 you'll see it 
marked as fixed back in 2018.


John.


___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Quadmath.h not found for float128 arm64 rocky linux

[John Maddock via Boost-users]

On 25/08/2023 02:40, David Frank via Boost-users wrote:
When compile with boost float128 on arm64 rocky linux, i got a failure 
of missing quadmath.h


quadmath.h is a system header, if it's not present then float128 is 
unsupported on that platform.



___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] assign a large integer to a cpp_int

[John Maddock via Boost-users]

On 27/05/2023 19:15, Matthew Mawson via Boost-users wrote:

I want to assign a large number to a cpp_int variable like this:

cpp_int large = 
30414093201713378043612608166064768844377641568960512;

and I get this: error: integer literal is too large to be represented in any 
integer type.


You're compiler is correct, there are two ways around this, the first is 
assignment from a string, which must be an explicit cast or construction:


cpp_int 
large{"30414093201713378043612608166064768844377641568960512"};


Or you can create extended precision literals, but these must be in hex 
format, see 
https://www.boost.org/doc/libs/1_82_0/libs/multiprecision/doc/html/boost_multiprecision/tut/lits.html


John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] errors in multiprecision

[John Maddock via Boost-users]

On 20/04/2023 18:28, Gero Peterhoff via Boost-users wrote:

Am 20.04.23 um 18:38 schrieb John Maddock via Boost-users:

On 20/04/2023 16:58, Gero Peterhoff via Boost-users wrote:

Hi John,
some functions do not work with multiprecision-integer-types, e.g.

using T = boost::multiprecision::int256_t;
using ::std::isinf;

const auto x = T{5};
const auto y = isinf(x); // ct error
std::cout << y << std::endl;

gives a CT error.

Correct.  Those functions are pretty meaningless in the context of 
integer types, and no one has ever asked for them.


John.



Ok, herewith I ask for it then :-) Finally this is relevant in the 
template context or a functions with std- AND multiprecision-types 
should/must work.


I'll add it to the list, but be aware that this is not always supported 
for regular integer types: 
https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(filename:'1',fontScale:14,fontUsePx:'0',j:1,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:6,positionColumn:2,positionLineNumber:6,selectionStartColumn:2,selectionStartLineNumber:6,startColumn:2,startLineNumber:6),source:'%23include+%3Ccmath%3E%0A%0Aint+main(int+argc)%0A%7B%0Areturn+std::isinf(argc)%3B%0A%7D%0A'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:33.336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:vcpp_v19_33_x64,deviceViewOpen:'1',filters:(b:'0',binary:'0',binaryObject:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'0',trim:'1'),flagsViewOpen:'1',fontScale:15,fontUsePx:'0',j:1,lang:c%2B%2B,libs:!(),options:'-O2',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:1),l:'5',n:'0',o:'+x64+msvc+v19.33+(Editor+%231)',t:'0')),k:33.336,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compilerName:'x64+msvc+v19.latest',editorid:1,fontScale:14,fontUsePx:'0',j:1,wrap:'1'),l:'5',n:'0',o:'Output+of+x64+msvc+v19.33+(Compiler+%231)',t:'0')),k:33.33,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4


John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] errors in multiprecision

[John Maddock via Boost-users]

On 20/04/2023 16:58, Gero Peterhoff via Boost-users wrote:

Hi John,
some functions do not work with multiprecision-integer-types, e.g.

using T = boost::multiprecision::int256_t;
using ::std::isinf;

const auto x = T{5};
const auto y = isinf(x); // ct error
std::cout << y << std::endl;

gives a CT error.

Correct.  Those functions are pretty meaningless in the context of 
integer types, and no one has ever asked for them.


John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Does Boost.Multiprecision have a forwards declaration header?

[John Maddock via Boost-users]

On 03/12/2022 13:03, Ivan Matek via Boost-users wrote:
I presume not since I could not find it in docs, but decided to double 
check.


My motivation is that I would like to limit heavy includes in my 
header(since intrinsics for avx512 files are 20k+ LOC on my system), 
but I would still like to use proper types in signature of my 
functions (since none of them take .args by value fwd declarations 
would be enough).

So I was hoping for something like iosfwd.

If it matters what part of library I am using:
|cpp_int.hpp|

P.S. I checked if telling compiler that I do not want arch support for 
avx512 would help, but it looks like avx512 intrinsics headers are 
included regardless, and even if it was not I would still like to not 
get into issues when compiling for HW that supports avx512. :)


There's no such header at present, but I've just filed myself a ticket 
as it seems like a good idea to me: 
https://github.com/boostorg/multiprecision/issues/508


Note however, that with just a forward declaration you wouldn't be able 
to do anything with the type inside the function body. Would be useful 
for traits class specializations, or template function overloads which 
are not normally instantiated (as compared to int/long overloads etc) 
though.


John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Norms methods

[John Maddock via Boost-users]

On 25/10/2022 09:00, General Magic - Teodora Bogdan via Boost-users wrote:


Hello,

I was using the Boost library and I wanted to call the l2_norm() 
method from "boost/math/tools/norms.hpp", but is says that the 
namespace boost::math::tools doesn't contain l2_norm() method. When I 
looked into it, I saw that the namespaces at the beginning of the file 
were written"boost::math::tools" instead of "namespace boost { 
namespace math { namespace tools {...".


They are the same thing from C++17 onward, and the norms.hpp header does 
require C++17 in it's implementation.


This should all be documented, but I'll double check.

John.
___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Boost::serialization detection of Cxx Standard

[John Maddock via Boost-users]

On 14/10/2022 10:04, Georg Gast via Boost-users wrote:

Hi,
I developed a patch and a test to serialize std::pmr::(w)strings in 
all 3 archive types. The test I set the requirement to 17. It 
works so far but when I compile the library for using it in my 
application the "hidden" functions behind 
"BOOST_NO_CXX17_MEMORY_RESOURCE" are not found by the linker as the 
define is set when the library is compiled.


How to work around this?

Unfortunately, I think you will need to build the library with C++17 
enabled, ie by added "cxxstd=17" to the b2 command line.


Whether this should be the default when available is open to question I 
guess.


John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Help with a compilation error [Boost/Math]

[John Maddock via Boost-users]

On 03/08/2022 21:56, Peder Lon Hauge via Boost-users wrote:


Hi,

I'm trying to use Boost in order to find values of a 2F3 
hypergeometric function. Just to check that I am using the package the 
correct way, I tried to compile the small test file below (using the 
example from the pFq docs), with the command


$ g++ -o test.exe test.cpp -I /home/peder/boost/boost_1_79_0


As far as I understand, the library is header-only, so I didn't expect 
the compilation error below. I don't where I've made a mistake, and 
I'd greatly appreciate any help with figuring out the error.



Yup, it's a bug and you shouldn't have to do this, but adding #include 
 to your program is a temporary 
workaround until we fix this.



John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Boost Twitter is Blowing Up!!!

[John Maddock via Boost-users]

On 20/06/2022 23:08, Vinnie Falco via Boost-users wrote:

Greetings fellow users, library authors, maintainers, review wizards,
release wizards, and Boost Foundation Board members! As part of our
ongoing effort to continue the revitalization of Boost, a handful of
us have taken the reins to post about Boost on social media. We have
postings on Reddit and Hacker news, blog posts about the new efforts
in Boost.Unordered, and new tweets.

However, we could use your help! Right now the Boost Twitter account
has a measly 957 followers. It would be great to increase our reach,
so I'm asking everyone if they could be so kind as to Follow the
official Boost Twitter account here:



and then amplify our messages by Liking and Retweeting. Starting with
this pinned tweet, which everyone will see when they visit the Boost
Libraries Twittter profile page:



Following the Boost Twitter account will give you up-to-date
information about what is going on with Boost, including articles and
mentions on other social media sites. Here is what we have so far:






To summarize, engaging with Boost related content on social media will
enhance our profile - any help is appreciated!

I think this is a very good idea: well done!  Unfortunately, I need to 
sign up to yet another social media site like I need a hole in the head :(


So for now, I'm going to wish you luck, and cheer on from the sidelines, 
but I really need to stay off twitter and get some actual work done ;)


Best, John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Any objections to making C++14 the current baseline for Boost support and testing?

[John Maddock via Boost-users]

On 06/05/2022 10:19, John McCabe via Boost-users wrote:
Personally, I always thought that, since C++11, Boost was there to 
allow people to be able to use some of the C++11 -> features without 
needing a C++11 -> compiler, so it seems a little odd to seemingly 
abandon those people who're using it for that purpose.


That was an early goal yes, but much of that (TR1 library for example) 
has been deprecated for some time.



___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Any objections to making C++14 the current baseline for Boost support and testing?

[John Maddock via Boost-users]

On 06/05/2022 09:25, Martijn Otto via Boost-users wrote:

I'm not against breaking compatibility with older c++-versions at all,
but given that c++-14 has so few new features compared to c++-11 I do
think that it may be better to bump the baseline to c++-17 directly.

Whether we should do that _now_ is another matter. IMNSHO c++17 has
been out for long enough that you'd expect most people to now have a


There's been some discussion on the develop list about this: I confess I 
was in your camp, but it's been (correctly) pointed out to me that C++14 
is the std version that actually made many of the C++11 features usable ;)


Plus compiler support for gcc and msvc tended to arrive at both C++14 
and 11 together in the same release (gcc had pre-C++11 support earlier, 
but there are enough bugs for it for us to not want to be targeting 
pre-gcc-5).  Both compilers are also c++14 by default at present, I 
realize that will change shortly, but we're not quite there yet.


Thanks, John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Any objections to making C++14 the current baseline for Boost support and testing?

[John Maddock via Boost-users]

On 06/05/2022 09:30, Klebsch, Mario via Boost-users wrote:

Hello,


Does anyone have any concrete objections to Boost moving to a C++14 baseline?

We are still using boost in code cross compiled for legacy target devices, and 
the toolchain does not support C++14. We are currently not using latest boost 
libraries, and won't be affected by this change immediately, but we won't be 
able to update our copy of boost to a recent version.


Do you mind if I ask which libraries you're using?

Thanks, John.


___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [Math / Special Functions] Use more than one user_error function?

[John Maddock via Boost-users]

That's actually a very good question, as things stand, I think the 
only way you can know what the caller is, is to check the string name 
passed to the error handler.  It is possibly "worse" than that too as 
some special functions can call other special functions internally, so 
in a few rare cases, if something has gone badly wrong in the "outer" 
function, the actual error may be generated in the "inner" function :(


But leaving aside that issue for the moment, I would probably create a 
sorted table of std::pair, with the first 
member of the pair being our name, the second your name, and then do a 
std:::lower_bound to find a matching entry and do the name 
translation.  I don't think our names have ever changed, so while 
we've never guaranteed stability of those, it's hard to imagine them 
changing unless someone spots a really grievous spelling mistake or 
something ;)  You would still need to perform the rather tedious job 
of calling each function you're wrapping with say NaN parameters, and 
then logging the string name of the function in the error handler so 
you know what to put in the table.


Maybe we're both over-thinking this, why not just:

double erfinv_double(double x)

{

 try{

 return erf_inv(x, special_policy());

   }

   catch(const std::domain_error&)

   {

  // Python error handling here.

   }

   catch(whatever-else-may-get-thrown){ /*more error handling*/}

}

?


___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [Math / Special Functions] Use more than one user_error function?

[John Maddock via Boost-users]

On 13/04/2022 17:15, Warren Weckesser via Boost-users wrote:

I am wrapping some boost special functions as NumPy "ufuncs" for
the Python library SciPy, and I am setting a policy to control
how errors are handled.  For example, the wrapper of erf_inv
(for C++ types float, double and long double) is wrapped as the
function scipy.special.erfinv (i.e. the Python function is
erfinv in the module scipy.special).

The actual core instantiation of the function for type, say, double,
in C++ that is called by the ufunc implementation is

 double erfinv_double(double x)
 {
 return erf_inv(x, special_policy());
 }

where erf_inv is the Boost function, and special_policy is
created as

 template 
 T user_domain_error(const char *function, const char * message,
const T& val)
 {
 sf_error("erfinv", SF_ERROR_DOMAIN, NULL);
 return std::numeric_limits::quiet_NaN();
 }

 typedef policy<
 domain_error,
 overflow_error
 > special_policy;

Note that the error handler is calling sf_error(), a function in
the SciPy special library.  The first argument is the name of the
SciPy Python function.  That function might generate a Python
warning or set a Python exception, and the name displayed in the
error message should be the name of the SciPy function, and not
something like "boost::math::erf_inv[...]".

This leads to the problem.  The above code, with a hard-coded string
"erfinv" passed to sf_error(), works for erfinv, but obviously I
can't use the same implementation of user_domain_error for a wrapper
of, say, tgamma_ratio.

So the question is, can different policies be created that have
different user-defined error handlers?  Or is there a clever way
to get the SciPy name into the user_domain_error() function?
(I hope there is something simple--I am not a C++ guru, so I
may have missed something obvious.)

I am considering creating a mapping from some parsed version of the
function argument of user_domain_error to the SciPy names.  E.g. the
function argument could be scanned for the occurrence of "erf_inv",
and know that the name "erfinv" should be passed to sf_error().  A
table of regex patterns with corresponding SciPy names might do the
trick.  But I'm wondering if there is a more elegant (and more
maintainable) solution.


That's actually a very good question, as things stand, I think the only 
way you can know what the caller is, is to check the string name passed 
to the error handler.  It is possibly "worse" than that too as some 
special functions can call other special functions internally, so in a 
few rare cases, if something has gone badly wrong in the "outer" 
function, the actual error may be generated in the "inner" function :(


But leaving aside that issue for the moment, I would probably create a 
sorted table of std::pair, with the first 
member of the pair being our name, the second your name, and then do a 
std:::lower_bound to find a matching entry and do the name translation.  
I don't think our names have ever changed, so while we've never 
guaranteed stability of those, it's hard to imagine them changing unless 
someone spots a really grievous spelling mistake or something ;)  You 
would still need to perform the rather tedious job of calling each 
function you're wrapping with say NaN parameters, and then logging the 
string name of the function in the error handler so you know what to put 
in the table.


And just to be clear, what you cannot do, is overload anything that 
would be compile-time different for each function: all domain_errors go 
through the same template instantiation 
(boost::math::policies::raise_domain_error for example) with only the 
arguments differing by caller.  Ah, but wait, you could technically give 
each function a different Policy and then overload raise_domain_error 
etc by the policy type, but honestly that sounds worse to me, plus I 
think you would struggle to create enough "fake" Policy arguments to 
cover everything... it might likely lead to code bloat too where some 
special functions call others.  But I guess it might work if you really 
needed a completely different handler for each function.


HTH, John.

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Very intermittent segmentation fault with boost::multiprecision

[John Maddock via Boost-users]

On 10/02/2022 22:07, tjisana (泰志) via Boost-users wrote:
Okay, rebuild the binary with AddressSanitizer. Since I need to run 
the program during market hours, I'll do so first thing tomorrow - 
will let you know how it goes.


Given that the fault is intermittent, and the offending line in the 
backtrace is innocuous, I would hazard a guess at stack overflow.


BTW, just to say, cpp_dec_float does not do correct bankers rounding, 
and so may not be a good choice for critical financial programs.


Best, John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] exception on boost serialization

[John Maddock via Boost-users]

On 12/01/2022 09:04, Alessio Mochi via Boost-users wrote:

Hello Gavin,
I have not defined BOOST_NO_EXCEPTIONS.


Ahhh, looks like our bug, I've just filed a PR to fix this here: 
https://github.com/boostorg/serialization/pull/250


The minimal header to #include prior to whatever serialization header 
you're using is boost/throw_exception.hpp BTW. Serialization should be 
doing that anyway but isn't :(


The reason this hasn't been spotted until now, is that 
boost/throw_exception.hpp gets #included by very nearly everything in 
boost so it's an easy one to miss.


HTH, John.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] exception on boost serialization

[John Maddock via Boost-users]

On 12/01/2022 09:04, Alessio Mochi via Boost-users wrote:

Hello Gavin,
I have not defined BOOST_NO_EXCEPTIONS.
I don't know why a small project with qt and boost serialization work 
and this one no. I tried to add #include  
before include the serialization header,

I don't know if it's correct but seem to fix the problem


What happens if at the very start of your cpp file you add:

#include 

#ifdef BOOST_NO_EXCEPTIONS

#error "Oooops"

#endf

Does the #error get hit?





Il giorno mer 12 gen 2022 alle ore 00:44 Gavin Lambert via Boost-users 
 ha scritto:


On 12/01/2022 10:22, Alessio Mochi wrote:
> Yes, this is a piece of included hierarchy error is show. Thanks
in advance
[...]
> 1>Note: including file:
>   E:\boost_1_78_0\boost/serialization/throw_exception.hpp
>
1>E:\boost_1_78_0\boost/serialization/throw_exception.hpp(30,14):
error
> C2039: 'throw_exception': is not a member of 'boost'
> 1>E:\boost_1_78_0\boost/serialization/throw_exception.hpp(24):
message :
> see declaration of 'boost'

That error at that site suggests that you are compiling with
BOOST_NO_EXCEPTIONS defined, which in turn means that you need to
define
boost::throw_exception yourself before including any boost headers to
define what you want to happen when an exception is "thrown" anyway.
(Typically a call to abort(), possibly among other things.)

Otherwise, you should remove BOOST_NO_EXCEPTIONS and allow it to
throw
normally.

If you're not defining this explicitly in your preprocessor options,
check if you have disabled exceptions in your compiler options.


I'm not really familiar with Qt but google suggests that some older
versions of it disable exceptions by default, but that newer versions
might not.  Perhaps you need to upgrade.
___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users


___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] assigning a "float128" variable with a regular "double" variable

[John Maddock via Boost-users]

On 26/11/2021 17:50, Jacques Mequin via Boost-users wrote:


I am a fresh new user   ( I need to extend some EIGEN library feature 
by using your float128 )


How to assign a "float128" variable with a regular "double" variable ?

With my source code in attachement

      double       double_pi =  3.141592653589793     ;
      float128  float128_pi =  3.141592653589793Q  ;

      produces the output that looks fine to me

      double_pi =
      3.141592653589793e+00

      float128_pi =
      3.14159265358979300e+00

but  thestatement    float128_pi = double_pi ;    produces

      float128_pi =
3.141592653589793115997963468544185e+00

How to get 3.14159265358979300e+00 also from an 
assigment  ???


You can't: remember your double has 53-bit precision, 3.141592653589793 
is it's decimal value ROUNDED to 16 decimal places (note that you would 
have to print more digits than that to be able to round-trip to and from 
decimal), converting to a float128_t gives you EXACTLY the same binary 
value, but you're code is now printing out more decimal places, so 
you're seeing it's "true" decimal value, rather than the rounded value 
you had before from the double output.



Hope that makes sense, John.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [multiprecission] Large divides layered on 128 bit divides

[John Maddock via Boost-users]

On 19/08/2021 23:02, Neill Clift via Boost-users wrote:


Hi,

The architecture of cpp_int being build on 64 bit arithmetic using 128 
bit double_limb_type is interesting.


I have a question on the large divide (divide_unsigned_helper). It 
uses the upper portions of the large integers to get an estimation of 
the quotient. Subtracts out a multiple of that quotient and repeats.


It does this in 128 bit values if available from the compiler:

 double_limb_type a = 
(static_cast(prem[r_order]) << CppInt1::limb_bits) | 
prem[r_order - 1];


 double_limb_type b = py[y_order];

 double_limb_type v = a / b;

The compiler emulates this operation in the routine __udivmodti4 which 
itself uses an iterative approach.


It seems to use a pretty basic shift and subtract algorithm mind you.

As a general rule for multiprecision is it OK to layer the Knuth like 
algorithm D on top of each other this way.


I have no idea myself but wonder if this is a known issue. I would 
have guessed that it made sense to do a 64 by 64 bit divide to guess 
the quotient and repeat.



Good question.

As I recall I tried both single-limb and double-limb partial-quotients 
and the double-limb (128 bit) version was slightly faster.


There is a balance here between removing as large a chunk as you can 
with each loop, compared to more expensive operations within the loop.  
You could for example, perform "Karatsuba-like" division by splitting a 
B-bit numerator into two B/2 chunks and perform schoolboy division on 
the two "digit" numbers.  But the fact that no-one seems to have done 
this suggests how well it must work ;)  On the other hand, __int128, 
while a synthetic type, is sufficiently well optimised for this to be a 
useful chunk size.


HTH, John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [multiprecission] some thoughts on add_unsigned.hpp

[John Maddock via Boost-users]

On 19/08/2021 02:43, Neill Clift via Boost-users wrote:


Hi,

In my program I see a lot of time taken up by add/subtract_unsigned. I 
have a couple of thoughts on the code:


Carry propagation outside the range of the smallest number can be 
improved:


  for (; i < x && carry; ++i)

 carry = ::boost::multiprecision::detail::addcarry_limb(carry, 
pa[i], 0, pr + i);


Maybe this:

  for (; i < x && carry; ++i)

 carry = ::boost::multiprecision::detail::addcarry_limb(0, 
pa[i], 1, pr + i);


This generates just an inc on my machine but unfortunately it doesn’t 
eliminate the loads and stores. I think on average the carry chain 
must be small though.


You have the same situation on subtract.

add_unsigned and subtract_unsigned are inconsistent at the tail end 
after carry propagation:


add_unsigned:

  if (i == x && carry)

  {

 // We overflowed, need to add one more limb:

 result.resize(x + 1, x + 1);

 if (result.size() > x)

    result.limbs()[x] = static_cast(1u);

  }

  else

 std::copy(pa + i, pa + x, pr + i); ß- if I == x we do the 
copy. We also do the copy even if the output and input overlap


subtract_unsigned:

  // Any remaining digits are the same as those in pa:

  if ((x != i) && (pa != pr)) ß-- we do these checks here and 
avoid the copy


 std_constexpr::copy(pa + i, pa + x, pr + i);

I am seeing a lot of time being used by that general copy above in 
add_unsigned  when it can be avoided.


This stuff is totally awesome and works well in my program. So thanks 
for working on this stuff.




Thanks Neill, it might be a few days at best before I can look at this 
in detail, I wonder could you either file a bug report or a PR at 
https://github.com/boostorg/multiprecision/ and then this won't get 
lost.  Thanks!!  John.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Boost uses unoptimized subtraction because of typo in intel_intrinsics.hpp

[John Maddock via Boost-users]

On 18/08/2021 17:23, Neill Clift via Boost-users wrote:


Hi,

In my program I am seeing my code use the slower (I assume) 
subtract_unsigned_constexpr rather than subtract_unsigned with he 
borrow chain handled intrinsics.


This seems to be happening because of these lines in intel_intrinsics.hpp:

#if defined(__clang__) && (__clang__ < 9)

// We appear to crash the compiler if we try to use these intrinsics?

#undef BOOST_MP_HAS_IMMINTRIN_H

#endif

__clang__ is not the version but just the value 1. I expect this 
should be the major version instead:



Good catch, see https://github.com/boostorg/multiprecision/pull/356


#define __clang__ 1

#define __clang_major__ 12

#define __clang_minor__ 0

As an aside 128bit support does work in windows with clang. I have to 
force it on like this:


#define __STRICT_ANSI__

#define BOOST_HAS_INT128

#define BOOST_MP_HAS_IMMINTRIN_H

#include 


I'll look at that separately, thanks John.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] boost/rational.hpp and VS2019

[John Maddock via Boost-users]

What architecture are you building for?

These intrinsic headers come from boost/integer/common_factor_rt.hpp and:

#if ((defined(BOOST_MSVC) && (BOOST_MSVC >= 1600)) || 
(defined(__clang__) && defined(__c2__)) || (defined(BOOST_INTEL) && 
defined(_MSC_VER))) && (defined(_M_IX86) || defined(_M_X64))

#include 
#endif

I'm wondering if the check for x86 needs to be applied to the BOOST_MSVC 
check as well as the intel one?


John.

I'm guessing this might be solvable by updating to a newer version of 
boost (currently I'm running ver 1.71.0) but before updating, I 
wondered if there might be something obvious that 'm missing


I'm building with Visual Studio 2019 and I get a whole bunch of errors 
simply by adding this line to an empty source file:-


  #include "boost/rational.hpp"

It seems to be the same 6 errors but at various different lines - i.e. 
these errors, over & over again:-


  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(146,19): 
error C4430: missing type specifier - int assumed. Note: C++ does not 
support default-int
  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(146,8): 
error C2146: syntax error: missing ';' before identifier '_mm_macc_ps'
  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(147,20): 
error C4430: missing type specifier - int assumed. Note: C++ does not 
support default-int
  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(147,9): 
error C2146: syntax error: missing ';' before identifier '_mm_macc_pd'
  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(148,19): 
error C4430: missing type specifier - int assumed. Note: C++ does not 
support default-int
  Visual 
Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\ammintrin.h(148,1): 
error C2086: 'int __m128': redefinition


I just wondered if this might ring a bell with someone?  e.g. might 
there be some preprocesser #define that I should've defined?  (or a 
#define that I shouldn't be defining...)


Thanks for any suggestions,  John
___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [boost][multiprecision/mpc][math/quadrature] Why boost::multiprecision::exp gets stuck when evaluating complex-valued integral?

[John Maddock via Boost-users]

On 06/08/2021 11:18, Kirill Kudashkin via Boost-users wrote:

thank you for your reply. I implemented your idea and it worked.

Though, I had to constraint the exponent not only from below but from 
above.


Nod.  One of the problems with this form of quadrature is that it can 
reach very far out into the end points sometimes you really need 
this though if that's where all the area is.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [boost][multiprecision/mpc][math/quadrature] Why boost::multiprecision::exp gets stuck when evaluating complex-valued integral?

[John Maddock via Boost-users]

I have encountered a problem while using Boost C++ libraries ( 
multiprecision/mpc.hpp, math/quadrature) which I cannot resolve.


This problems appears when running the following piece of code

||


OK, the value that triggers the issue is 
-6.27513002646369320950230099689165841342351751646e-118909138 - 
6.27513002646369320950230099689165841342351751646e-118909138i


And this appears to be an exponent range issue - basically mpc_exp gets 
slower and slower as the exponents approach -INF and eventually grinds 
to a halt.


I'm not yet sure if this is a bug in MPC, or if you've just hit a 
stupidly hard value to compute - wolframalpha dies as well with this case.


For the purposes of calculating the integral, guess you could just 
return 1 from your functor whenever the exponent is sufficiently small?


HTH, John.

|#include  #include 
 #include 
 #include 
 #include 
 namespace mpns = 
boost::multiprecision; typedef 
mpns::number > 
mpc_type ; typedef mpc_type::value_type mp_type ; int main() { using 
boost::math::constants::root_pi ; mpc_type z{mp_type(1),mp_type(1)} ; 
auto f = [&](mp_type x) { //actually I did not test if all these 
conditions are needed... if (boost::math::fpclassify (x) == 
FP_ZERO) { return mpc_type(mp_type(1)) ; }; if 
(boost::math::fpclassify (x) == FP_INFINITE) { return 
mpc_type(mp_type(0)) ; }; mp_type x2 = mpns::pow(x,2U) ; if 
(boost::math::fpclassify (x2) == FP_ZERO) { return 
mpc_type(mp_type(1)) ; }; if (boost::math::fpclassify (x2) == 
FP_INFINITE) { return mpc_type(mp_type(0)) ; }; mpc_type ex2 = 
mpns::exp(-z*x2) ; if (boost::math::fpclassify (ex2) == 
FP_ZERO) { return mpc_type(mp_type(0)) ; }; return ex2 ; } ; mp_type 
termination = boost::math::tools::root_epsilon  () ; mp_type 
error; mp_type L1; size_t max_halvings = 12; 
boost::math::quadrature::exp_sinh integrator(max_halvings) ; 
mpc_type res = integrator.integrate(f,termination,,) ; 
mpc_type div = 2U*mpns::sqrt(z) ; mpc_type result = 
(mpc_type(root_pi ())/div) - res ; return 0; } |


||Namely, the problem appears when evaluating the exponent.

The code is compiled without any problems, but hangs on computing

|    mpc_type ex2 = mpns::exp(-z*x2) ;|

It was possible to go into the function while debugging.

It crashed eventually, when the compiler reached "unable to resolve 
non-existing file.../src/init2.c".


I let it run for a while checking the call stack. It appears that the 
programs is stuck atcalling ___gmpn_sub_n_coreisbr().


Or better, in the call stuck it appeared frequently.


I did several tests.

The real-valued version (with mpfr_backend <2000>) works without any 
problems.


cpp_complex_backend <100> works fine, but I could not test higher 
precision yet, since it is much slower.


I found a work-around which is not ideal. Namely,

mpc_type ex2 = mpc_type(mpns::exp(x2)) ;
mpc_type ezx2 = mpns::pow(ex2,-z) ;

works fine with mpc_complex_backend <2000>.

The lambda-function as it is declared in the code above works and 
yields correct numbers.


The problem appears when it is called from the integrator.


My system.

I use openSUSE Tumbeleweed.

I installed boost libraries as provided by 
|boost_1_76_0-gnu-mpich-hpc-devel.|


Complier -> g++, cppStandard gnu+17.

I check that I have all libs, e.g. libgmp, libmpc, libmpfr and etc.

All headers are present (the programs is complied without any warnings).


Thank you in advance and

Best wishes,

Kirill

||



___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] [boost][multiprecision/mpc][math/quadrature] Why boost::multiprecision::exp gets stuck when evaluating complex-valued integral?

[John Maddock via Boost-users]

I have encountered a problem while using Boost C++ libraries ( 
multiprecision/mpc.hpp, math/quadrature) which I cannot resolve.


I'm a bit tied up for a few days, but I'll look into this as soon as I 
can, John.


This problems appears when running the following piece of code

||
|#include  #include 
 #include 
 #include 
 #include 
 namespace mpns = 
boost::multiprecision; typedef 
mpns::number > 
mpc_type ; typedef mpc_type::value_type mp_type ; int main() { using 
boost::math::constants::root_pi ; mpc_type z{mp_type(1),mp_type(1)} ; 
auto f = [&](mp_type x) { //actually I did not test if all these 
conditions are needed... if (boost::math::fpclassify (x) == 
FP_ZERO) { return mpc_type(mp_type(1)) ; }; if 
(boost::math::fpclassify (x) == FP_INFINITE) { return 
mpc_type(mp_type(0)) ; }; mp_type x2 = mpns::pow(x,2U) ; if 
(boost::math::fpclassify (x2) == FP_ZERO) { return 
mpc_type(mp_type(1)) ; }; if (boost::math::fpclassify (x2) == 
FP_INFINITE) { return mpc_type(mp_type(0)) ; }; mpc_type ex2 = 
mpns::exp(-z*x2) ; if (boost::math::fpclassify (ex2) == 
FP_ZERO) { return mpc_type(mp_type(0)) ; }; return ex2 ; } ; mp_type 
termination = boost::math::tools::root_epsilon  () ; mp_type 
error; mp_type L1; size_t max_halvings = 12; 
boost::math::quadrature::exp_sinh integrator(max_halvings) ; 
mpc_type res = integrator.integrate(f,termination,,) ; 
mpc_type div = 2U*mpns::sqrt(z) ; mpc_type result = 
(mpc_type(root_pi ())/div) - res ; return 0; } |


||Namely, the problem appears when evaluating the exponent.

The code is compiled without any problems, but hangs on computing

|    mpc_type ex2 = mpns::exp(-z*x2) ;|

It was possible to go into the function while debugging.

It crashed eventually, when the compiler reached "unable to resolve 
non-existing file.../src/init2.c".


I let it run for a while checking the call stack. It appears that the 
programs is stuck atcalling ___gmpn_sub_n_coreisbr().


Or better, in the call stuck it appeared frequently.


I did several tests.

The real-valued version (with mpfr_backend <2000>) works without any 
problems.


cpp_complex_backend <100> works fine, but I could not test higher 
precision yet, since it is much slower.


I found a work-around which is not ideal. Namely,

mpc_type ex2 = mpc_type(mpns::exp(x2)) ;
mpc_type ezx2 = mpns::pow(ex2,-z) ;

works fine with mpc_complex_backend <2000>.

The lambda-function as it is declared in the code above works and 
yields correct numbers.


The problem appears when it is called from the integrator.


My system.

I use openSUSE Tumbeleweed.

I installed boost libraries as provided by 
|boost_1_76_0-gnu-mpich-hpc-devel.|


Complier -> g++, cppStandard gnu+17.

I check that I have all libs, e.g. libgmp, libmpc, libmpfr and etc.

All headers are present (the programs is complied without any warnings).


Thank you in advance and

Best wishes,

Kirill

||



___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] R: Boost multiprecision as array index

[John Maddock via Boost-users]

On 03/08/2021 17:53, Claudio La Rosa via Boost-users wrote:


My array have only 3 elements, but I indexed it with an modulo 
operation (%) that use a uint128_t value. The result of modulo 
operation is a uint128_t value type.


But well, I now use with success a standard cast for obtain a valid 
index type value!


OK, there is also a function integer_modulus(a,b) which returns the 
result of a%b as the type of b (since the result must be smaller than b).




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Boost multiprecision as array index

[John Maddock via Boost-users]

On 03/08/2021 07:34, Claudio La Rosa via Boost-users wrote:


Hi to all,

I unsuccessfully  tried to use a boost multiprecision variable 
(object?) as index of an array.


Int myArray[100];

uint128_t index = 23;

int value = myArray[index];

This code don’t work.

There is a way for to use a multiprecision as index of an array?


You would need to explicitly cast the variable to a std::size_t.

But I would rather question the wisdom of using a multiprecision type in 
that context?


John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] g++ linking error with lboost_program_options

[John Maddock via Boost-users]

On 23/07/2021 07:57, Stefano Gragnani via Boost-users wrote:

The development system is:
MacBook Pro Intel i9
MacOS  Big Sur 11.4
gcc version 11.1.0 (Homebrew GCC 11.1.0_1)
clang version 12.0.0

I'm having trouble compiling some examples from the book 'Boost C ++ 
Application Development Cookbook’.

The problem occurs *only* *with g ++,* *with clang there is no error.*
Mistakes only occur when linking to -lboost_program_options, 
-lboost_system and -lboost_filesystem, with any other library (eg 
-lboost_chrono) everything is fine.


Did you compile the libraries with g++ or are they clang compiled?  I 
would expect that mixing the 2 would cause issues.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Trouble compiling with float128 data type

[John Maddock via Boost-users]

On 21/07/2021 19:07, Stefano Gragnani via Boost-users wrote:

further clarification if possible:

why the 2 lines that don't compile:

// float128 e1 = exp(1.Q); // Note argument to exp is type float128.
// std::cout << e1 << std::endl; // 2.71828182845904523536028747135266231

 if i put them in the following code compile regularly?


You're mixing up 2 different things:

* If you want to use __float128 "as if" it were no different to 
float/double etc, then include boost/math/cstdfloat.hpp


* If you want a 128-bit floating point type which hides the underlying 
implementation then use boost/multiprecision/float128.hpp.


Note that these are completely different approaches to the same problem, 
and are completely different types.


Also note that strictly speaking, boost/math/cstdfloat.hpp is NOT C++ 
conformant, as it adds function overloads directly to namespace std.





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Trouble compiling with float128 data type

[John Maddock via Boost-users]

On 21/07/2021 16:56, Stefano Gragnani via Boost-users wrote:

ok things are better but i still get errors:

> Executing task: g++-11 -g -I/usr/local/Cellar/boost/1.76.0/include/ 
-I/usr/local/include/ -L/usr/local/Cellar/boost/1.76.0/lib/ 
-L/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/ 
-L/usr/local/Cellar/gmp/6.2.1/lib/ -L/usr/local/Cellar/mpfr/4.1.0/lib/ 
-std=gnu++20 -lmpfr -lgmp -lquadmath -lboost_system -lboost_filesystem 
'-fext-numeric-literals' float128_example.cpp -o main <


float128_example.cpp: In function 'int main()':
float128_example.cpp:186:20: error: call of overloaded 
'exp(__float128)' is ambiguous
  186 |   float128 e1 = exp(1.Q); // Note argument to exp is type 
float128.

      |                 ~~~^


The compiler is quite correct: there are no std lib functions for the 
built in type __float128, there are however for 
boost::multiprecision::float128 which is the type you should be using 
throughout.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Trouble compiling with float128 data type

[John Maddock via Boost-users]

On 20/07/2021 18:44, Stefano Gragnani via Boost-users wrote:


Hi,

I'm having trouble compiling code that contains float128 data type.
I'm using MacOS Big Sur 11.4.
Compiler: gcc version 11.1.0 (Homebrew GCC 11.1.0_1)

I have no other problems with Boost, the only problem is when I use 
float128.


Please note that I have no problem compiling using libquadmath without 
using Boost using the __float128 data type.


I use Visual Studio Code:

You can manually fix this by defining BOOST_HAS_FLOAT128 on the command 
line.  However, you may still hit other errors as __float128 and 
quadmath.h aren't really fully supported in ISO C++ mode.  The correct 
fix is to use -std=gnu++20, and then GNU extensions including __float128 
are turned on.


HTH, John.


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Build issue utilizing Boost::regex

[John Maddock via Boost-users]

On 28/05/2021 17:41, Brad Smith via Boost-users wrote:

Hi,

I am trying to upgrade from Boost 1.73 to Boost 1.76 and down to only 
one consumer left that will

not build. This appears to be an issue with Boost::regex.

I noticed this in the Boost 1.76 release notes..

"Regex is now header only except in C++03 mode."

Clang defaults to C++14, but I noticed BOOST_REGEX_CXX03 is defined. 
The project does not

specify a particular C++ version so it should be using C++14.


Are you defining BOOST_REGEX_RECURSIVE?  That would force it into 
legacy-mode.




The functions below exist in the Boost 1.73 Boost::regex library but 
not in the 1.76

library.


Hmm, that's strange, do you have a test case?  We do test C++03 legacy 
mode in CI, so this should all still be working, plus nothing should 
actually have changed in those classes compared to 1.73.


Best, John.



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] TOMS748 question

[John Maddock via Boost-users]

On 26/01/2021 15:46, Shriramana Sharma via Boost-users wrote:

Namaste.

This is wrt the TOMS748 math root finding implementation:

Given that `if(fa == 0)` is handled at:

https://github.com/boostorg/math/blob/develop/include/boost/math/tools/toms748_solve.hpp#L325

… and the function returns in case of the above condition, it is not
clear to me what the need is for the `if (fa != 0)` at:

https://github.com/boostorg/math/blob/develop/include/boost/math/tools/toms748_solve.hpp#L342


You're quite right - it's superfluous, will fix.


Now I also note similar checks at:

https://github.com/boostorg/math/blob/develop/include/boost/math/tools/toms748_solve.hpp#L352
https://github.com/boostorg/math/blob/develop/include/boost/math/tools/toms748_solve.hpp#L366

… but regarding those lines, while I can understand the need for
checking there after more bracketing work is done, it is not clear to
me why `(fa == 0)` is alone checked for, and not `(fb == 0)` as well.
I would have thought the algorithm is not biased towards a or b.


When bracket() is called, it updates either fa or fb with the next value 
(fc), and when fc is zero then fa is always set to zero, and the result 
is always a.  So checking fb == 0 is unnecessary after a bracket() call.



Indeed, in the last steps from:

https://github.com/boostorg/math/blob/develop/include/boost/math/tools/toms748_solve.hpp#L465,

… both the conditions are checked for,


Somewhat different situation - at this point the loop has terminated, 
and we're just tightening up our interval in the case that one of a or b 
is right on the root.  This is a nicety not required by the algorithm as 
such, and indeed the fb == 0 branch *may* be superfluous, but I would 
want to think very carefully indeed before changing it ;)


Best, John Maddock.

--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] limited accuracy for tanh-sinh integrator

[John Maddock via Boost-users]

On 16/08/2020 21:15, Anirban Pal via Boost-users wrote:


Hello,

I’m using the tanh-sinh integrator to integrate a simple function f(x) 
= 0.26*x from 3.0 to 4.0.
The exact result is 0.91. With the integrator I’m getting a result 
accurate to only 10^-18 with cpp_bin_float_100 multiprecision.


You have the double precision constant 0.26 in your code, and since this 
is an inexact binary value, everything that depends on that constant is 
inherently limited to double precision.  Try constructing it as Real(26) 
/ 100.



|typedef boost::multiprecision::cpp_bin_float_100 Real; int main(int 
argc, char **argv) { using namespace boost::math::quadrature; using 
namespace std::placeholders; tanh_sinh integrator; auto f2 = 
[](Real x) { Real a = 0.26; return x*a; }; std::cout << 
std::setprecision(std::numeric_limits::max_digits10) << "Comp.: 
" << integrator.integrate(f2, (Real) 3.0, (Real) 4.0) << std::endl; 
return 0; } |

I'm getting an output of

Comp.: 
0.91003108624468950438313186168670654296874999429


which I'm a bit curious about. I was wondering if I can improve the 
result.


Thank you.


--
Anirban Pal




___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Integrate function with arguments using quadrature

[John Maddock via Boost-users]

On 14/08/2020 22:56, Anirban Pal via Boost-users wrote:

Hello,

I'm trying to integrate functions with BOOST quadrature routines. So 
far they have been extremely impressive accuracy-wise, particularly 
with multiprecision features.


I wish to integrate a function and pass some arguments to it. These 
arguments can be scalars, matrices, structs or objects. I was 
wondering if there is an example that explores this. Would I need to 
use a boost.function? Or would a function pointer work?


To create a reusable single-valued functor that integrates from [a, x] 
for fixed a, then I think some nested lambda expressions would work:


   auto integral = [](double x)
   {  // Integrates from 0 to x:
  static tanh_sinh integrator;
  static auto f = [](double x) { return 5 * x + 7; };
  return integrator.integrate(f, 0.0, x);
   };
   std::cout << integral(2) << std::endl;
   std::cout << integral(4.5) << std::endl;

I'm not sure what you had in mind with non-scalar arguments, but if you 
need to evaluate the above at multiple x values [x_1, x_2 x_n] then 
conceivably you could integrate from


[a, x_0]

[x_1, x_2]



[x_n-1, x_n]

and then sum to get the integrals

[a, x_0]

[a, x_1]



[a, x_n]

Which may or may not be more efficient.

HTH, John.



I currently have an implementation using GSL_functions which 
explicitly allow the function and parameters to be passed as pointers. 
I am curious if I can do something similar with boost.


Thank you.


--
Anirban Pal




___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [Boost-users] Difficulty using boost quadrature library

[John Maddock via Boost-users]

On 14/08/2020 01:07, Anirban Pal via Boost-users wrote:

Hello everyone,

I'm new to using boost and I'm trying to use its quadrature routines, 
specifically

the *tanh_sinh* integrator. I'm trying to run the examples here:


https://www.boost.org/doc/libs/1_66_0/libs/math/doc/html/math_toolkit/double_exponential/de_tanh_sinh.html 



I've been successful using it with the *double* datatype. However, I 
can't seem to work with the *Real* datatype. When I run the following, 
I'm successful.

tanh_sinh  integrator;
auto  f  =  [](double  x)  {  return  5*x  +  7;  };
double  Q  =  integrator.integrate(f);
Q  =  integrator.integrate(f,  0.0,  1.1);

But when I run the following:
auto  f  =  [](Real  x)  {  return  log(x)*log(1-x);  };
Real  Q  =  integrator.integrate(f,  (Real)  0,  (Real)  1);


I confess that's not the best example in the docs :(

The name "Real" is just used as "some kind of floating point type" - 
replace with whatever actual type you wish to use.



I get the error:

boost_test.cxx: In function ‘int main(int, char**)’:
boost_test.cxx:47:15: error: ‘Real’ has not been declared
  auto f2 = [](Real x) { return log(x)*log(1-x); };
               ^~~~
boost_test.cxx:48:2: error: ‘Real’ was not declared in this scope
  Real Q2 = integrator.integrate(f2, (Real) 0, (Real) 1);

I think I need to include the right headers for this to go away. 
However, I'm not sure what the correct header file is.


Thank you for your attention.

--
Anirban Pal




___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Re: [boost] [for Win] [was: Re: 1.30.0-1.30.2: no more threadsupportfor Linux?]

[John Maddock]

 I haven't followed this thread completely, but I have a question.
 I'm working on Win 2k, and I'm using VC++ 7.1. Building
 boost with this toolset, do I need to specify something to make it
 thread-safe?

Actually you need to do more than that - you need to compile Boost against
the same runtime library options that you use to build your application -
otherwise you will get linker errors at the very least.  Relevant options
are:

threadingmulti : multithreaded builds
threadingsingle : single threaded builds
runtime-linkdynamic : dynamic runtime
runtime-linkstatic : static runtime.

The default behaviour is to build against the dynamic (and thread safe)
runtime, so if that's what you are using then you're OK, if you want the
static runtime library versions as well then:

bjam -sTOOLS=vc7.1 -sBUILD=debug release threadingmulti/single
runtime-linkstatic

will do the job.

Oh, and to answer your question: Boost is always as thread safe as the
runtime it's built against.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: 1.30.0-1.30.2: no more thread support for Linux?

[John Maddock]

  Threading support is on when BOOST_HAS_THREADS is defined, and off when
it's
  not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both
of
  these mentioned in the configure generated user.hpp (and in the config
  docs).

 So if I my program runs only on systems that I know support threads,
 and I want shared_ptr to use threading support, my program can guarantee
 this by defining BOOST_HAS_THREADS? No matter whether the user's Boost
 install is -

 1) Simply extracted from the tarball
 2) Configured without thread support
 3) Configured with thread support

 And I don't need to define anything about the platform thread library
being
 used, like BOOST_HAS_PTHREADS?

OK lets start with Linux and gcc as a specific and special case - in this
case I think that will work - BOOST_HAS_PTHREADS will be defined anyway, but
remember that your std lib will not be thread safe unless you define
_REENTRANT, and if you do that then BOOST_HAS_THREADS will get defined
anyway by the config system (either the out-the-box version or the
configure'd one).  Of course the user could always manually configure boost
in some obscure way, or deliberately disable thread support with
BOOST_DISABLE_THREADS, but if they've done that then you should probably be
emitting a #error not trying to work around it.

In the general case though, we're back to the situation that your code will
not be thread safe unless you invoke your chosen compiler with some magic
special flag (or in the case of IBM Visual Age use a different compiler
front end altogether), and if you do that then Boost.config will detect it's
presence by whatever macros it sets (usually but not always _REENTRANT) and
turn on BOOST_HAS_THREADS.  You should always regard BOOST_HAS_THREADS as
*information*, not as something you set yourself, in 99% of cases if you
find it's not set, then it's because the compiler in it's current mode isn't
capable of producing thread safe code.

Note for example that Boost.config explicitly defines BOOST_DISABLE_THREADS
for gcc on some platforms because we know that gcc isn't capable of
producing thread safe code on those platforms yet (even though they do have
a perfectly good pthread lib).

Finally if you're configuring your program via autoconf then there are some
nice looking autoconf macros on the net, for example:
http://ac-archive.sourceforge.net/Installed_Packages/acx_pthread.html.

Sorry to make this complicated, but threads _are_ complicated

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: 1.30.0-1.30.2: no more thread support for Linux?

[John Maddock]

 I was thinking of a view from the point of view of each individual
 library.  e.g., the shared_ptr docs mention what to define to
 turn off thread support on a boost that was configured with thread
 support on, but I didn't see a specific explanation of what to define to
 turn thread support on without Boost Config.

  Boost Config seems to hide those details fairly effectively for
developers
  who don't distribute their code (or distribute Boost along with their
  code).
 
  The problem I see is that developers who distribute code that depends
on
  boost can't count on the user's version of Boost being configured in
any
  particular way (or at all - the docs suggest just untarring it as a
valid
  way to use the header-only modules).
 
  There shouldn't really be any difference between the config after just
  extracting the tarball, and after running configure.

 Maybe I'm missing something - when I run boost/libs/config/configure, it
 adds #defines to user.hpp.  Presumably Boost Config does something
similar,
 correct?

Yes, the default user.hpp does nothing and delegates everything to to the
boost.config system, ultimately they should both end up setting the same
options allbeit by different means.

 If these defines were just for boost implementation details/optimization
it
 wouldn't concern me, but it seems as though in some cases they change the
 way Boost will interact with my program (e.g., shared_ptr and thread
safety).

Threading support is on when BOOST_HAS_THREADS is defined, and off when it's
not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of
these mentioned in the configure generated user.hpp (and in the config
docs).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Boost.Regex compilation errors with BCB5

[John Maddock]

 and I don't get an error. Are you using any particular compiler setting?.
(I
 am just creating a new Console Project in the IDE and then pasting in the
 code.) Maybe there is more to this?

Make sure that the console app has Project uses the VCL checked when you
create it.  Haven't tried without it... I'm using the 5.6.4 compiler BTW.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 1.30.0-1.30.2: no more thread support for Linux?

[John Maddock]

 IMHO it's not requirement to use -pthread on linux - especially when it's
 not documented. I think usage of -D_REENTRANT for compiling and -lpthread
 for linking should be enough.

Maybe - I don't have a linux box to check on right now - doing a:

 g++ -dumpspecs | grep thread 

will tell you what -pthread does on your system.

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: memcpy_copyable and memcpy_moveable type traits

[John Maddock]

  Thats my point - you may flag some types as safely moveable and then
  use
  this knowledge in algorithms. User has the responsibility to do the
  decision.

 Extremely dangerous and error prone. I can't even imagine a non-POD type
 where flagging it for memcpy_copyable and memcpy_moveable can be right.
Can
 you give an example ?

 Also, flagging it introduces some more complication on the user's part.
 How would you propose the user do this ?

He needs to take a look at the has_trivial_* traits:

has_trivial_assign is roughly equivalent to memcpy_copyable

I guess there is no equivalent to memcpy_moveable: but it looks rather
dangerous, what state is the original object left in afterwards etc?  In any
case there is another promising approach to moveable objects proposed for
the next standard
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: memcpy_copyable and memcpy_moveable type traits

[John Maddock]

 see boost::is_POD.

And has_trivial_copy has_trivial_assign has_trivial_destruct etc

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost.Regex compiler warnings

[John Maddock]

 Compilation of Boost.Regex using Borland C++ 5.5 currently gives a bunch
of
 previous options and warnings not restored messages. The culprit is
 boost/regex/config/cstring.hpp where the lines

Fixes are in cvs now.

Thanks for reporting this.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost.Regex compilation errors with BCB5

[John Maddock]

 At the moment, Boost.Regex has an incompatibility with the VCL headers
when
 compiling with Borland C++ 5.5. Simply having

 #include vcl.h
 #include boost\regex.hpp

 generates a large number of errors of the type.

 [C++ Error] cregex.hpp(91): E2015 Ambiguity between '_fastcall operator
 |(int,const Variant )' and '|'

 I'm afraid that I have yet to track down the precise cause of the errors,
or
 a solution.

I can reproduce this with just:

#include vcl.h
#include locale

No boost code necessary :-(

Even worse this reproduces the error as well:

#include vcl.h
#pragma hdrstop

enum enum_t
{
   one = 1,
   two = 2
};

int test()
{
   int a = one | two;  // error
   int b = one + two;  // error
   int c = (int)one  (int)two; // OK
   return a  b;   // OK
}

which doesn't look good at all...

Oh and the problem is present in Builder 6 as well.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] boost 1.30.2 thread support issue under cygwin

[John Maddock]

  From the g++ man pages, -mthreads Support thread-safe exception handling
 on Mingw32 and only defines _MT for Mingw32. Therefore, after threading
 support is disabled on line 53 of boost/config/compiler/gcc.hpp, nothing
 actually enables it again for a non-Mingw32 cygwin build. Is this the
 desired behaviour? (If I removed the check for __CYGWIN__ in gcc.hpp,
 everything compiles and the tests seem to run correctly).

No it's not desired - boost/config/suffix.hpp checks for _MT and turns
threading support on when it finds it, however, when I build the following
program with the -mthreads option I see the #error triggered:

#ifndef _MT
#error oops
#endif

Looking further into the specs file it seems that _MT is only defined if you
use both -mno-cygwin and -mthreads, cygwin itself appears to no longer set
any define in multi-threading mode, so I guess we're back to setting
BOOST_HAS_THREADS unconditionally for that compiler :-(

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 1.30.0-1.30.2: no more thread support for Linux?

[John Maddock]

 One more thing: what exactly can go wrong with 1.30.0 if
 -pthread isn't used? Is it boost specific or a general thing
 (e.g. issues w/ respect to libstdc++)?

A general thing - without this then:

 Your std lib is not thread safe.
 Your C lib is not thread safe.
 g++ will not emit thread safe exception handling code.

Thus while for C programs enabling thread support is just a question of
linking to the right libraries, for C++ you also need to ensure that the
compiler knows that you want thread safe code.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc

[John Maddock]

  My understanding is that Boost.Config should take care about these
issues.
  Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in
  case if there is no support for POSIX interfaces. Could you report the
value
  of that flag in case of compilation failures you are expiriencing.

 BOOST_HAS_SIGACTION gets defined to an empty string
 for como, gcc -ansi -U_GNU_SOURCE and for icc -D__STRICT_ANSI__.

 Boost.Config uses _POSIX_VERSION to determine wether sigaction()
 is available. The presence of _POSIX_VERSION doesn't indicate
 wether the POSIX API has actually been enabled.

 If we want to use Boost.Config to take care of this then
 Boost.Config also has to check wether POSIX has been enabled.
 This would be a very tedious task. glibc uses a plethora of
 flags to enable POSIX, other implementations probably will
 also add some flags.

My gut feeling is that checking for _POSIX_C_SOURCE would probably be the
standard conforming way to handle this, but is likely to break on some
systems.

Could we not just add define_POSIX_C_SOURCE=200112 to the test library's
requirements?

On the other hand, I notice that the requirement to specify this, is only
for conforming C applications, nothing is mentioned about other languages
(if we're being picky about this).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [regex] Escaping a search string?

[John Maddock]

Given that I have a string 's' from somewhere, I'd like to create a
regular expression where some part must match that string. The problem
is, the 's' could contain characters that have a special meaning in
regular expressions. Is there some support function that can provide an
escaped version of 's'? Something that transforms my.*string into
my\.\*string? If there isn't, would it be possible/easy to provide one?

Good question, no there isn't, but how about:

std::string escape_regex(const std::string s)
{
static const std::regex e([\\[\\]$\\^|.+*?(){}]);
return regex_merge(s, e, $);
}

Just off the top of my head and untried

I'll try and think up something more general that works with all the flag
settings though...

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] config, workaround of bug in variant's compiler bugworkaround on gcc

[John Maddock]

 I think problem is with BOOST_EXPLICIT_TEMPLATE_TYPE(void)
 Simply removing that workaround macro from forced_return works for me as a
 dirty workaround.

 The question is, why BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS on gcc
 3.2.x? config/compiler/gcc.hpp comments about some unspecified bug, while
 documentation says only about VC6. The same bug in both compilers?
Strange.

Kind of - the extended test case is in
libs/config/test/boost_no_exp_func_tem_arg.cxx

 Diving more in config, little of compiler specific code pollutes
 config/suffix.hpp, shouldnt it go to compiler specific config instead?

Everything in suffix.hpp is generic macro workarounds - it's not dependent
upon specific compilers just whether the appropriate macro is defined.

I think you are going to have to use a dirty workaround here: check for gcc
before using BOOST_EXPLICIT_TEMPLATE_TYPE(void)
 in this particular case.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Release date? (was the boost::signal sample crashes)

[John Maddock]

 I'm not sure how to proceed with this so if there is anything I can do
 in the meantime, let me know.  Feel free to e-mail me off the list.

OK, I've got this working pretty well with regex - but as it entails changes
to boost.config I'm not sure if I should make the changes now or wait until
after the next release - Beman I guess we have a couple of weeks still to
run yes?

[ Footnote - on second thoughts it just means moving code that's in
boost.regex now into the central config system it's not new code - so maybe
I should go ahead ]

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Metaprogramming question

[John Maddock]

 See boost/mpl/aux_/has_xxx.hpp.  Example usage in
boost/detail/iterator.hpp.

Thanks, I'll look into it.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Metaprogramming question

[John Maddock]

I'm trying to remember, did someone around here come up with some code that
can tell at compiler time whether an object has a specific member or not, I
can do it for operators, but not a member typedef (which is what I want)...

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Release of 1.30.2 imminent

[John Maddock]

 NOTICE:

 If I don't hear of any new problems with the RC_1_30_0 branch I'm
 going to release 1.30.2 tomorrow (Wed) evening or Thursday morning.

Then be aware that I've just merged a few select config changes into the
RC_1_30_0 branch to fix the linux regressions you reported (and bring a few
other config headers up to date to cope with new compiler/platform releases
etc).  If this can make into the release it would be a good thing IMO.

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: the boost::signal sample crashes

[John Maddock]

 I'm not sure how to proceed with this so if there is anything I can do
 in the meantime, let me know.  Feel free to e-mail me off the list.

ABI prefix and suffix headers are now in cvs, as is
boost/config/auto_link.hpp for selecting link libraries - for now refer to
the header for usage, I'll add this to the config docs in due course, but
lets get it running through the regression tests first...

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Release of 1.30.2 imminent

[John Maddock]

  The link failures for the format tests and the ios_state_test likely
  isn't an indication of a problem in the respective libraries.


 I was in  holidays, sorry I did not respond earlier.

 I gave a look at the regression reports, and indeed the pthread linking
 problem must be rather unrelated to the code itself in format, which
 doesnt call any thread function.

 I suspect it's because the tests are linked statically (because of wchar
 issues whith some compiler), and it triggers something.

 Does anyone have a clue on what to do to fix this ?

Very likely you are using something like shared_ptr or regex that make
themselves thread safe when BOOST_HAS_THREADS is defined, if this is the
case then adding either:

defineBOOST_DISABLE_THREADS=1

or

threadingmulti

To the build requirements of the test will fix that.

If you don't depend on any boost lib that uses threads, then I would guess
that the culprit would be the std lib used (probably synchronises it's
iostream code somewhere), in which case you're going to need to use the
second option above.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Release of 1.30.2 imminent

[John Maddock]

 Just out of curiosity. What the heck is librt?

It contains the POSIX realtime feature set (used by boost.threads, and hence
tested by boost.config for timeouts and thread priorities and the like).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] boost/math octonion/quaternion failures?

[John Maddock]

 Current GCC and Intel compilers don't appear to allow using declarations
at
 function scope, according to a bug report.

Also Borland's compiler crashes if there are using declarations inside a
function that will be expanded inline if memory serves.

 Is there any reason not to just move the using declarations to namespace
 scope?

 Answering my own queston, I think prefer the solution used in other boost
 code where calls to say std::abs are explicitly qualified, and ifdef
 BOOST_NO_STDC_NAMESPACE then namespace std { using ::abs; } is supplied.

 What are the pros and cons of the different approaches?

Personally I prefer,  namespace std { using ::abs; } approach, however this
can cause overload ambiguities on vc6 (but this is legacy support now
right?), likewise mixing the two approaches with the same function name
messes up vc6 (overload ambiguities again).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] MSVC7.1 bug not yet fixed

[John Maddock]

 I've just downloaded 1.30.1 and the bug I reported a while ago

 http://aspn.activestate.com/ASPN/Mail/Message/boost/1622190
 (Missing BOOST_HAS_THREADS on MSVC with /Za and /MT)

 is still there. I don't know config at all but if nobody else has time
I'll
 try to submit a patch (I believe it'd be less than half an hour for
someone
 knowing config). Just let me know.

I'm pretty sure that I fixed that in the main branch, I'm not sure what
changes would need to be merged into the release branch though, I'll try and
look into it.

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: the boost::signal sample crashes

[John Maddock]

 So John, would you be interested in trying to get this sorted out for
 the next release?  As I have said, I currenly only use BCB, and so can't
 offer much help for other compilers.

Yep.

 Would it be best to have something like a  boost/config/preinclude.hpp
 file which includes a compiler specific pre-include and then a
 boost/config/postinclude.hpp for afters?

I'm wondering how complicated to make this - one option would be to do
something a little like the config system does and have:

#ifdef BOOST_ABI_INCLUDE
#include BOOST_ABI_PREFIX
#endif

// code...

#ifdef BOOST_ABI_INCLUDE
#include BOOST_ABI_SUFFIX
#endif

which would let users define their own prefix/suffix headers if they want
to.

 I've created ones for BCB which I use here, that simply do

 #praga nopushoptwarn
 #pragma option push -a8 -b -Vx -Ve -pc -w-8027

 for pre and

 #pragma nopushoptwarn
 #pragma option pop

 for post (probably don't need the nopushoptwarn in postinclude though).

Yep.

 These options are from regex.  I may be a better idea not to include
 disabling warnings in the default boost options?

Some of those warnings can get pretty pesky at times

 And also, It might be
 worth adding -Vg- to disable codeguard for boost, unless the new build
 system will build CodeGuard libraries as well as non-cg enabled libraries.

Does adding codeguard info break the ABI?  I didn't think it did so (there
are no codeguard protected std libraries for example), and I mix and match
codeguard and non-codeguard code all the time without any apparent issues...

Here's what the STLPort that Borland ship is using:

#  pragma option
push -Vx- -Ve- -a8 -b -pc -w-inl -w-aus -w-sig -w-8062 -w-8041 -w-8008 -w-80
12 -w-8027 -w-8057 -w-8091 -w-8092 -w-8066

 These options also should be the same as the default jam options for the
 compiler also.

Yes, that should be the case now I think.

I'm slightly tied up this week, but I'll try and add something to regex and
see how it looks.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: libs/config/configure screwed up in DOS format in1.30.1

[John Maddock]

 Fixed now.  I wonder if it really ought to be checked in as binary so
 this doesn't happen?

Personally I think that would cause even more problems (for me at least),
note that there are plenty of other files that need the \r's stripping in
order for them to work on Unix, in fact some pre-processors (some versions
of gcc for example) can't even cope with \r's in header files (if there's a
\r between a \ and a \n).

The only complete solution is to make sure that all text files have their
\r's stripped before producing the tar.gz file.

[ footnote - one way to do this is with the new bcp tool - something like:

bcp --boost=boost-path --unix-lines --cvs . destination-path

will produce a clean copy of all of the boost cvs with \r's stripped from
text files - we could probably even write a Jamfile that would automate the
release process come to that. -- end footnote ]

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] ABI fixing and prefix/suffix headers (was the boost::signal sample crashes)

[John Maddock]

 The main problem with shared_ptr 1.30.x and below is that the single- and
 multithreaded versions are incompatible. The CVS version is now binary
 compatible on Windows, so 1.31 will work across different threading
 models; still, the correct default for Borland should probably be to do a
 multithreaded build.

 By the way, this can't be fixed with prefix/suffix headers.

Agreed, no-one is trying to fix that - threaded and non-threaded builds use
different run time libraries for both the Microsoft and Borland compilers -
mixing code that was built with threading turned on with code where it is
turned off will *always* cause ODR violations, even if you're not using
boost :-)

  but by default the libraries are all built using
  the default compiler option for the tool.  The inlined (header-only)
  library are only tested against that default set, so why not enforce
  that default set for all boost libraries?  If an individual library
  author then wants to enforce another set (different alignment or
  something) for optimisation purposes, then let then over-ride the
  defaults,

 But I don't want to enforce a set. I want (for example) shared_ptr to use
 whatever set the user has specified and not to override his settings.

Which causes no end of issues for libraries with separate source, unless we
abandon having a build system altogether and just tell people to build
everything yourself.

To put this in perspective for C++ Builder the following options effect the
ABI:

-b (on or off - effect emum sizes)
-Vx  (on or off - empty members)
-Ve (on or off - empty base classes)
-aX (alignment - 5 options).
-pX (Calling convention - 4 options)
-Vmx (member pointer size and layout - 5 options)
-VC (on or off, changes name mangling)
-Vl (on or off, changes struct layout).

In addition, there are a whole bunch of separate runtime libraries - 4 C
libraries, plus 2 STLPort versions on top (so 8 combinations).  And that's
not counting the optional diagnostic libraries or the optional use of Rogue
Waves STL.

So assuming we build libraries for the 8 runtime variants we can't control,
that still leaves 2*2*2*5*4*5*2*2=3200!!! ABI options for each runtime
variant.  Seriously we need to get a handle on this where we can - and
please don't forget users can always turn this off if they want to handle
the ABI themselves.

One final point - there was a reason that I moved regex to use automatic
library selection and ABI fixing - without it I was getting a tonne of
support requests along the lines of Your library doesn't work, it just
crashes when I call anything, which almost always turned out to be caused
by ODR violations (either the user had changed an ABI option, or had linked
to the wrong runtime-library-build variant), these basically stopped
overnight once I modified my code to stop those (this was all in pre-boost
days BTW).

Convinced yet?

John.




___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: [regex] Escaping a search string?

[John Maddock]

 Front end localization could change this also, I believe. For instance if
a
 dll or message catalog substitutes '!' for '$' wouldn't I need to escape
'!'
 instead of '$' in order to use '!' as a literal in an expression ?

Yes, I was afraid you would bring that up :-)

 In this regard it would be helpful if the end-user could obtain back at
 run-time the substitutions that are made due to localization. I didn't see
 this as a function of the regex_traits class reference but maybe it is
 there.

No it's not - the internal data simply isn't structured in a way that allows
that kind of query - however as you yourself said already - the end user
*knows* what the special characters are (if they have been changed).

The worst case scenario: the user has substituted a traits class that uses
different characters for the \ x { and } regular characters, so that escape
sequences like: \x{32} don't work anymore.

John


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: the boost::signal sample crashes

[John Maddock]

 Does regex address the issue of alignment and calling convention etc and
 other options (in BCB, treat enums as ints is a good one to screw up
 libraries) by wrapping the headers in push/pop option statements?

Yes:

#ifdef __BORLANDC__
#  pragma option push -a8 -b -Vx -Ve -pc -w-8027
#endif

// code here

#ifdef __BORLANDC__
#  pragma option pop
#endif

We should standardize this boost-wide really in some kind of prefix/suffix
header.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] C++ Builder 6 and Boost Generic Graph Library

[John Maddock]

 awhile ago I tried to compile this simple program:

 #includeboost/graph/adjacency_list.hpp

 int main (){

return 0;
 }


 and Borland C++ Builder 6 refuse to compile.
 I have track the problem and it seemed that Borland C++ builder has
problem with template partial specialization with constant. The program
below also refuse to compile

Yep, we even have a macro for it: BOOST_NO_CV_SPECIALIZATIONS, evidently
boost.graph doesn't use it.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Preparing 1.30.1 Release

[John Maddock]

I've applied the first two; I'm not comfortable applying the regex
patches myself; it takes someone who knows the library to verify that
they're OK.  John can do it, though, as far as I'm concerned.

done,

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Preparing 1.30.1 Release

[John Maddock]

 I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
 at http://www.boost-consulting.com/diffs-1-30-1.txt.  These will be
 the changes that go into the Boost 1.30.1 release.  Will the
 authors/maintainers of the following libraries please post a brief
 summary of the fixes that were applied?

 smart_ptr
 lexical_cast
 function
 lambda
 MPL
 type_traits

The one type_traits change is hardly worth mentioning - it just updates the
EDG version number for which a specific fix is required (is_base_and_derived
fix for EDG versions prior to 243).

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and gcc

[John Maddock]

I've just written the following. It (correctly) fails for MSVC 6.5 and gcc
3.2 for
cygwin,
but I cannot test it in a conforming compiler.

I had to modify it a little to make it conforming code, but it's now in cvs.

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Today's compiler checks

[John Maddock]

   don't know how to make
libs!regex!testconfig_info/regex_config_info.cpp
   don't know how to make libs!regex!testconcepts/concept_check.cpp
   don't know how to make libs!regex!testconcepts/wide_concept_check.cpp

 Any ideas how this got broken?

You need to do a cvs update with the -d option to get the new directories
I've added...

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and gcc

[John Maddock]

Currently, BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
is not defined for gcc. However, the following URL in the gcc bug
database

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7676

leads me to believe that the macro should be set on for the appropriate
versions of gcc. Matter of fact, I run with this problem myself and it
can be
workedaround with techniques similar to those employed for MSVC. See
for instance definitions of get() and workaround_holder in

boost/tuple/detail/tuple_basic_no_partial_spec.hpp


Thanks,

The issue with gcc seems to be a little more specific than we normally set
the macro for, but I don't see any reason why we shouldn't set it.  Am I
right in thinking that this is specific to gcc 3.1 and 3.2?  Also do you
have a test case that can be added to the appropriate config test?

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Recursive_mutex bug?

[John Maddock]

 I caught a memory leak (24 bytes) when using recursive_mutex class in
 Solaris 8.
 This class initializes a pthread_mutexattr attribute but never destroys it
 thus
 leaving the leak.
 We use tons of the recursive mutexes in our huge app and that leak leads
 to significant memory loss.

That does look like a bug... Bill?

John Maddock.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost Bibliography?

[John Maddock]

 Attached is a quick draft of a Boost Bibliography page. Each entry is
 bookmarked so it can be referenced directly from other web pages.

 Comments?

A good idea, can you add to that the article in
libs/type_traits/c++_type_traits.htm which was in the October 2000 issue of
Dr Dobb's Journal, I don't have an issue number to hand though.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] problems with config for intel-7.1 on Linux

[John Maddock]

 I found a problem with the intel configuration for Linux.
 For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
 gets defined although the compiler has an intrinsic wchar_t.

 Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
 defined on Linux. __WCHAR_TYPE__ is defined to int. Never-
 theless, wchar_t and int are distinct types.

Looking at the boost regression test results, it seems that Intel on linux
defines _WCHAR_T (which is what the EDG front-end documentation specifies
for wchar_t support), so I used that as the test - should be in cvs now -
can you check that it does the right thing?

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Borland-tools.jam

[John Maddock]

Dave,

Is there any reason for including the wide-character-support option in the
Borland toolset: this is set to on by default in features jam, and then
selectively turned off for borland, this means that if I inherit a toolset
from borland-tools.jam (I want multiple toolsets to test different Borland
versions) then it gets turned on again in the inherited toolset and nothing
compiles anymore.

BTW this option should *not* be turned on by default - the effect of -WU is
to make the linker look for a Unicode entrypoint:

int wmain(int argc, wchar_t** argv);

and since no boost code uses such an entry point this is obviously a
mistake.  Also since only borland-tools.jam provides this option, I think we
can just remove all reference to it (or at the very least rename it to
something more suitable and turn it off by default in features.jam).

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] regex documentation bug

[John Maddock]

 http://www.boost.org/libs/regex/template_class_ref.htm#partial_matches
 
 There are two examples given.  Though the examples are different, in
 both cases, the example links to a complete implementation of the
 first example.  This likely was a cut-and-paste error.

Thanks, fixed in cvs,

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: boost::regex opeartor+= bug report

[John Maddock]

 I believe that consistent use of std::advance would solve the problem.
 Or would this change be so costly that I ought to use vector or deque?
 Unfortunately, doing so would cause me other problems such as iterator
 invalidation. :-/

Should be fixed in cvs now.

Thanks for the report,

John Maddock

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Experimental audience-targeted regression results

[John Maddock]

 Well, we didn't do anything special to mis-configure it ;), besides
 choosing MSVC 6 compatibility mode (during the setup, as opposite to
 MSVC 7.0 one). Any ideas what's the right way to fix that?

The problem is that there is no way for the config system to tell how your
Intel compiler is set up, and which conformance options have been set
(because Intel doesn't define any macros to indicate which options have been
enabled/disabled), so... you basically have to set up boost.config manually
to match your compiler options.  On unix platforms running the configure
script would do that, but that's a little tricky on win32 :-(

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Trouble building latest CVS (Intel 7.1 and VC7)

[John Maddock]

 I just checked out the latest CVS and I am having trouble building it.
 My environment is:

 - Windows XP
 - Intel Version 7.1, Build 20030402Z
 - Visual C++ 7.0

 All my environment variables are setup correctly (INCLUDE, LIB, MSVCDIR,
 INTEL_PATH, PATH). The command line I am using with bjam is:

 bjam -sTOOLS=intel-win32 -sINTEL_BASE_MSVC_TOOLSET=vc7
 -sPYTHON_ROOT=C:\Python

 Looking at the command line that bjam is executing to compile the files,
 it seems to be all right (paths to header files, the correct compiler,
etc).

 This error happens in a lot of files, besides numeric.cpp. I let it try
 to compile more 6 files before I gave up, since something is obviously
 wrong. If needed, I can post the list of files that are giving this error.

 Does anybody know what am I doing wrong?

It looks like the config system is assuming that wchar_t is a native type,
but that it isn't being turned on in the compiler - perhaps a boost.build
expert can jump in here

John


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Managing boost licenses

[John Maddock]

I've modified the bcp tool to add a --report mode which will report all the
licenses in effect for a set of boost files, for example:

bcp --report scoped_ptr.hpp scoped-ptr-report.html

will report:

* All the licences in effect.
* All the authors using each license.
* All the copyright holders using each license.
* Any files with no recognized copyright holder or license.
* All the authors and the files they are responsible for.
* The dependency information for each file found (which is to say the reason
for including each file as a dependency).

There are a couple of examples of the program output here:

http://www.regex.fsnet.co.uk/scoped_ptr.html
http://www.regex.fsnet.co.uk/regex.html

The source is in cvs now, or available from here:

http://www.regex.fsnet.co.uk/bcp.zip

as is a win32 executable:

http://www.regex.fsnet.co.uk/bcp_win32.zip

If the folks that have been having trouble with boost licenses could take a
look and see if this helps smooth their problems out I would appreciate it.

Regards,

John Maddock.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Filesystem problem

[John Maddock]

 Comments?

Sounds reasonably to me, but I admit that I don't really understand POSIX
filesystems.  I guess what I really wanted was something that would be
equivalent to rm -f file, remember that we already have the equivalent to
rm -r path.  Of course I don't know how one would implement that :-)

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Comments on the bcp tool

[John Maddock]

 Except for one problem. If the second run of bcp selects less files than
 the first, and you only ovewrite files, not clean up the entire directory,
 the number of files will not be reduced. Uncessasary ones will just lay in
 the directory.

Good point, however I've sometimes used it that way deliberately (if I've
forgotten something), even so it has a problem with overwriting read only
files (boost.filesystem won't let you do that).


 :-(
 I start to understand why Gennadiy Rozental was saying that dependency
from
 program_options to function is a bit too much --- don't feel all that good
 about adding 2Megs just for command line parsing. Of course, this only
 matters when packaging library separately.

Agreed - it's not quite 2Megs though: 1.39Mb on disk, and zips up to 235K,
even so...

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Comments on the bcp tool

[John Maddock]

   However, it seems to be confused by the preprocessor library.
   Since the
   includes sometime have the form:
  
  #include BOOST_PP_ITERATE()
  
   the 'bcp' tool does not find them. For example,
   boost/preprocessor/iteration/detail/iter directory is needed by
   boost/function.hpp but is not included.
 
  Is it overkill to use Wave for this? It would solve the
  mentioned problem by correctly preprocessing the inspected sources.

 Here is the (main) code, which uses Wave to output the file names of all
 successfully opened include files (this needs some filtering to avoid
 double output of the same file):

Interesting, the thing is I need the code to find all possible dependencies,
so that if we have:

#if SOME_MACRO
#include boost/a.hpp
#else
#include boost/b.hpp
#endif

then it should find *both* headers.

Which I don't think a preprocessor will do?

In any case I'm already using regex for other purposes, and boost::function
seems to be the only problematic case so far...

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Comments on the bcp tool

[John Maddock]

 However, it seems to be confused by the preprocessor library. Since the
 includes sometime have the form:

#include BOOST_PP_ITERATE()

 the 'bcp' tool does not find them. For example,
 boost/preprocessor/iteration/detail/iter directory is needed by
 boost/function.hpp but is not included. I've added some explicit
dependencies
 with the attached patch --- can it be applied?

Thanks will fix - I've got a bunch of other really exciting changes comming
(licence scanning) - so the patch may have to wait a few days.

 Another note is on usability. Say I create directory po and find that
some
 files are missing. I tweak bcp source and try again. But attempt to
override
 files fail. I remove po directory. But then bcp says the destination
does
 not exist. It's a bit inconvenient --- maybe destination directory should
be
 created if it does not exist. Or maybe, there should be --overwrite
switch,
 which would simply clean up destination before doing copies.

Or maybe it should just go ahead and overwrite, should be easy to fix.

 And the last note:

bcp --boost=/home/ghost/Work/boost boost/function/function1.hpp
function1

 creates a tree of 1975 kbytes. Hmm, never though there's that many
 dependencies...

Hmm, it seems to pull in more of type_traits than I would have expected, and
that pulls in part of mpl, and then a whole load of the preprocessor
library.  I don't think any given compiler will include half of that, but
which half depends upon which compiler...

John


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Comments on the bcp tool

[John Maddock]

 Anyone got a Win32 exe of bcp that they could email me?

Eventually there probably will be one to download, but it's still developing
quite rapidly at present, I'll mail you a binary build though.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] problems with config for intel-7.1 on Linux

[John Maddock]

 I found a problem with the intel configuration for Linux.
 For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T
 gets defined although the compiler has an intrinsic wchar_t.

 Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is
 defined on Linux. __WCHAR_TYPE__ is defined to int. Never-
 theless, wchar_t and int are distinct types.

 The attached patch to intel.hpp fixes this problem for
 intel 7.1 on Linux. However, I'm not sure wether the change
 is acceptable in this form. I'm also not sure wether
 it causes problems with version 7.0 of the compiler.

We have endless problems with this compiler: basically you can turn wchar_t
support on or off on the command line, but there is no way to detect which
option is used in code.  Is wchar_t supported by default with Intel 7.1 on
linux?  If yes then I guess we should change

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Missing copyright on pending files

[John Maddock]

A large number of files in the boost/pending directory have no licence or
copyright information:

boost/pending/container_traits.hpp
boost/pending/cstddef.hpp
boost/pending/detail/disjoint_sets.hpp
boost/pending/detail/property.hpp
boost/pending/fenced_priority_queue.hpp
boost/pending/fibonacci_heap.hpp
boost/pending/iterator_adaptors.hpp
boost/pending/iterator_tests.hpp
boost/pending/property.hpp
boost/pending/queue.hpp
boost/pending/stringtok.hpp

Any chance of the authors concerned fixing these?

Thanks,

John Maddock.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] no licence or copyright in boost/any.hpp

[John Maddock]

 The license is at the end.

Duh!, apologies, and thanks,

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Licence proliferation (Graph library)

[John Maddock]

 I would not mind to change my copyrights to use different wording --- 
either
 the one from function library or the standard one. The only problem is
 that

boost/graph/transitive_closure.hpp

 is generated from

libs/graph/doc/transitive_closure.w

 and only Jeremy knows how.

 And related note: probably the text of standard license should be placed
 somewhere and you could suggest that standard license to authors which
 used something different, instead for suggesting to use any license
 currently used? Of course, it must be settled what standard is.

I think I probably jumped the gun a little here: there's going to some
discussion around here real soon now about a standard boost licence for
new code.  At present I've been trying to flag up files that have licences
that are *almost* completely identical to common ones used elsewhere in
boost, but which are just different enough to be separate legal entities
(well probably anywayg).  If you want to either hold off any changes for a
while that's completely OK; your existing licence is perfectly boost
compatible, it's just um, well unique.

I'll also try and post a rundown of what licences are actually in use right
now, one I've got my code a bit more complete.

Regards,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] No copyright or licenceinboost/date_time/microsec_time_clock.hpp

[John Maddock]

 Done.

Thanks!

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Managing boost dependencies

[John Maddock]

 Do realize that people are different and that my programming preference is
 almost always to use a GUI interface over command lines as long as the GUI
 interface lets me do what I want to accomplish. Of course I write actual
 code in a fancy editor just like everyone else g. I will dig into the
.pdf
 version of the link first, although my initial reaction to CVS was not
 joyful, but I am sure it can not be that arcane to use.

Check out TortoiseCVS: it integrates with the windows shell and is pretty
much wonderful and easy to use.  It does lack the power features of WinCVS
or the command line, but that can sometimes be a good thing.  One caveat
however: I've never tried to use it in pserver (read only access) mode.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Managing boost dependencies

[John Maddock]

 I don't think it needs to.  We review libraries, but traditionally
 tools are just checked in if they seem useful or are known to be
 needed.  This one is.

OK I'll check it in, thanks.

John.

___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] filesystem::path and ./

[John Maddock]

Beman,

While putting together bcp (see managing boost dependencies thread), I found
that some of the boost html files contain relative URL's of that begin with
./.  In order to get filesystem::path to accept these, I had to manually
strip the ./ off first, so basically this is a plea to let the portable
syntax recognise this, as there does seem to be a genuine need.

Thanks,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost header and library dependency tables

[John Maddock]

 I think it's a good idea. But I have a few comments.

 First, it only handles headers that are directly under 'boost/'. However
 some people have tried not to pollute the root directory and have put
 their libraries in sub-directories. For example, the Graph library, uBlas,
 the Interval library, the mathematical libraries, and so on. And your
 script is unfortunately forgetting them.

I know, I just wasn't sure which needed including.

 Second, the links at the top of the pages don't work with all browsers
 since the anchors are defined in a non-standard way. It shouldn't be a
 name=#boostaligned_storagehpp but a name=boostaligned_storagehpp (no
 sharp sign). With some quotes, it would be even better, but it's another
 problem.

OK, that's an error in the shell script I used, easy enough to hack
around

 Finally, what are library dependencies? Sorry if it's a dumb question.
 But by looking at the results, I don't get the meaning of it.

It's everything that's needed by the complete library - by it's test and
example programs etc as well as the headers - for most libraries this means
that the Boost.test source will be listed as a dependency for example.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] alternative configuration technique

[John Maddock]

 I found that boost has very powerful configuration system
 (boost/config.hpp and around...)
 but why use macros?
 there is another solution described here, let discuss it...
 may be there are some troubles, invisible for me, that prevent from using
 this technique
 in libraries like boost?

I think that there are two problems:

1) Your scheme requires that all possible implementations can be parsed by
the compiler - that won't be true for macros describing defects.
2) Your scheme can't cope with optional features (long long or
someheader.h).

Oh, and macros are probably simpler, if ugly.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Need two new configuration macros

[John Maddock]

 Actually, the problem I have is that GCC extended the copying ban to
 std::basic_streambuf, even though DR 50 only mentions std::ios_base.
 I know that copying stream bases or stream buffers are probably bad
 ideas, but I didn't feel comfortable leaving copy semantics out of my
 subclass's description, especially since I knew the default copy
 semantics would be wrong.  Should I just take the copying code out and
 hope that no one will try copying?  (Remember that copying can be
 attempted, with unknown results, on compilers without DR 50.)  Should I
 explicitly ban copying in my subclass?

Personally I would say yes, is there a good reason for copying stream
buffers (I can't think of one)?  Looks like a grey area of the standard to
me, I don't think that basic_streambuf was supposed to be copyable, but you
never know, I'll check on the std-lib reflector.

 Even if I add explicit non-copying, that is only necessary only if
 stream-buffer copying wasn't already banned in std::basic_streambuf.  I
 would still need a macro to know when to apply my own copying ban.
 (Since GCC added the ban on stream-buffer copying on its own, it's not
 covered by DR 50.  So I can't expect every compiler to eventually do
 that change too.)

If you add a private copy constructor then that will always work, no matter
what the base class does.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Managing boost dependencies

[John Maddock]

Folks,

I've put together a small tool for managing boost dependencies called bcp
(for boost copy).

The bcp utility is a tool for extracting subsets of Boost, it's useful for
Boost authors who want to distribute their library separately from Boost,
and for Boost users who want to distribute a subset of Boost with their
application.

Examples:
~~~

   bcp scoped_ptr /foo

Copies boost/scoped_ptr.hpp and dependencies to /foo.

   bcp boost/regex.hpp /foo

Copies boost/regex.hpp and all dependencies
including the regex source code (in libs/regex/src) and build files (in
libs/regex/build) to /foo.  Does not copy the regex documentation,  test, or
example code.

   bcp regex /foo

Copies the full regex lib (in libs/regex) including
dependencies (such as the boost.test source required by the regex test
programs) to /foo.

   bcp regex config build /foo

Copies the full regex lib (in libs/regex) plus
the config lib (libs/config) and the build system (tools/build) to /foo
including all the dependencies.

Syntax:
~

   bcp --list [options] module-list

Outputs a list of all the files in
module-list including dependencies.

   bcp [options] module-list output-path

Copies all the files found in
module-list to output-path

Options:
~~

   --boost=path

Sets the location of the boost tree to path.

   --scan

Treats the module list as a list of (probably non-boost) files to scan
for boost dependencies, the files listed in the module list are not copied
(or listed), only the boost files upon which they depend.

   --cvs

Only copy files under cvs version control.

   --unix-lines

Make sure that all copied files use Unix style line endings.

module-list:


When the --scan option is not used then a list of boost files or library
names to copy, this can be:

  1.. The name of a tool: for example build will find tools/build.
  2.. The name of a library: for example regex.
  3.. The title of a header: for example scoped_ptr will find
boost/scoped_ptr.hpp.
  4.. The name of a header: for example scoped_ptr.hpp will find
boost/scoped_ptr.hpp.
  5.. The name of a file: for example boost/regex.hpp.

When the --scan option is used, then a list of (probably non-boost) files to
scan for boost dependencies, the files in the module list are not therefore
copied/listed.

output-path:


The path to which files will be copied (this path must exist).

Dependencies

File dependencies are found as follows:

C++ source files are scanned for #includes, all #includes present in the
boost source tree will then be scanned for their dependencies and so on.

C++ source files are associated with the name of a library, if that library
has source code (and possibly build data), then include that source in the
dependencies.

C++ source files are checked for dependencies on Boost.test (for example to
see if they use cpp_main as an entry point).

HTML files are scanned for immediate dependencies (images and style sheets,
but not links).

~

As usual comments etc are most welcome, also should a utility/tool such as
this go through the review process, before eventually living under
tools/bcp?

The source is available from: www.regex.fsnet.co.uk/bcp.zip

This requires the latest boost cvs source to build, so there is also a file
containing bcp's dependencies (obviously produced using bcp!):
www.regex.fsnet.co.uk/bcp_deps.zip

Regards,

John Maddock.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Boost header and library dependency tables

[John Maddock]

A while ago Beman produced header dependency tables, unfortunately these
began to get rather complicated and so were dropped, I've placed some
alternative tables here:

Boost header dependencies:
http://www.regex.fsnet.co.uk/header_dependencies.html
Boost library dependencies:
http://www.regex.fsnet.co.uk/library_dependencies.html

Whether these are actually any better than what we had before is
questionable, but the information might prove useful to some.

BTW these tables are produced using bcp in list mode (see separate thread).

Regards,

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] MSVC 6 build problem

[John Maddock]

 I am a newbie to boost, and I don't know if this issue has been addressed.

 I am trying to build the boost libraries on a Win2k machine with MSVC++ 6
 installed, so I downloaded bjam, added it to the path, added the boost
 libraries path to the include path and started the build with the command
 bjam -sTOOLS=msvc, and here is what I am getting:

I suspect that bjam can't find your visual studio installation: try running
the vcvars32.bat file (provided by Microsoft) to set your environment up,
before running bjam.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Need two new configuration macros

[John Maddock]

 I see the need for two new configuration macros.  The need popped up
 when I was trying to add a copy constructor to a stream buffer template
 class (for completeness) but GCC blocked it.

 The std::basic_streambuf class template and the std::ios_base class
 don't mention any copying semantics in the standard.  This means that
 they automatically get a copy constructor.  However, DR 50 suggests
 that std::ios_base shouldn't be copyable.  (I think the reason was
 unclear semantics, and that all its derived types are non-copyable.)
 Recent versions of GCC block copying in ios_base, and they did the same
 to basic_streambuf.  (The latter was a side-effect; if everything else
 was non-copyable, why bother with copyable stream buffers.)

 So now, we need macros to detect environments that implement DR 50.  We
 need two macros because only ios_base is directly involved, the
 treatment of basic_streambuf is an optional bonus.  From someone
 involved on GCC, he _thinks_ that the change happened in GCC 3.1, but
 may have happened earlier.

 How would we express this macro?  Right now, I'm blocking my problem
 code with

 #if !defined(__GNUC__) || (__GNUC__  3) || ((__GNUC__ == 3) 
 (__GNUC_MINOR__  1))

 Any GCC experts here could correct, either in form, or the exact
 version the change happened.  We also need to know if any other
 compilers have added this change.

Hold on a minute: DR50 makes it clear that this was an oversight - you
should *never ever* try to copy a stream object (or base class) - libraries
that don't explicitly implement DR50 are still likely to be non-copyable (or
at least invoke inconsistent or undefined behaviour) even if the copy
constructor isn't explicitly private.  In short you should always assume
that DR50 is in effect and that the copy constructor for ios_base is either
private or else not capable of being created.

John.


___
Unsubscribe  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost