David Abrahams wrote:
Someone at HP has been testing against boost and has found a bug and
some workarounds for parts of the graph library. The message he sent
me is enclosed.
Since I was using BGL recently, I took the liberty of looking though these patches.
1) boost/graph/copy.hpp
Dave Gomboc wrote:
No, I would prefer
#if BOOST_WORKAROUND(__HP_aCC, =33900) || BOOST_WORKAROUND(__VisualAge,
=12345)
template bool cond, typename T struct enable_if;
#else
template bool, typename struct enable_if;
#endif
I already explained the reason: C++ compiler vendors
David Abrahams wrote:
But I was under the impression that is_class's workaround must be
broken in some way - although I couldn't see it. (Yes, I shouldn't
have claimed what is broken from just reading code - I should have
at least tried it out). I think I should not assume such things in
I will try to address 1(without tss) 2 and 4 today.
I committed execution_monitor.cpp with changes that should address above
issues. We may try now recheck how signal handling behave on OpenBSD
Gennadiy.
___
Unsubscribe other changes:
There still are getenv link errors in prg_exec_fail1 and prg_exec_fail2.
I think I've got them fixed. Testing now.
And what is the fix?
prg_exec_fail3.cpp is failing: Assertion(div != 0), line 32.
It what supposed to happend. Important thing is whether the test is aborted
at that moment or
The mandrake 9 box used for the linux regression tests seem to fail
static-linking tests.
http://boost.sourceforge.net/regression-logs/cs-linux-links.html#format_test1%20gcc
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
export LD_LIBRARY_PATH
g++ -static
Gennadiy Rozental said:
I've been looking at your signal handling implementation in
execution_monitor.cpp, and I think I've uncovered quite a few bugs,
some of which are really quite fatal for multithreading code.
The code never promised to work in multithreaded environment, nor even
to be
Le lun 17/02/2003 à 11:30, Samuel Krempp a écrit :
The mandrake 9 box used for the linux regression tests seem to fail
[ .. ]
Sorry, I missed-up the subject line when sending my first message.
It should have read
Re: [boost] linux regression tests : static-link troubles ?
...
--
Samuel
No, I would prefer
#if BOOST_WORKAROUND(__HP_aCC, =33900) ||
BOOST_WORKAROUND(__VisualAge, =12345)
template bool cond, typename T struct enable_if;
#else
template bool, typename struct enable_if;
#endif
I already explained the reason: C++ compiler vendors use Boost
On Sat, 8 Feb 2003, Joerg Walter wrote:
Hi Johan,
[...]
On 32-bit systems the upper dimensions for sparse_matrix are 65535 x 65535
due to the internal mapping of (i, j) - (i * size2+j) (or (i + j * size1).
I've added a corresponding check to the debug version.
For larger dimension
Vladimir Prus [EMAIL PROTECTED] writes:
David Abrahams wrote:
2.1) libs/graph/test/graph_type.hpp
#line 136
Graph g;
typedef boost::graph_traitsGraph::vertex_descriptor Vertex;
typedef boost::graph_traitsGraph::edge_descriptor Edge;
I have something completely
Daniel Frey [EMAIL PROTECTED] writes:
And finally, if I got you right, it might
also be useful to use my is_class-version to add it even if we have 3
versions in is_class then. I guess that the older EDG-versions you
refer to are really slow when having to instantiate all the dependecies
of
Somewhere in the E.U., le 17/02/2003
In article [EMAIL PROTECTED],
Paul A. Bristow [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Hubert Holin
Sent: Friday, February 14, 2003 1:25 PM
To: [EMAIL PROTECTED]
Subject:
From: Daniel Frey [EMAIL PROTECTED]
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;
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
And finally, if I got you right, it might
also be useful to use my is_class-version to add it even if we have 3
versions in is_class then. I guess that the older EDG-versions you
refer to are really slow when having to
Peter Dimov [EMAIL PROTECTED] writes:
I don't see why you expect remove_pointer(T) to work when T is not a
pointer.
I think that's a reasonable expectation, if by work you mean return
the original type without modification. That's what it does for int
arguments, for example.
--
Dave
From: David Abrahams [EMAIL PROTECTED]
Peter Dimov [EMAIL PROTECTED] writes:
I don't see why you expect remove_pointer(T) to work when T is not a
pointer.
I think that's a reasonable expectation, if by work you mean return
the original type without modification. That's what it does for
Peter Dimov wrote:
From: Daniel Frey [EMAIL PROTECTED]
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
Daniel Frey [EMAIL PROTECTED] writes:
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
And finally, if I got you right, it might
also be useful to use my is_class-version to add it even if we have 3
versions in is_class then. I guess that the older EDG-versions you
refer
Daniel Frey wrote:
I think we should consider to define what should not work and what
should not. If we want add_const to reject types that cannot be made
const, we should also consider to make references not compile.
The definition of what should work in this case is simple:
add_constT::type
The graph_type.hpp file gets generated by a test file, in fact,
it gets generated over and over again. The purpose is to test
the many different variations of the adjacency_list.
Cheers,
Jeremy
On Mon, 17 Feb 2003, David Abrahams wrote:
dave Vladimir Prus [EMAIL PROTECTED] writes:
dave
dave
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
I think even Intel 7 is using the old front-end, but Intel 6
certainly. I don't know whether you'll _notice_ a difference, though.
Certainly not for a single instantiation, but why not write a benchmark?
I'll see if I can come up
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
Peter Dimov [EMAIL PROTECTED] writes:
I don't see why you expect remove_pointer(T) to work when T is not a
pointer.
I think that's a reasonable expectation, if by work you mean
I don't know exactly what you mean by non-trivial sever and what you
get from ACE/expect not to get from Boost.Socket that a non-trivial
server requires?
Depends on the server, CDR formatting, thread-safe queues come to mind.
There are probably a few threading things as well. Of course all
Peter Dimov wrote:
Daniel Frey wrote:
I think we should consider to define what should not work and what
should not. If we want add_const to reject types that cannot be made
const, we should also consider to make references not compile.
The definition of what should work in this case
Jeremy Siek [EMAIL PROTECTED] writes:
The graph_type.hpp file gets generated by a test file, in fact,
it gets generated over and over again. The purpose is to test
the many different variations of the adjacency_list.
OK, can you make the appropriate fix, then?
--
Dave Abrahams
Boost
At 05:12 AM 2/17/2003, Gennadiy Rozental wrote:
There still are getenv link errors in prg_exec_fail1 and
prg_exec_fail2.
I think I've got them fixed. Testing now.
And what is the fix?
Add MSL_All-DLL_x86.lib to the MWWinx86LibraryFiles environmental variable.
prg_exec_fail3.cpp is
I vote that variant be accepted into boost. I read all the documentation, and tried
out the code in a simple test under VC7. I am very pleased with this library.
Following are a comments I have that can help make it even better:
*Design:*
Please consider incorporating a blank type. This
At 09:44 AM 2/17/2003, David Abrahams wrote:
Jeremy Siek [EMAIL PROTECTED] writes:
The graph_type.hpp file gets generated by a test file, in fact,
it gets generated over and over again. The purpose is to test
the many different variations of the adjacency_list.
OK, can you make the
At 12:04 AM 2/17/2003, Douglas Gregor wrote:
I've removed the HTML-only documentation for these three libraries from
CVS, as the documentation for each is now maintained in BoostBook.
libraryname/index.html forwarding documents are in place to get to the
generated documentation (in doc/html), and
At 12:04 AM 2/17/2003, Douglas Gregor wrote:
I've removed the HTML-only documentation for these three libraries from
CVS,as the documentation for each is now maintained in BoostBook.
libraryname/index.html forwarding documents are in place to get to the
generated documentation (in doc/html), and
[2003-02-17] Gennadiy Rozental wrote:
I will try to address 1(without tss) 2 and 4 today.
I committed execution_monitor.cpp with changes that should address above
issues. We may try now recheck how signal handling behave on OpenBSD
They are running now, again. Results will take another 1.5
At 11:21 PM 2/15/2003, Carl Daniel wrote:
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
[2003-02-17] Rene Rivera wrote:
[2003-02-17] Gennadiy Rozental wrote:
I will try to address 1(without tss) 2 and 4 today.
I committed execution_monitor.cpp with changes that should address above
issues. We may try now recheck how signal handling behave on OpenBSD
They are running now, again.
On Mon, 17 Feb 2003 08:34:24 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
I think even Intel 7 is using the old front-end, but Intel 6
certainly. I don't know whether you'll _notice_ a difference, though.
I don't know what is, in context, the old front-end here. However
Intel C++ 7 for
On Monday 17 February 2003 11:21 am, Beman Dawes wrote:
Ouch! That means the current HTML docs for these libraries aren't available
to Boosters who depend on CVS to keep up-to-date,
They're always available here, regenerated nightly in HTML, DocBook, FO, PDF,
and man pages:
I'm trying the variant library, by currently it doesn't
compile with bcc551.
I'd like to be able to compile it with my compiler so I can base my
vote (tentatively to accept it) on more than the documentation
and interpretation of the code.
The first problem is that the current
On Mon, 17 Feb 2003 10:02:58 +0100, Daniel Frey
[EMAIL PROTECTED] wrote:
I started to implement my own type-traits to see if I can do it and to
learn something. While doing so, my design lead me to some dependencies:
is_enum needed is_class
Daniel, my apologies in advance if this is just a
Aleksey Gurtovoy wrote:
Fernando Cacciola wrote:
OK, I can see the motivation: We can have a noncopyable class
and need an optional object of it.
Following optional semantics, it would be spelled:
boost::optionalRAII_lock lock;
if ( cond )
lock.reset( RAII_lock(entity) ) ;
But there
Hi Johan,
you wrote:
Thanks for all your info. I've run the tests with a Boost from CVS (from
january 31st), compressed_matrix and axpy_prod, and the results give
roughly the same speed as our implementation, and ca. 30% better memory
efficiency. Great!
Kudos to the guys on
At 02:00 PM 2/17/2003, Douglas Gregor wrote:
On Monday 17 February 2003 11:21 am, Beman Dawes wrote:
Ouch! That means the current HTML docs for these libraries aren't
available to Boosters who depend on CVS to keep up-to-date,
They're always available here, regenerated nightly in HTML,
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Curiosity got the better of me, and I did an experimental run on build
2292.
Looks pretty good. A vast improvement over prior releases. Problems
noted:
* Missing overloads for long long.
*
We don't want to stick all of the generated HTML into CVS (too big).
If it is too big for the regular CVS, isn't it too big for the distribution
too? How big is big?
This is a radical idea, but maybe that's what's needed.
What if we did this:
1) Create a new CVS repository ala the sandbox for
The code never promised to work in multithreaded environment, nor even
to be thread save. It is in my to-do list. Though recent hands in
several situations may require address some of these issues sooner.
What?!? Where's the big, bold disclaimer about that!
It's in to-do section in front
On Monday 17 February 2003 04:49 pm, Beman Dawes wrote:
At 02:00 PM 2/17/2003, Douglas Gregor wrote:
They're always available here, regenerated nightly in HTML, DocBook, FO,
PDF, and man pages:
http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html
That really isn't very
Fernando Cacciola wrote:
[snip]
(3) variant dependency.
We are just about to review boost::variant.
I was planning to wrap optional around variant discarding its current
implementation.
This might seem like a good idea in theory, but for the simple case
presented by optional, the baggage of
46 matches
Mail list logo
