4. In case an assertion has failed, two actions will occur:
- first, the assertion will be logged
- second, a message will be show to the user, and the user can choose from
multiple actions, like Ignore, Retry, Abort, etc.
These are SEPARATE actions, and are both customizable.
Customization can
BOOST_ASSERT(some_lenghty_function())(???)
2. BOOST_ASSERT( some_lengthy_function() 10) ( some_lengthy_function());
Indeed, is kind of lengthy, but this is life :-(
The point is that I could provide the v_ macro as well - it would not be too
complicated. What do others think?
I wondered about
Darren Cook wrote:
In my own assert library I added options for logging, but in the end
never used that and always had it throw an exception. This is nice for
two reasons:
1. MFC debugger catches it and allows me to go back up the call stack
to where the assert happened. (I'm still struggling
Alexander Nasonov wrote:
I agree that a-move(10, 10) is clearer then move()(a, 10, 10). One big
plus of it is ability to overload move member-function: a-move(Point(10,
10)). You can't do that with move operation:
move()(a, 10, 10);
move()(a, Point(10, 10)); // error
You have to
I just restored the lost revisions for these three headers:
boost/config/platform/win32.hpp
boost/config/stdlib/stlport.hpp
boost/filesystem/convenience.hpp
and, comparing what is probably the most recent before-the-disk-crash CVS
snapshot to the current CVS state, it seems that
I just restored the lost revisions for these three headers:
boost/config/platform/win32.hpp
boost/config/stdlib/stlport.hpp
boost/filesystem/convenience.hpp
and, comparing what is probably the most recent before-the-disk-crash
CVS
snapshot to the current CVS state, it seems
Darren Cook wrote:
Anywhere in Boost is fine by me; currently it is in boost::detail and
not in the documentation.
Given enough pressure... and documentation... and tests... ;-)
OK. How about a template parameter to specify page size? We could use
the platform and the class size to guess a
On Thu, 8 May 2003 05:20:11 -0500, Aleksey Gurtovoy
[EMAIL PROTECTED] wrote:
I just restored the lost revisions for these three headers:
boost/config/platform/win32.hpp
boost/config/stdlib/stlport.hpp
boost/filesystem/convenience.hpp
Thanks Aleksey. I was particularly
Gennaro Prota wrote:
I drop an idea: suppose that when there's a new
commit the CVS informs, via e-mail, the penultimate people that had
done a commit. This way I (the generic developer) can do the
following: before doing any commit check out the whole repository (in
order to have the newest
Christopher Currie wrote:
While in theory I agree with Aleksey, I tried David's suggestion of
inhibiting in-class static constant initialization. This single change
eliminatated all but one of the remaining problems I've had compiling
the tests for type_traits (there's still an assertion
Gennaro Prota wrote:
I think this is a bit more complicated that it should be. Why don't just
create boost-wide commit emails mailing list?
Off-hand _this one_ seems more complicated, because it involves more
people than necessary and forces to keep the diffs (though just for,
say, a couple
If VERIFY is used in MFC to mean an assert even in release mode then that
is
probably the best name.
In MFC it doesn't have that meaning though. It means that the expression
passed to VERIFY will get evaluated in the release build but the result of
this expression will not get checked in release
... various backup suggestions
SourceForge already makes the entire Boost CVS tarball available every
night, and several Boosters download it daily.
(At least I hope they do - I have no way of telling if they are still
running their cron jobs.)
That is supposed to protect us from total
Roland Richter said:
Dear all,
I'm new with Boost.Threads; I've just worked with
Java Threads so far.
One feature of the Java language is the synchronized
keyword - to make variables, methods, code blocks etc.
thread-safe. So, when I first came into the situation
that I
On Thursday, May 8, 2003, at 07:04 AM, Beman Dawes wrote:
A 2-3% timing difference probably isn't reliably repeatable in real
code.
How code and data happens to land in hardware caches can easily swamp
out such a small difference. The version-to-version or step-to-step
differences in CPU's,
In message [EMAIL PROTECTED],
[EMAIL PROTECTED] writes
From: Markus Werle [EMAIL PROTECTED]
The feature mentioned in the subject is missing in boost.
(actually it throws)
I propose adding something simmilar to the (incomplete) stuff below.
template typename Source
class
My experience tuning our java VM is similar, and it runs on a lot of
different CPUs. Still, there is reason to be suspicious of very small
changes, which might be repeatable for our benchmark set, yet have no
real meaning for normal use. And there is reason to be careful not to
waste time
If VERIFY is used in MFC to mean an assert even in release mode then
that
is
probably the best name.
In MFC it doesn't have that meaning though. It means that the expression
passed to VERIFY will get evaluated in the release build but the result of
this expression will not get checked in
Gennaro Prota wrote:
On Thu, 8 May 2003 15:06:02 +0300, John Torjo [EMAIL PROTECTED]
wrote:
Unfortunately, we can't use the do-while(0) idiom, since we don't know when
while(0) will be ;-)
Oops, no. That's not the problem. The problem is that I read Daniel's
reply out of context and too
the following fails to compile. Should it?
--
#include boost/mpl/vector.hpp
#include boost/mpl/push_back.hpp
namespace mpl = boost::mpl;
typedef mpl::vectorint[1], int[2], int[3], int[4], int[5], int[6], int[7], int[8],
int[9], int[10] v10;
typedef mpl::push_backv10, int[11]::type
At 11:11 AM 5/8/2003, Darin Adler wrote:
On Thursday, May 8, 2003, at 07:04 AM, Beman Dawes wrote:
A 2-3% timing difference probably isn't reliably repeatable in real
code.
How code and data happens to land in hardware caches can easily swamp
out such a small difference. The
On Thursday, May 8, 2003, at 11:07 America/Denver, Beman Dawes wrote:
At 11:11 AM 5/8/2003, Darin Adler wrote:
On Thursday, May 8, 2003, at 07:04 AM, Beman Dawes wrote:
A 2-3% timing difference probably isn't reliably repeatable in real
code.
How code and data happens to land in hardware
Somewhere in this thread I lost track of this -- but just how
do out and in differ from ref and cref?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gennaro Prota wrote:
Just that Borland won't warn on BOOST_INVARIANT(false). Admittedly
not a big one :-)
This warning can be configured away simply by purposely accessing a non-constant
variable or calling an inline function:
inline bool force_non_constant() { return true; }
if
Right!
However, I think this would be a great feature (and a good name -
BOOST_VERIFY) - to allow the same behaviour as ASSERT in release as well.
What do you think? Do you think of a better name?
how about just VERIFY() :-)
-Thorsten
___
David Abrahams wrote:
the following fails to compile. Should it?
--
#include boost/mpl/vector.hpp
#include boost/mpl/push_back.hpp
namespace mpl = boost::mpl;
typedef mpl::vectorint[1], int[2], int[3], int[4], int[5], int[6],
int[7], int[8], int[9], int[10] v10;
typedef
I just made a mistake with the MPL and got this error message:
c:/boost/boost/python/init.hpp:246: warning:
`typename boost::mpl::iterator_range
boost::mpl::begin
boost::python::detail::type_list
T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13,
Beman Dawes wrote:
... various backup suggestions
SourceForge already makes the entire Boost CVS tarball available every
night, and several Boosters download it daily.
Oh, good. There is no such thing as too much backup.
(At least I hope they do - I have no way of telling if they are
28 matches
Mail list logo
