Hi Phil and Mathias,
I completely appreciate the portability issues involved in making such
an extension in which case it has to come with a portability clause
and disclaimer which would become a deterrent in including such a
facility in the library.
However, I thought of your suggested extension of threadpool class
exploiting processor affinity techniques and it sounds very
interesting as well but I guess we would run into the same portability
issues with regard to availability of the lower level API exposing the
hooks to be able to develop such a facility. Another issue would be to
qualify and justify how much improvement would this type of
parallelism enable on top of the instruction level parallelism already
in place for all modern processors. Although, I would still like to
find out if you have any concrete lead in mind.
I know for sure that there are those hard engineering problems in high
performance computing domain to ensure QOS guarantees to distributed
real-time embedded systems. They look into processor utilization
optimizations in the face of uncertainty of computational load on the
system. These usually require some kind of mathematical validation of
the scheme for the system under construction. I guess that would be
beyond the scope of the GSOC project, given the time frame.
M:N type of models would also have the same portability issue as it
requires changing kernel code as well as the userland code in thread
library.
Please let me know if you can think of a any non trivial portable
addition that you can think of an I can work on it. In fact, I don't
mind doing a big project even if it goes beyond the time frame of GSOC
if we can see value in it. Please let me know.
Thanks,
Indradip.
____________________________________________________________________________
Hi Indradip,
I have previously looked at passing POSIX thread attributes (i.e.
priority and policy) and it's not much work; presumably it could now be
done using the native handle in the proposed std::thread and new
version of boost::thread. How close to the POSIX semantics does
Windows come? Boost generally prefers to implement portable stuff
(although that's not something I need!) and choosing to work in an area
where the different platforms have little common ground will make
things more difficult for you, unless you're already familiar with how
this stuff works on both POSIX and Windows systems.
Beyond that there's the area of processor affinity, where as far as I
know POSIX has nothing to say. Linux has some APIs for this but I
doubt they have much in common with any other platforms. Maybe the
Intel TBB library has already solved all of this?
I'm wondering how something like a thread pool would be extended to
exploit processor affinity, if the lower-level API offered it.
Do you have a motivating application?
Phil.
On Tue, Mar 24, 2009 at 5:09 AM, <boost-request@lists.boost.org> wrote:
Send Boost mailing list submissions to
boost@lists.boost.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.boost.org/mailman/listinfo.cgi/boost
or, via email, send a message with subject or body 'help' to
boost-request@lists.boost.org
You can reach the person managing the list at
boost-owner@lists.boost.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Boost digest..."
The boost archives may be found at: http://lists.boost.org/MailArchives/boost/
Today's Topics:
1. Re: Re quest interest in Bloom filters (Phil Endecott)
2. [asio] basic_datagram_socket::send_to (Miroslav Berani? ml.)
3. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Simonson, Lucanus J)
4. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Sebastian Redl)
5. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Simonson, Lucanus J)
6. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Sebastian Redl)
7. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Simonson, Lucanus J)
8. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Schrader, Glenn)
9. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Mathias Gaunard)
10. [GSOC] 10 Day student application period begins today
(troy d. straszheim)
11. Re: How to build 32 bits boost library on a 64 bits platform
(Qihong Wang)
12. Re: "[gsoc] Thread scheduler support for boost" (Phil Endecott)
13. [interprocess] locked mutex and process killed (vicente.botet)
14. Re: "[gsoc] Thread scheduler support for boost" (Mathias Gaunard)
15. has_operator_new (Robert Ramey)
16. BOOST_NO_INTRINSIC_INT64_T (Robert Ramey)
17. Re: Can a Boost library use a component like GMP and mfpr
that have a LGPL license ? (Barend Gehrels)
18. Boost with ICU on AIX - Patch (solar@rootdirectory.de)
19. Re: has_operator_new (John Maddock)
20. Re: [interprocess] locked mutex and process killed (Edouard A.)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Mar 2009 16:15:01 +0000
From: "Phil Endecott" <spam_from_boost_dev@chezphil.org>
Subject: Re: [boost] Re quest interest in Bloom filters
To: <boost@lists.boost.org>
Message-ID: <1237824901397@dmwebmail.dmwebmail.chezphil.org>
Content-Type: text/plain; format="flowed"
Vicente Botet Escriba wrote:
Phil Endecott-48 wrote:
vicente.botet wrote:
I need for my application bloom filters. Do you know of a good boostified
generic implementation?
Is there any interest in such a generic bloom filters library in Boost?
Hi Vicente,
I have a simple generic Bloom filter here:
http://svn.chezphil.org/libpbe/trunk/include/bloom_filter.hh
I seem to have lost the example code
Now found and checked in here:
http://svn.chezphil.org/libpbe/trunk/examples/spellcheck.cc
The hard part (the hash functions) is left out quite elegantly. I was
thinking about defining some hash traits wich will allow the user to set the
hash functions in a independent way. Something like
template <template T, size_t N> struct hash_traits;
template <> hash_traits<SpecificUserType,0> {
static unsigned hash(T& value) {
// specific code
}
}
BTW, besides the tr1::hash function, are there other hash generic functions
in Boost?
You can use Boost.CRC. What sort of key do you have? I once did some
investigation of hash functions for strings for use with unordered
containers; I was considering using a degenerate hash that only looks
at the first N characters.
Something I didn't mention before is that if you need, say, 10-bit hash
values then a 32-bit CRC could give you three of them. In this case
your hash_traits would presumably compute the same CRC three times and
extract different portions each time, which is not ideal.
I would need also the union and intersection functions. I'm wondering if
replacing the tr1::array by a boost::dynamic_bitset should make eassier
this.
Well it's not exactly difficult with the array. I've never used
dynamic_bitset and being dynamic is not a requirement here. I was
concerned (as normal) about getting a fast implementation and the
simple bit manipulation in my code is probably about as fast as you can get.
Cheers, Phil.
------------------------------
Message: 2
Date: Mon, 23 Mar 2009 17:54:14 +0100
From: Miroslav Berani? ml. <miroslav.beranic@mibesis.si>
Subject: [boost] [asio] basic_datagram_socket::send_to
To: boost@lists.boost.org
Message-ID:
<c62cccb70903230954g7020c4c0w30664ae62556b6f@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Greetings,
will method basic_datagram_socket::send_to flush data immediately to
the endpoint or will first fill its internal buffer and than flush
data to endpoint? I would like to make sure, data gets flushed to
endpoint when this method is called.
Is there any other way to flush data to endpoint?
Does any socket::set_option(option); makes difference to behaviour of
send_to method ?
Why isn't it possible to set buffer size lower than 1024 (low-level
restriction?), with method (basic_datagram_socket::send_buffer_size())
There is no documentation about this.
Best regards,
-----
Miroslav Berani? ml.
------------------------------
Message: 3
Date: Mon, 23 Mar 2009 09:58:20 -0700
From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: "boost@lists.boost.org" <boost@lists.boost.org>
Message-ID:
<26E9B811E137AB4B95200FD4C950886B25DDF48C@orsmsx507.amr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Sebastian Redl wrote:
AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is
no problem in using them in commercial products, even closed source
applications (provided a copy of the license is distributed with
said product), so I don't think there should be any restriction on
allowing Boost libs to depend on LPGL libs.
The LGPL requires you to construct your code in such a way that you
can relink with a new library. It also requires you to allow users
to reverse engineer the code for debugging. Commercial users of
Boost may not like those terms.
My company, for example, would be interested in the BGL, but quite
unable
to include an LGPL library, since our copy protection mechanism kills
the application if it detects a debugger. This would be a license
violation. (We probably wouldn't need bignum functionality. As long
as the BGL can be used without the bignum libraries, we'd probably be
happy.)
Huh, they basically exclude copy protection in the terms of their license? I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake?
Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. That can be performed with 64 bit unsigned integer if you keep track of the sign seperately. The only other places where I need high precision are the computation of the sweep-line intercept for comparing the y coordinates of segments that intersect the sweep-line and the actual computation of intersection points. Instead of using mp rational I could provide robust calculations "by hand" if I implement enough of what is in a multi-precision rational to get by or come up with some tricks. Long double only barely fails in my pseudo-exhasutive testing of line intersection computation. Since its result is only off by a small margin I could potentially detect these errors and handle them specially. The impor
tant aspect of the intersection computation is that when it snaps to the the integer grid both line segments must intersect that integer grid box. This check can be performed with point on-above-or-below line segment based degree-2 predicates (on-above-or-below can be implemented with slope comparison) that don't need multi-precision or rationals and then I can search adjacent grid boxes for one that meets the criteria for correctness if the check fails for the one computed by floating point approximation. Happily I have the ability to validate such fancy (read error-prone) code against the known correct big-num reliant implementation I already have.
Luke
------------------------------
Message: 4
Date: Mon, 23 Mar 2009 19:01:29 +0100
From: Sebastian Redl <sebastian.redl@getdesigned.at>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: boost@lists.boost.org
Message-ID: <49C7CE79.10607@getdesigned.at>
Content-Type: text/plain; charset=ISO-8859-1
Sebastian Redl wrote:
My company, for example, would be interested in the BGL, but quite
unable
to include an LGPL library, since our copy protection mechanism kills
the application if it detects a debugger. This would be a license
violation. (We probably wouldn't need bignum functionality. As long
as the BGL can be used without the bignum libraries, we'd probably be
happy.)
Huh, they basically exclude copy protection in the terms of their license?
They require that it is still possible to debug the LGPLed library in
Simonson, Lucanus J wrote:
the context of the combined work. If there's a debugger killer as part
of the copy protection (and every effective CP needs one), that's
obviously not possible.
I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake?
Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry
libraries called that?
Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates.
I'm fairly certain that I don't need that. So it's a question of how
modular the library is.
Sebastian
------------------------------
Message: 5
Date: Mon, 23 Mar 2009 11:16:01 -0700
From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: "boost@lists.boost.org" <boost@lists.boost.org>
Message-ID:
<26E9B811E137AB4B95200FD4C950886B262115D3@orsmsx507.amr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Sebastian Redl wrote:
Sebastian Redl wrote:
My company, for example, would be interested in the BGL, but quite
unable to include an LGPL library, since our copy protection
mechanism kills the application if it detects a debugger. This
would be a license violation. (We probably wouldn't need bignum
functionality. As long as the BGL can be used without the bignum
libraries, we'd probably be happy.)
Huh, they basically exclude copy protection in the terms of their
license?
They require that it is still possible to debug the LGPLed library in
Simonson, Lucanus J wrote:
the context of the combined work. If there's a debugger killer as part
of the copy protection (and every effective CP needs one), that's
obviously not possible.
I didn't trust the LGPL when I read it because it was obviously
written by a lawyer. Did you mean GTL and type BGL by mistake?
Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry
libraries called that?
I think it's called ggl, generic geometry library. Boost geometry library would be confusing.
Ideally I'd like to eliminate dependence on big-num for robustness,
for performance reasons if not license concerns, but this requires
some fancy programming. For instance, the degree-2 predicate of
slope comparison requires 65 bits when the input is 32 bit
coordinates.
I'm fairly certain that I don't need that. So it's a question of how
modular the library is.
Well, I have no explicit dependency on big num, just provide the ability to override non-robust arithmetic by specifying a big num data type. I have no direct code dependency on any external library, only the stl.
What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information.
Thanks,
Luke
------------------------------
Message: 6
Date: Mon, 23 Mar 2009 19:23:06 +0100
From: Sebastian Redl <sebastian.redl@getdesigned.at>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: boost@lists.boost.org
Message-ID: <49C7D38A.8080506@getdesigned.at>
Content-Type: text/plain; charset=ISO-8859-1
Simonson, Lucanus J wrote:
What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information.
It's pretty vague at this time. We've been doing without, and looking at
it to optimize some algorithms that currently work on rasters. We're
mostly looking for quickly doing many, many polygon intersections in a
huge floating point coordinate system. (Transformed to integer rasters
at a given resolution.) The whole thing is about geographic data.
Sebastian
------------------------------
Message: 7
Date: Mon, 23 Mar 2009 11:30:38 -0700
From: "Simonson, Lucanus J" <lucanus.j.simonson@intel.com>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: "boost@lists.boost.org" <boost@lists.boost.org>
Message-ID:
<26E9B811E137AB4B95200FD4C950886B262115F7@orsmsx507.amr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Sebastian Redl wrote:
It's pretty vague at this time. We've been doing without, and looking
at
it to optimize some algorithms that currently work on rasters. We're
mostly looking for quickly doing many, many polygon intersections in a
huge floating point coordinate system. (Transformed to integer rasters
at a given resolution.) The whole thing is about geographic data.
Do you need map overlay, or is polygon intersection enough? I have both, but most other libraries only provide intersection.
Luke
------------------------------
Message: 8
Date: Mon, 23 Mar 2009 14:38:15 -0400
From: "Schrader, Glenn" <gschrad@ll.mit.edu>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: "boost@lists.boost.org" <boost@lists.boost.org>
Message-ID:
<57F5948627B03042A29E70F4AABB446A9311073C9D@LLE2K7-BE01.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
-----Original Message-----
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]
On Behalf Of Sebastian Redl
Sent: Monday, March 23, 2009 2:01 PM
To: boost@lists.boost.org
Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr
that have a LGPL license ?
Huh, they basically exclude copy protection in the terms of their
license?
They require that it is still possible to debug the LGPLed library in
the context of the combined work. If there's a debugger killer as part
of the copy protection (and every effective CP needs one), that's
obviously not possible.
I assume you are referring to the "Combined Works" section of the LPGL. This is the only paragraph I can find containing the string "debug".
*
* 4. Combined Works.
* You may convey a Combined Work under terms of your choice that,
* taken together, effectively do not restrict modification of the
* portions of the Library contained in the Combined Work and
* reverse engineering for debugging such modifications, if you
* also do each of the following:
*
The term "Library" means "the library that is licensed under the LGPL". Note that the wording says >debugging< and NOT a >debugger<. Debugging can be carried out in different ways. For instance, the library can be instrumented using printf/cout. While the ability to run a debugger is certainly convenient, I fail to see how this mandates it. Some may object to the reverse engineering clause but its only an issue if reverse engineering is actually needed. If you say up front how you use the library then there should be no need to reverse engineer anything.
Sebastian
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
Message: 9
Date: Mon, 23 Mar 2009 19:51:31 +0100
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: boost@lists.boost.org
Message-ID: <gq8lnj$ii0$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sebastian Redl wrpte:
Huh, they basically exclude copy protection in the terms of their license?
They require that it is still possible to debug the LGPLed library in
the context of the combined work. If there's a debugger killer as part
of the copy protection (and every effective CP needs one), that's
obviously not possible.
In the case of DRM, the law in some countries requires to provide
information for interoperability on demand anyway, so what the LGPL
requires is actually required for any software in those countries.
------------------------------
Message: 10
Date: Mon, 23 Mar 2009 15:48:17 -0400
From: "troy d. straszheim" <troy@resophonic.com>
Subject: [boost] [GSOC] 10 Day student application period begins today
To: boost@lists.boost.org
Message-ID: <49C7E781.1070600@resophonic.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The window is open another week and a half or so. Deadline: April 3.
Our first student proposal (py3k support for boost python) arrived
within moments of the start of the application period.
Don't be shy, keep discussing your ideas, and make some proposals. You
can't get accepted if you don't apply.
-t
------------------------------
Message: 11
Date: Mon, 23 Mar 2009 16:48:04 -0400
From: Qihong Wang <qihongwang@gmail.com>
Subject: Re: [boost] How to build 32 bits boost library on a 64 bits
platform
To: boost@lists.boost.org
Message-ID:
<cf7fc54c0903231348n7bb3b585k8ac4a71aabbb84d0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
It works for me. If I just specify address-mode, the library is still 64
bits. I have to specify both. Before I tried this, I also tried to specify
gcc version and compileFlag and linkFlag as -m32 according to document. That
doesn't work either.
Thanks Fr?d?ric and Alexander.
On Mon, Mar 23, 2009 at 4:16 AM, Alexander Arhipenko <arhipjan@gmail.com>wrote:
On Sat, Mar 21, 2009 at 10:58 PM, Qihong Wang <qihongwang@gmail.com>
wrote:
Hello,
My platform is a 64 bits Linux with gcc. My program needs to link a 32
bits
library without source code and other
libraries with source code. I wrote a script to build those libraries
with
source code by
./configure --prefix=$install_prefix CFLAGS="-g -O2 -Wall -m32"
CPPFLAGS=-m32 CXXFLAGS="-g -O2 -m32"
make install
Then start to build my executable through Makefile with -m32 flag either.
The configure and make install work for other libraries but not work for
boost. The boost libraries were compiled and
installed but still 64 bits. Linker refused to link it. Is there any
simple
approach to build 32 bits boost on 64 bits Linux?
Thanks,
Qihong
Passing 'address-model=32 architecture=x86' arguments to bjam works fine
for me.
Regards
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
Message: 12
Date: Mon, 23 Mar 2009 21:05:06 +0000
From: "Phil Endecott" <spam_from_boost_dev@chezphil.org>
Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
To: <boost@lists.boost.org>
Message-ID: <1237842306073@dmwebmail.dmwebmail.chezphil.org>
Content-Type: text/plain; format="flowed"
Indradip Ghosh wrote:
I would like to get suggestions on developing a thread scheduler API for
supporting users having specific needs in prioritizing threads
running on SMP / Multi-Core processors. Please let me know the
viability of including such an API in generic boost distribution and
whether anyone would volunteer to mentor this effort as a GSOC
project.
Hi Indradip,
I have previously looked at passing POSIX thread attributes (i.e.
priority and policy) and it's not much work; presumably it could now be
done using the native handle in the proposed std::thread and new
version of boost::thread. How close to the POSIX semantics does
Windows come? Boost generally prefers to implement portable stuff
(although that's not something I need!) and choosing to work in an area
where the different platforms have little common ground will make
things more difficult for you, unless you're already familiar with how
this stuff works on both POSIX and Windows systems.
Beyond that there's the area of processor affinity, where as far as I
know POSIX has nothing to say. Linux has some APIs for this but I
doubt they have much in common with any other platforms. Maybe the
Intel TBB library has already solved all of this?
I'm wondering how something like a thread pool would be extended to
exploit processor affinity, if the lower-level API offered it.
Do you have a motivating application?
Phil.
------------------------------
Message: 13
Date: Mon, 23 Mar 2009 23:57:19 +0100
From: "vicente.botet" <vicente.botet@wanadoo.fr>
Subject: [boost] [interprocess] locked mutex and process killed
To: <boost@lists.boost.org>
Message-ID: <D12CA6DE6C6E4902B1170C7ED7F2AD8D@viboes1>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
what happens when a process owning interprocess::mutex is killed? is the mutex unlocked before the process dies?
Thanks,
Vicente
------------------------------
Message: 14
Date: Tue, 24 Mar 2009 00:55:18 +0100
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Subject: Re: [boost] "[gsoc] Thread scheduler support for boost"
To: boost@lists.boost.org
Message-ID: <gq97h5$dbk$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Indradip Ghosh wrote:
I would like to get suggestions on developing a thread scheduler API for
supporting users having specific needs in prioritizing threads
running on SMP / Multi-Core processors. Please let me know the
viability of including such an API in generic boost distribution and
whether anyone would volunteer to mentor this effort as a GSOC
project.
Are you suggesting a N:M threading model where you can specify the
userland scheduler?
------------------------------
Message: 15
Date: Mon, 23 Mar 2009 21:22:06 -0800
From: "Robert Ramey" <ramey@rrsd.com>
Subject: [boost] has_operator_new
To: boost@lists.boost.org
Message-ID: <gq9n29$dr4$1@ger.gmane.org>
I've made a TRAK item to request a new type traits feature -
has_operator_new. I've included an implementation and a test - both
type_traitsified. Hope you can see fit to check it out, and if it's OK,
check it in. Let me know when you do this. Once this is in, I can clear a
dependent feature request TRAK item from the serialization library.
Robert Ramey
------------------------------
Message: 16
Date: Mon, 23 Mar 2009 21:38:54 -0800
From: "Robert Ramey" <ramey@rrsd.com>
Subject: [boost] BOOST_NO_INTRINSIC_INT64_T
To: boost@lists.boost.org
Message-ID: <gq9o1p$fkm$1@ger.gmane.org>
boost config includes BOOST_NO_INTRINSIC_WCHAR_T.
boost Is there any chance we might see BOOST_NO_INTRINSIC_INT64_T
appear in the near future?
Robert Ramey
------------------------------
Message: 17
Date: Tue, 24 Mar 2009 10:18:25 +0100
From: Barend Gehrels <barend@geodan.nl>
Subject: Re: [boost] Can a Boost library use a component like GMP and
mfpr that have a LGPL license ?
To: boost@lists.boost.org
Message-ID: <49C8A561.7010709@geodan.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Fernando Cacciola wrote:
A different and much less ambitious goal could be to come up with a
good C++ *interface* to *those* libraries. That is, C++ number types
specifically designed to be implementable on top of a C API like that
of GMP and MPFR.
This is the approach we planned to take. In our geometry library (GGL)
we want to optionally calculate with large number types as GMP or CLN.
The GGL (or other geometry libraries who might take the same approach)
is completely independant from GMP and from their license. It can just
work together.
We will work this out in the upcoming preview of GGL. We realize that it
is not applicable for geometry alone, so we make it independant from it
and might submit it as a separate, small, header-only library. The
sample (link below) shows a numeric_adaptor, having a policy of either
gmp, or just ieee types, or other big number types as cln (not worked
out). Other policies might elaborate adaptive precision.
See
http://geometrylibrary.geodan.nl/num/numeric_adaptor.html
Details might change of course, such as the place of the member variable
in either adaptor or policy, but the sample will give the general idea.
Regards,
Barend Gehrels, Amsterdam
Bruno Lalande, Paris
------------------------------
Message: 18
Date: Tue, 24 Mar 2009 09:08:19 +0100 (CET)
From: solar@rootdirectory.de
Subject: [boost] Boost with ICU on AIX - Patch
To: boost@lists.boost.org
Message-ID: <20090324080819.1361134C4B8@mail.lcube.de>
Content-Type: text/plain; charset="ISO-8859-1"
Hi there,
while trying to get Boost 1.34.1 to work on an AIX machine, I
found a bug that still persists in 1.38.0. You might want to fix
this...
In boost/regex/icu.hpp:
314c314
< typedef std::vector<UCHAR32> vector_type;
---
typedef std::vector<UChar32> vector_type;
318,319c318,319
< v.push_back((UCHAR32)(*i));
< ++a;
v.push_back((UChar32)(*i));
++i;
It should be obvious once you look at the source environment -
the UCHAR32 is probably a typo, and the ++a is copy-and-paste
work. This has obviously never been test-compiled on a real
machine. Surprising that this has not been caught earlier (since
it's been in there since 1.33)...
Anyway, with that patch (and a backport of another one on
vacpp.jam that's been included in later versions of Boost), v1.34.1
compiles cleanly with ICU-support on AIX.
Regards,
Martin Baute
------------------------------
Message: 19
Date: Tue, 24 Mar 2009 09:52:36 -0000
From: "John Maddock" <john@johnmaddock.co.uk>
Subject: Re: [boost] has_operator_new
To: <boost@lists.boost.org>
Message-ID: <0993906E24C64887BD216A8DA04492EC@acerlaptop>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
I've made a TRAK item to request a new type traits feature -
has_operator_new. I've included an implementation and a test - both
type_traitsified. Hope you can see fit to check it out, and if it's OK,
check it in. Let me know when you do this. Once this is in, I can clear
a dependent feature request TRAK item from the serialization library.
I'll look into it: did you test out the is_virtual_base in SVN type_traits
Trunk BTW?
John.
------------------------------
Message: 20
Date: Tue, 24 Mar 2009 11:08:59 +0100
From: "Edouard A." <edouard@fausse.info>
Subject: Re: [boost] [interprocess] locked mutex and process killed
To: boost@lists.boost.org
Message-ID: <04ab3291f101326aab20f6b7c4b7253b@127.0.0.1>
Content-Type: text/plain; charset="UTF-8"
On Mon, 23 Mar 2009 23:57:19 +0100, "vicente.botet"
<vicente.botet@wanadoo.fr> wrote:
Hi,
what happens when a process owning interprocess::mutex is killed? is the
mutex unlocked before the process dies?
After a quick look at the source code:
inline void interprocess_mutex::lock()
{
if (pthread_mutex_lock(&m_mut) != 0)
throw lock_exception();
}
The answer to your question is "an exception will be thrown" since the call
will return "EOWNERDEAD".
Generally speaking when a thread terminates while holding a mutex, the
mutex is considered abandoned and shared resources protected by the mutex
are in an undetermined state. Hope you like quantum physics. ;)
--
EA
------------------------------
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
End of Boost Digest, Vol 2497, Issue 1
**************************************
Hartmut Kaiser
Indradip Ghosh