Attached is an implementation of 'boost::tuples::apply' function template,
providing one with a possibility of function application on a tuple of
arguments:
#include boost/tuple/tuple.hpp
#include boost/tuple/apply.hpp
using namespace boost;
void f(int, char const*);
int
Beman Dawes wrote:
In terms of new libraries and most major revisions, Boost developers
committed their files early, so we are in great shape. Thanks to the
developers of Filesystem, Optional, Interval, MPL, Spirit, Smart
pointers, Date-Time.
(If your library didn't get mentioned, its
David B. Held [EMAIL PROTECTED] writes:
This is a request for anyone who is willing and able to help finish
writing the tests for policy_ptr in the sandbox. I'm afraid that I
just don't have the time to dedicate to this library to come
anywhere close to the April meeting of the LWG (or
It strange. At least 2.95.3 should crash imidiately. This compiler does
not
support sigaction. So there is no signal handling installed. And the first
sigaction is supported by all gcc versions if the platform has it (and BSD
does).
John Maddock
After thinking about it longer, I still think that there is a problem. The
code seems twisted to me. Let me try to explain it, I start by some
observations (all for the case of
BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION not being set):
is_scalar is based on 3.9/10, which says that
Did somebody manage to link shared library with HP aCC and run the jgrep
example ?
It links but the excutable crashed !! (OK with the library is static
built)
I'm afraid I know nothing about shared libs on HP. If the static lib works
then I would suggest that you stick with that if you can,
There's no need for us to argue about this, is there? Can't we detect
whether the compiler is supporting long long and only enable the
long long code under those circumstances? In fact, /don't/ we do
that?
If this is just about inconvenient warnings, it seems to me that
telling people
On Sat, 15 Feb 2003 12:45:10 +0100, John Maddock wrote:
After thinking about it longer, I still think that there is a problem.
The code seems twisted to me. Let me try to explain it, I start by
some observations (all for the case of
BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION not being
At 09:18 PM 2/13/2003, Gennadiy Rozental wrote:
No, it is some sort of configuration problem.
Look on metrowerks linking errors thread. It about the same issue with
different undefined symbol
I have a vague memory of that, but can't find the thread. Can you be more
specific?
In the meantime,
This morning's Win32 regression tests have been posted. Looking at the
diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html,
there are still some worries:
* random/random_test is failing, and/or exhausting compiler memory for most
compilers, on both Win32 and other platforms.
Another thing is I think it is important to get at least one
non-Sockets-based network API in the mix right at the beginning to
make
sure the design is truly flexible. I recommend Apple's OpenTransport,
not because it will be around much longer, but because it is quite a
bit different from
At the very end of it, network programmers should be using a
callback-driven interface and not have to worry about multiplexing at
all, but I agree that for now a third layer should be deferred until
the basic groundwork has been laid out.
Yes the level 2 interface should be callback driven.
On Sat, 15 Feb 2003 12:00:36 -, John Maddock
[EMAIL PROTECTED] wrote:
Can't we detect
whether the compiler is supporting long long and only enable the
long long code under those circumstances? In fact, /don't/ we do
that?
If this is just about inconvenient warnings, it seems to me that
And just for your amusement:
#include boost/type_traits.hpp
// #include mfl/type_traits.hpp
namespace test = boost;
class A {};
int main()
{
typedef test::remove_pointer int A::* ::type t1;
typedef test::remove_pointer int A::* const ::type t2;
typedef test::remove_pointer int A::*
As someone mentioned previously...
The links to libraries and source are broken.
I took a few minutes to put in an .htaccess file on the server that
redirects those links to reasonable places.
For the library links they are redirected to the corresponding www.boost.org
point.
For the
Daniel Frey wrote:
typedef test::remove_pointer int A::* ::type t1;
typedef test::remove_pointer int A::* const ::type t2;
typedef test::remove_pointer int A::* volatile ::type t3;
typedef test::remove_pointer int A::* const volatile ::type t4;
typedef test::add_const
At 03:56 AM 2/15/2003, David Abrahams wrote:
... in the standards committee we operate in the
rarified air where all compilers are perfectly conforming (just
kidding, but it's almost like that).
It is indeed like that. There wasn't a compiler in
the world that could handle the standard library
At 12:45 PM 2/15/2003, Rene Rivera wrote:
As someone mentioned previously...
The links to libraries and source are broken.
I took a few minutes to put in an .htaccess file on the server that
redirects those links to reasonable places.
For the library links they are redirected to the
[2003-02-15] Beman Dawes wrote:
At 12:45 PM 2/15/2003, Rene Rivera wrote:
As someone mentioned previously...
The links to libraries and source are broken.
I took a few minutes to put in an .htaccess file on the server that
redirects those links to reasonable places.
For the
* test lib has three tests failing all compilers; at least some of these
passed until recently.
Note that errors_handling_test and results_resport_test failures does not
lead ot any error messages.
So I would recommend to perform clean build of those two.
test_fp_comparisons IS failing on all
sigaction is supported by all gcc versions if the platform has it (and BSD
does).
You right. But, then it looks like it does not work properly, cause
siglongjump causing SIGSEGV.
Maybe we do not want to use sigaction facility with gcc 2.95.3?
Could we change line 64 in execution_monitor.cpp so
I fixed config/test/Jamfile to use proper names of Boost.Test libraries.
How does this thing work in regression testing?
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[2003-02-15] Gennadiy Rozental wrote:
sigaction is supported by all gcc versions if the platform has it (and
BSD
does).
You right. But, then it looks like it does not work properly, cause
siglongjump causing SIGSEGV.
Maybe we do not want to use sigaction facility with gcc 2.95.3?
Could we
Daniel Frey [EMAIL PROTECTED] writes:
I won't try to fix any of these anymore. I neither understand the
documentation nor the implementation of boost's type-traits. I tried to
make the code better but AFAICS there is no interest in improvment.
Does anyone understand what improvement you're
With the latest CVS...
cd BOOST_ROOT/tools/build/jam_src
sh ./build.sh
1. This produce an error stating that whence is not accessible. whence seems
to be Korn shell utility. SO now I am using
ksh ./build.sh
2. Almost zero compilation errors but one:
pwd.c: In function `pwd':
pwd.c:17:
Maybe I should do the factorization and put it in the sandbox or
boost::detail...
Looking forward to see that. Could you, please, let me know when you done or
if you need my help?
optimization crop up). This is not an idiom that's been
well-exercised in compiler vendors' test suites,
On Sat, 15 Feb 2003 19:01:08 +0100, Peter Dimov wrote:
Daniel Frey wrote:
typedef test::remove_pointer int A::* ::type t1; typedef
test::remove_pointer int A::* const ::type t2; typedef
test::remove_pointer int A::* volatile ::type t3; typedef
test::remove_pointer int A::*
Here what I getting from config_info compiled with gcc 3.2
GNU C++ version 3.2.1
__cplusplus =1
__STDC__=1
_WCHAR_T [no value]
_WCHAR_T_DEFINED [no value]
On Sun, 16 Feb 2003 01:14:17 +0100, David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
I won't try to fix any of these anymore. I neither understand the
documentation nor the implementation of boost's type-traits. I tried to
make the code better but AFAICS there is no interest in
Daniel Frey wrote:
I won't try to fix any of these anymore. I neither understand the
documentation nor the implementation of boost's type-traits. I
tried to make the code better but AFAICS there is no interest in
improvment.
Does anyone understand what improvement you're trying to
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
This morning's Win32 regression tests have been posted. Looking at the
diff, http://boost.sourceforge.net/regression-logs/cs-win32-diff.html,
there are still some worries:
An aside -
Since 1.30.0 will
Attached is a series of lock I created for one of my projects. These
classes have the following features.
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implemented the Monitor concept.
2) Avoid the need for recursive locks by careful
32 matches
Mail list logo
