Re: [boost] smart assert (was: ENFORCE/ better assertion technique)
Basically, the N actions will be able to be customized (that is, you'll be able to add your own levels). What you say, about throwing an exception, also will be possible, since you'll be able to set a "handler" for each level of assertion. So, for instance, for assertions with level Debug (default), you can set a handler that will throw. Just like that! At run-time! (you can leave the default handler for assertions, that will prompt the user, etc. , or just set your own, which can throw an exception). This sounds good. So if I want to do a test that a function does actually assert with bad data I can switch to exceptions, do a BOOST_CHECK_THROW() test, then switch back to normal assertion behaviour. Following on from that, there seems some overlap between your proposed asserts and Boost.Test's BOOST_CHECK_() macros. I wonder if it would be possible to have an assert handler for use in the unit test framework, and then I can use SMART_ASSERT() in both main code and in test code and only have to learn one syntax. others have picked up and continued developing it. Some of the initial constraints have been loosened, therefore, some of the ASSERTs became unnecessary. Had such an ASSERT throw, some handler might catch it, and this could go undetected. What do you think? Yes, that is another problem with asserts throwing exceptions that I'd not considered. Darren ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: CVS status
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 still > running their cron jobs.) > > That is supposed to protect us from total failure, such as > SourceForge going bankrupt and shutting down unexpectedly. > > But it isn't clear what the best procedure is to protect against > partial failure - it seemed easier just to restore file-by-file in > this particular case. Sure, if the files content indeed makes sense. I would characterize our case as malfunctioning with the possible result of the bogus content; in this situation, plain content backup, whether it's intentional or accidental, tarball or separate files, is not a reliable source to restore from. We just happened to be lucky this time (if John will be able to restore his branch). I think Vladimir's suggestion makes sense and is worth doing. It covers what plain backups cannot, and costs nothing in terms of maintenance. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is a 3% timing difference reliably repeatable in realcode?
A 2-3% timing difference probably isn't reliably repeatable in real code.
My timing tests were interleaved as I swapped in various algorithms and
recompiled and the time differences were consistent. I gave ranges not
averages to give a feel for the "experimental error".
I'm not sure, though, if this negates your point, Beman. Something that
gives a 2-3% speedup for one Boost user might not be worth any level of
obfuscation unless we can prove it provides a similar speedup for other
Boost uses.
Just to avoid confusion for people joining this thread halfway, the 2-3%
speedup was in my code; I wasn't proposing obfuscating any boost library.
My point was that I got this speed-up by overriding operator new/delete with
one-liners in just a single class (of course I chose the class I new from
profiling was making heaviest use of new/delete):
void* operator new(std::size_t sz){
return boost::detail::quick_allocator::alloc(sz);
}
void operator delete(void *p,std::size_t sz){
boost::detail::quick_allocator::dealloc(p,sz);
}
where T is the name of my class. That is so easy it is practically free,
like using -O3 instead of -O2.
> In our project, a 3% speed increase is considered a cause for celebration.
>
- sped up JavaScript iBench by 70% by using a better sort algorithm and
reducing the number of UString allocations
How did you celebrate that one then? :-)
Darren
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] STLFilt rocks
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, T14 , boost::mpl::void_, boost::mpl::void_ > >::type , boost::mpl::apply_if< boost::python::detail::is_optional< boost::mpl::apply_if< boost::mpl::empty< boost::python::detail::type_list< T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14 , boost::mpl::void_, boost::mpl::void_ > >, int , boost::mpl::back< boost::python::detail::type_list< T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14 , boost::mpl::void_, boost::mpl::void_ > > > >, boost::mpl::prev< boost::mpl::end< boost::python::detail::type_list< T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14 , boost::mpl::void_, boost::mpl::void_ > >::type >, boost::mpl::end< boost::python::detail::type_list< T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14 , boost::mpl::void_, boost::mpl::void_ > > >::type >::type' is implicitly a typename That's just so beautyful it brings tears to my eyes. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL CVS still bustificated?
David Abrahams wrote: > > the following fails to compile. Should it? > > -- > > #include > #include > > namespace mpl = boost::mpl; > typedef mpl::vector v10; > typedef mpl::push_back::type v11; > Contrary to what the docs say, no. Please see http://groups.yahoo.com/group/Boost-Users/message/3852. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: smart assert (was:ENFORCE/betterassertiontechnique)
> 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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: in/out parameters, codingstylesandmaintenance
To Victor: You still haven't replied to the posting below. Am I to take this to mean that you have no answer, i.e. you were wrong but won't admit it? Or do you tend to offend people for no reason, and not care about it? If I don't hear anything from you, I'll assume both, because I have no reason to believe anything else. When you come with a claim like this, you should at least have the decency to explain what you mean, so I can reply to it. Posting vague accusations is simply bad manners. (Note: I've asked him about a reply to the posting below, off-list, but got no reply. I've also seen him post, after I sent the posting below. I would have preferred to settle this off-list) Regards, Terje >From: "Terje Slettebø" <[EMAIL PROTECTED]> > > >Do you still think I've got it backwards? > >From: "Victor A. Wagner, Jr." <[EMAIL PROTECTED]> > > > in a word, yes. > > In what way? > > > Regards, > > Terje > > > > At Saturday 5/3/2003 12:42 PM, you wrote: > > > >From: "Victor A. Wagner, Jr." <[EMAIL PROTECTED]> > > > > > > > "It's not possible" --- JML > > > > "Yes it isshow me an example" --- TS > > > > > > > > U, I think you got it backwards Terje > > > > > >No, I haven't, but I think you've misunderstood. > > > > > >I meant, show me an example of a function where you think it's impossible > to > > >just use name, to convey the meaning. > > > > > >His statement was: "And as I've already point out, it's not possible to > make > > >a function's intent clear with a name." > > > > > >Do you still think I've got it backwards? > > > > > >It's an attempt of getting the discussion more concrete, with actual > code. > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Proposal for improved versions of some std functionobjects
On Thursday, May 8, 2003, at 10:12 AM, Kresimir Fresl wrote: Matthias Troyer wrote: That's a good point. I have prepared a version separate from functional.hpp and posted it on our web server: http://www.comp-phys.org/software/function_objects/ Shouldn't the default type of the result of `logical_and' and `logical_or' be `bool' and not `Arg1'? Yes, that's a good point as std::logical_and as std::logical_or also have bool as return type I think that even for user defined types overloaded operators && and || will usually return boolean values. except for container types such as std::valarray, where an operator&& or operator|| might return a std::valarray. However in order to keep consistency with the standard when only one template argument is given, I agree that a default value of bool is better. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ENFORCE
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 (force_non_constant(), expr) else ...
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: in/outparameters,codingstylesandmaintenance[was:classproposal]
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
Re: [boost] Is a 3% timing difference reliably repeatable in realcode?
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 caches can easily swamp >> out such a small difference. The version-to-version or step-to-step >> differences in CPU's, memory, compilers, or operating systems can >> cause that much difference in a given program. Differences need to get >> up into the 20-30% range before they are likely to be reliably >> repeatable across different systems. >> >> At least that's been my experience. > >That has not been my recent experience. While working on my current >project (the Safari web browser), we have routinely made 1% speedups >that are measurable and have an effect across multiple machines and >compilers (same basic CPU type and operating system), and we have also >detected 1% slowdowns when we inadvertently introduced them. I notice the examples you give are JavaScript. Greg's example of a virtual machine is written mostly in C, IIRC. I wonder if C++ is more sensitive to compiler differences? For example, some C++ compilers are a lot more aggressive about inlining than others. For some of the code I've timed, a change slowed results for a compiler that failed to inline it, but ran quicker for the compiler that was good at inlining. Makes sense. Boost code stresses compilers in ways that our code doesn't -- the need to be as portable as we are means we don't even use all the features of C89, let alone C++ or C99. And of course C89 doesn't have things like inlining and virtual function dispatch that can vary so much across C++ compilers. Plus we spend a fair amount of time inspecting the output of our compilers and tweaking our C code until we get what we want, and preserving the tweaks in platform-specific macros. The fact remains that it takes a lot of 3% tweaks to make a big difference, so until you know you have the best possible data structures and algorithms there isn't much point, and when there is a point it is painstaking work at the limits of measurability. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is a 3% timing difference reliably repeatable in realcode?
On Thursday, May 8, 2003, at 10:07 AM, Beman Dawes wrote: I notice the examples you give are JavaScript. Sorry I wasn't clear. The examples I gave were speed improvements to a JavaScript interpreter, written in C++. For example, some C++ compilers are a lot more aggressive about inlining than others. For some of the code I've timed, a change slowed results for a compiler that failed to inline it, but ran quicker for the compiler that was good at inlining. Yes. That particular issue, difference in inlining, is a major problem for portability of performance optimizations for C++ code that I've encountered too. -- Darin ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is a 3% timing difference reliably repeatable in real code?
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 version-to-version or step-to-step >> differences in CPU's, memory, compilers, or operating systems can >> cause that much difference in a given program. Differences need to get >> up into the 20-30% range before they are likely to be reliably >> repeatable across different systems. >> >> At least that's been my experience. > >That has not been my recent experience. While working on my current >project (the Safari web browser), we have routinely made 1% speedups >that are measurable and have an effect across multiple machines and >compilers (same basic CPU type and operating system), and we have also >detected 1% slowdowns when we inadvertently introduced them. I notice the examples you give are JavaScript. Greg's example of a virtual machine is written mostly in C, IIRC. I wonder if C++ is more sensitive to compiler differences? For example, some C++ compilers are a lot more aggressive about inlining than others. For some of the code I've timed, a change slowed results for a compiler that failed to inline it, but ran quicker for the compiler that was good at inlining. >I'm not sure, though, if this negates your point, Beman. Something that >gives a 2-3% speedup for one Boost user might not be worth any level of >obfuscation unless we can prove it provides a similar speedup for other >Boost uses. Yes, that's a key point. And of course the 70% gain from a better sort algorithm is the kind of win Boost needs to be alert to. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL CVS still bustificated?
the following fails to compile. Should it? -- #include #include namespace mpl = boost::mpl; typedef mpl::vector v10; typedef mpl::push_back::type v11; -- foo.cpp: In instantiation of `boost::mpl::push_back': foo.cpp:9: base `boost::mpl::push_back_traits >::algorithm' has incomplete type foo.cpp:9: syntax error before `;' token foo.cpp: In function `int main()': foo.cpp:12: `v11' undeclared (first use this function) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] IO Formatting Manipulators
John Torjo wrote:
Sorry for the late reply...
Don't worry about it - I've been kinda busy lately
The library is in great shape!!!
Thanks :-)
I love the idea behind format_traits! formatob as well!
Why did you opt for the .space() function? I think it could have been
included in the .format function? I don't think it was for efficiency...
The .space() function was a legacy of when I only had support for char
types and there was no string support. It is essentially redundant now
that I have character strings support, but I have kept it for compatibility.
I did not put it in the .format() function because that would get confusing.
Question: Should I drop the space options in the formatter?
Wouldn't it be easier if (I think) in formatlist_t, when deriving from:
class formatlist_t: public detail::list_output< FormatType, formatlist_t<
ForwardIterator,
FormatType,
Outputter >, Outputter >
you could derive from something like:
class formatlist_t: public detail::list_output< FormatType, formatlist_t<
ForwardIterator,
some_traits_whatever< FormatType>,
Outputter >, Outputter >
In order to move away from specifically using format_traits? I'll look into
this (another thing on my todo list)! But this is essentially the same as
creating a formatter and supplying that to the manipulator generator.
boost::io::formatter< char > fmt;
fmt.format( '{', '}' );
So, instead of keeping chars, in formatlist_t<..., char> or whatever, you
would ALWAYS keep strings.
I'd like the option -- std::string would perform slower than a string
constant.
I'm looking at supporting std::basic_string types in format_traits (again,
this
is on my todo list).
This way, there would be no need for chars. How 'bout it?
Again with the performance.
---
The formatter generators (formatob) concept is very powerful. Maybe you
could insist more on it on the documentation.
I have been busy lately, so I have not had much time to work on the
documentation. Thanks for the input though.
I am kind of puzzled why you need both formatlistfn and formatob. Could you
enlighten me?
formatlist - list output including containers, sub-lists and arrays
formatob - any basic type (i.e. non-list)
formatlist has several variants:
formatlist - standard list formatting
formatlistex - specify the format type
formatlistfn - list formatting with a specialist outputter
formatlistfn2 - the formatter_t variants (not posted yet)
-- this is to stop compilers complaining about matching the template
arguments
By the way, how about providing an operator << for the STL containers
(vector, list, deque, map, multimap, set) that just does a
'boost::io::formatlist( v )'???
(eventually with a posibility to turn off)
I think it would be helpful, and writing could be straightforward. In case
the user wants more, just use boost::io::formatlist.
Possibly -- wrap it in a preprocessor if statement. Or have it as a seperate
file:
#include
--
I think it's possible to determine, in function boost::io::formatlist, if a
container is associative or not. Therefore, it would simplify writing
maps/multimaps/sets/etc. to streams.
I could dig further to see if it's possible.
Interesting... and more things to do
--
P.S. What did you use to generate the docs? It's really COOL!!!
I used my own XSLT stylesheet; I could e-mail you the source if you want.
It is large, BTW - 236kb zipped!
Thanks for your feedback,
Reece.
_
Get Hotmail on your mobile phone http://www.msn.co.uk/mobile
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ENFORCE
--- Daniel Frey <[EMAIL PROTECTED]> wrote: > 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 absent-mindedly :-) I thought it was > > something like > > > > if (false) ; else > > > > whereas he is really testing for a condition > > > > if(expr)... > > > > However, if you are going to abort at the end (or throw, but I don't > > want to enter in this matter) you can simply replace 'if' with > > 'while': > > But that does not give you any benefit at all, does it? Just that Borland won't warn on BOOST_INVARIANT(false). Admittedly not a big one :-) > The > do-while-idiom is very different from the while-version you suggest. Indeed. I did say that I misread your post. Sorry for the noise. Genny. __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
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 absent-mindedly :-) I thought it was something like if (false) ; else whereas he is really testing for a condition if(expr)... However, if you are going to abort at the end (or throw, but I don't want to enter in this matter) you can simply replace 'if' with 'while': But that does not give you any benefit at all, does it? The do-while-idiom is very different from the while-version you suggest. It's IMHO the only idiom that forces the user to add a semicolon, but we actually don't want to do that here. The user should be allowed to add (i) or other stuff. I think that the 'if' (or 'while', but that's not a difference) is the best we can do here. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: smart assert (was: ENFORCE/betterassertiontechnique)
> > 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 build. > 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? Best, John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
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 ;-) > >Example: >BOOST_ASSERT(i != j)(i)(j); > >or > >BOOST_ASSERT(i > 1000)(i); Oops, no. That's not the problem. The problem is that I read Daniel's reply out of context and too absent-mindedly :-) I thought it was something like if (false) ; else whereas he is really testing for a condition if(expr)... However, if you are going to abort at the end (or throw, but I don't want to enter in this matter) you can simply replace 'if' with 'while': #define BOOST_INVARIANT(expr) \ while /*if*/ (!(expr))\ boost::invariant(), \ std::clog << "invariant failure: " #expr, \ boost::BOOST_INVARIANT_A \ \ /**/ But don't care about that. Had I noticed that there was really a condition I wouldn't have replied. And, then, Borland will find some way to warn in any case :-) >note: see the 'smart assert' thread, where we discuss details about the >interface/ implementation of the smart assert (BOOST_ASSERT) I have no time. And, from the little I've read, I've noticed quite a confusion between exceptions and asserts. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Is a 3% timing difference reliably repeatable in realcode?
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 pursuing 3% tweaks instead of going for 100% breakthroughs. On Thursday, May 8, 2003, at 09:11 America/Denver, 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 version-to-version or step-to-step differences in CPU's, memory, compilers, or operating systems can cause that much difference in a given program. Differences need to get up into the 20-30% range before they are likely to be reliably repeatable across different systems. At least that's been my experience. That has not been my recent experience. While working on my current project (the Safari web browser), we have routinely made 1% speedups that are measurable and have an effect across multiple machines and compilers (same basic CPU type and operating system), and we have also detected 1% slowdowns when we inadvertently introduced them. They add up. Ten 1% speedups result in a 9.5% speedup. It's true that differences in CPUs, memory, compilers, and operating systems can cause huge differences, but that does not mean that changes that make such small increases in performance are therefore not worthwhile. In our project, a 3% speed increase is considered a cause for celebration. I'm not sure, though, if this negates your point, Beman. Something that gives a 2-3% speedup for one Boost user might not be worth any level of obfuscation unless we can prove it provides a similar speedup for other Boost uses. -- Darin PS: On the occasions where you can fix an algorithm in a way that gives a 10x speed increase, or a 25% one, that's even more exciting. To give you an idea of what I'm talking about, here's a log from a week I spent increasing the speed of our JavaScript library: Monday, November 18, 2002 - sped up JavaScript iBench by 70% by using a better sort algorithm and reducing the number of UString allocations - sped up JavaScript iBench by 6% by turning ExecState into a simple object instead of a two level abstraction - sped up JavaScript iBench by 7% by turning the property map into a hash table and improving String instance handling - sped up JavaScript iBench by 6% by hoisting the property map into ObjectImp and doing less ref/unref - sped up JavaScript iBench by 1.5% by converting integers into strings with custom code rather than sprintf Tuesday, November 19, 2002 - sped up JavaScript iBench by 2% by using masking instead of modulus in the property map hash table code - sped up JavaScript iBench by 3% by improving the implementation of the "perfect hashing" hash tables used for static properties - sped up JavaScript iBench by 1.5% by storing computed hash values in the UString representation so we don't recompute them - sped up JavaScript iBench by 6.5% by atomizing property identifiers - sped up JavaScript iBench by 1.5% by not clearing and rebuilding the list each time during sorting Wednesday, November 20, 2002 - sped up JavaScript iBench by 5% by decreasing the amount of ref/deref done by changing interfaces so they can deal directly with ValueImp - sped up JavaScript iBench by 1% by making lists ref/unref less - sped up JavaScript iBench by 7.5% by creating argument list objects only on demand rather than for each function call Thursday, November 21, 2002 - sped up JavaScript iBench by 3% by allocating the ActivationImp objects on the stack rather than in the garbage-collected heap - sped up JavaScript iBench by 11% by turning the scope chain into a singly-linked list that shares tails rather than a non-sharing doubly-linked list with subtly different semantics Friday, November 22, 2002 - sped up JavaScript iBench by 10% by changing the List class from a linked list to a vector, and using a pool of instances ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::lexical_cast("true");
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 >> class lexical_stream_common_stuff > >This could be a possibility. Rather than testing for the strings "true" and >"false" (which wouldn't respect locale), it may be better to set the ios_base >"boolalpha" flag, which reads and writes bool as "true" and "false" (or whatever >is set for the locale). > >However, the question is that some users may want to read/write "0" and "1", >instead. > >This has the same problem as other stream configuration, such as setting the >number base, etc. Sensitivity to the global locale is important, so this would certainly have to be a consideration. However, it is not clear to me that "true" and "false" are necessarily better than "1" and "0" because that result is rarely surprising or awkward in the context of I/O streams. This differs from either precision loss for numerics or whitespace quirks for text types, which are the two obvious exceptions made in lexical_cast at present. Years ago I considered the bool issue, and rejected it the need for such special casing because it felt like more of a "would be nice if" than a "must have" feature. I am not sure that has changed. There are two basic directions in which I intend to evolve lexical_cast that may be relevant here: (1) Formulate the general model of conversion that is used in a way that allows text and numeric types to be considered part of a model rather than exceptions to it. In the past suggestions for lexical_cast have tended to focus on point solutions or have been implementation focused. It is time to tidy up the underlying conceptual model and make it explicit. However, I am not overly keen on adding Boolean types as an additional category that needs to be modelled. (2) Allow some form of parameterisation when converting -- but, just to be clear, this would not result in changes to the core lexical_cast function template or the addition of extra arguments. The motivation for this is the ability to use locales other than the global one, and is something that I have been discussing with Thomas Witt. Handling format- related flags would be a logical extension of this, and might be the way to address any need to work with bool as "true"/"false" rather than "1"/"0". Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Is a 3% timing difference reliably repeatable in real code?
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, memory, compilers, or operating systems can cause that much difference in a given program. Differences need to get up into the 20-30% range before they are likely to be reliably repeatable across different systems. At least that's been my experience. That has not been my recent experience. While working on my current project (the Safari web browser), we have routinely made 1% speedups that are measurable and have an effect across multiple machines and compilers (same basic CPU type and operating system), and we have also detected 1% slowdowns when we inadvertently introduced them. They add up. Ten 1% speedups result in a 9.5% speedup. It's true that differences in CPUs, memory, compilers, and operating systems can cause huge differences, but that does not mean that changes that make such small increases in performance are therefore not worthwhile. In our project, a 3% speed increase is considered a cause for celebration. I'm not sure, though, if this negates your point, Beman. Something that gives a 2-3% speedup for one Boost user might not be worth any level of obfuscation unless we can prove it provides a similar speedup for other Boost uses. -- Darin PS: On the occasions where you can fix an algorithm in a way that gives a 10x speed increase, or a 25% one, that's even more exciting. To give you an idea of what I'm talking about, here's a log from a week I spent increasing the speed of our JavaScript library: Monday, November 18, 2002 - sped up JavaScript iBench by 70% by using a better sort algorithm and reducing the number of UString allocations - sped up JavaScript iBench by 6% by turning ExecState into a simple object instead of a two level abstraction - sped up JavaScript iBench by 7% by turning the property map into a hash table and improving String instance handling - sped up JavaScript iBench by 6% by hoisting the property map into ObjectImp and doing less ref/unref - sped up JavaScript iBench by 1.5% by converting integers into strings with custom code rather than sprintf Tuesday, November 19, 2002 - sped up JavaScript iBench by 2% by using masking instead of modulus in the property map hash table code - sped up JavaScript iBench by 3% by improving the implementation of the "perfect hashing" hash tables used for static properties - sped up JavaScript iBench by 1.5% by storing computed hash values in the UString representation so we don't recompute them - sped up JavaScript iBench by 6.5% by atomizing property identifiers - sped up JavaScript iBench by 1.5% by not clearing and rebuilding the list each time during sorting Wednesday, November 20, 2002 - sped up JavaScript iBench by 5% by decreasing the amount of ref/deref done by changing interfaces so they can deal directly with ValueImp - sped up JavaScript iBench by 1% by making lists ref/unref less - sped up JavaScript iBench by 7.5% by creating argument list objects only on demand rather than for each function call Thursday, November 21, 2002 - sped up JavaScript iBench by 3% by allocating the ActivationImp objects on the stack rather than in the garbage-collected heap - sped up JavaScript iBench by 11% by turning the scope chain into a singly-linked list that shares tails rather than a non-sharing doubly-linked list with subtly different semantics Friday, November 22, 2002 - sped up JavaScript iBench by 10% by changing the List class from a linked list to a vector, and using a pool of instances ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::pool speed tests
At 07:28 PM 5/7/2003, Darren Cook wrote: >Well it was a real-world example and I only applied it to one of the >classes. 2-3% speed boost for only three extra lines of code (header >include, new, delete) is worth having. 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, memory, compilers, or operating systems can cause that much difference in a given program. Differences need to get up into the 20-30% range before they are likely to be reliably repeatable across different systems. At least that's been my experience. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] synchronized with boost::threads?
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 needed threads in C++ as well, I thought of a
> way how to reflect that feature into C++.
>
> It seems to be easy to synchronize variables - see the
> very minimalistic draft below. But what about synchronized
> class methods etc.?
Java synchronized method:
class Foo
{
public synchronized void bar() { /* code */ }
}
Boost.Threads synchronized method:
class Foo
{
public:
void bar() { boost::mutex::scoped_lock lock(m_mutex); /* code */ }
private:
boost::mutex m_mutex;
};
Java synchronized block:
class Foo
{
public void bar() {
synchronized (this) {
/* code */
}
}
}
Boost.Threads synchronized block:
class Foo
{
public:
void bar() {
{
boost::mutex::scoped_lock lock(m_mutex);
/* code */
}
}
private:
boost::mutex m_mutex;
};
> Is it worth to go further into that direction?
>
> I mean, the Boost.Thread library seems to be designed with
> safety in mind, but is still a little bit low-level.
>
> Are there any efforts to enhance the library further?
Yes.
--
William E. Kempf
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
> ... 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 failure, such as SourceForge going bankrupt and shutting down unexpectedly. But it isn't clear what the best procedure is to protect against partial failure - it seemed easier just to restore file-by-file in this particular case. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: smart assert (was: ENFORCE/ betterassertiontechnique)
> 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 build. Sam ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
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 of days - longer than that, we have the daily backups). Actually, it does not involve any people: just create a new list on sourceforge and set up commit emails. Unless disk crashes, nobody is forced to even look at this list. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: synchronized with boost::threads?
Roland Richter wrote: It seems to be easy to synchronize variables - see the very minimalistic draft below. But what about synchronized class methods etc.? Using the scoped_lock on a mutex (like you have done in the example), will work for the entire method. The lock isn't freed until the method exits so you can do as much work as you like in the method, and no other method will execute until that one has executed provided it creates a scoped_lock also. Is that what you mean? Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [type-traits] Patch to alignment_of.hpp for Sun compiler
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 happening with > type_with_alignment_test, I'll be looking into that next). > > While this hides some gross inadequecies of the Sun compiler, We weren't trying to highlight those :), rather to determine if the code in question needs patching regardless of whether Sun can handle or not. It doesn't, so... > I'm all in > favor of getting Boost to compile reliably for users of this platform. > Can someone make this change to the Sun config? Done. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
On Thu, 08 May 2003 15:30:05 +0400, Vladimir Prus <[EMAIL PROTECTED]> wrote: >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 state of everything), then _until I receive >> the informative mail_, I do keep my copy. When I receive the mail I >> know that the duty to keep the files is up to someone else. Of course >> that doesn't protect against failures of the "last committor" machine, >> but... As a further precaution we could advice for keeping a fresh >> checkout for at least one day, regardless of informative mails >> (provided that we can setup something similar). Thoughts? > >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 of days - longer than that, we have the daily backups). However I'm not confident enough into CVS to say if my idea works well with branching (I have my doubts), which can be an advantage of yours. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ENFORCE
> > That's right. But if this will ever get into boost maybe we'll better > use the classical do-while(0). Borland warns on if(false), and > assert(false) is quite common, for instance, in the default case of > switch statements. BOOST_INVARIANT(false) could be used similarly > (Though, depending on the people who would speak in the formal review, > we could choose to have a separate macro for 'assert always'-like > cases, with no condition argument) > Unfortunately, we can't use the do-while(0) idiom, since we don't know when while(0) will be ;-) Example: BOOST_ASSERT(i != j)(i)(j); or BOOST_ASSERT(i > 1000)(i); note: see the 'smart assert' thread, where we discuss details about the interface/ implementation of the smart assert (BOOST_ASSERT) Best, John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ betterassertiontechnique)
> #include
>
> struct Keeper
> {
> Keeper(int) {}
> operator bool() { return false; }
>
> template< class type>
> void log( const type & val, const char * str)
> { std::clog << str << "=" << val; }
> };
>
> template< class type>
> struct log_me_t
> {
> log_me_t( const value & val, const char * str, Keeper & k)
> : m_val( val)
> { k.log( val, str); }
>
> const type & m_val;
> };
>
> template< class type> log_me_t< type> log_me( const type & val, const char
*
> str, Keeper & k)
> { return log_me_t< type>( val, str, k); }
>
> #define BOOST_ASSERT(expr)
> if ( Keeper k=0 ) ; \
> else if ( (expr) ) ; \
> else \
> \
>
> #define v_(x) log_me(x, #x, k).ref
Pardon me, it should be:
#define v_(x) log_me(x, #x, k).m_val
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ENFORCE
On Mon, 5 May 2003 20:12:13 -0700, "Paul Mensonides" <[EMAIL PROTECTED]> wrote: >Daniel Frey wrote: >> Paul Mensonides wrote: >> >>> #define BOOST_INVARIANT(expr) \ >>> if (!(expr)) \ >> >> One possible enhancment: >> >>if( expr ); else >> >> It prevents problems when the macro is used in other >> if-else-structures. > >Thanks Daniel, I forgot about that... That's right. But if this will ever get into boost maybe we'll better use the classical do-while(0). Borland warns on if(false), and assert(false) is quite common, for instance, in the default case of switch statements. BOOST_INVARIANT(false) could be used similarly (Though, depending on the people who would speak in the formal review, we could choose to have a separate macro for 'assert always'-like cases, with no condition argument) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ betterassertiontechnique)
> > Under win32, my assert method uses
> >
> > if (IsDebuggerPresent())
> > {
> > DebugBreak();// ammounts to int 3 on intel
> > }
>
> Maybe that is the 4th alternative I couldn't think of earlier :-). I also
> thought of one more: emailling the system administrator. Useful on
servers.
Indeed ;-)
That's cool!
The thing about emailing the system admin: sure, it's possible.
>
> > which I find better than the debugger catching an exception. At my last
> > work place, we made asserts through exceptions but ended up with
> > exceptions being thrown in destructors and such which wasn't very nice,
> > especially if the destructor was being called during clean up because of
> > a previous exception.
>
> I hadn't thought of such issues. Is uncaught_exception() implemented in
all
> modern compilers? Falling back on one of the other methods when it returns
> true instead of throwing an exception avoids some of the problems.
>
On VC6, uncaught_exception always returns false. Kind of bad :-(
Best,
John
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ better assertiontechnique)
> 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 with gdb but I think
> > it can be set to do the same?)
> >
>
> Under win32, my assert method uses
>
> if (IsDebuggerPresent())
> {
> DebugBreak(); // ammounts to int 3 on intel
> }
>
> (IsDebuggerPresent() is a win32 method to see if a debugger is attached
> to the process)
>
> which I find better than the debugger catching an exception. At my last
> work place, we made asserts through exceptions but ended up with
> exceptions being thrown in destructors and such which wasn't very nice,
> especially if the destructor was being called during clean up because of
> a previous exception.
>
Indeed, you're right. Also, I don't prefer throwing exceptions by default.
But, it's very simple to do so, if this is what you want.
Best,
John
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ betterassertiontechnique)
> >>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 this as well. Here is one option:
>BOOST_PREPARE_ASSERT(int _result=some_lengthy_function());
>BOOST_ASSERT(_result>10)(_result);
>
> I've used something like this in my own assert library, but have never
been
> happy with having a local variable that is only there in debug mode.
>
> How would the v_ macro work?
the PREPARE is an interesting idea.
About the v_ macro, was something very simple, like
#define v_(x) (do_some_print(x, #x))
It should work like this:
BOOST_ASSERT( v_(some_lengthy_function()) > 0);
instead of
BOOST_ASSERT( some_lengthy_function() > 0)( some_lengthy_function() );
I guess it could be implemented like this:
#include
struct Keeper
{
Keeper(int) {}
operator bool() { return false; }
template< class type>
void log( const type & val, const char * str)
{ std::clog << str << "=" << val; }
};
template< class type>
struct log_me_t
{
log_me_t( const value & val, const char * str, Keeper & k)
: m_val( val)
{ k.log( val, str); }
const type & m_val;
};
template< class type> log_me_t< type> log_me( const type & val, const char *
str, Keeper & k)
{ return log_me_t< type>( val, str, k); }
#define BOOST_ASSERT(expr)
if ( Keeper k=0 ) ; \
else if ( (expr) ) ; \
else \
\
#define v_(x) log_me(x, #x, k).ref
This will allow for the v_ macro.
What do you think?
>
> >>If not-idempotent function is given as parameter, it may have
sideeffects
> >>(silly contrived example: pool resource allocator which gets exhausted
in
> >>the middle of assert).
> >
> > I did think (a lot!) about this. But, it's reasonable to assume that
> > functions/ member functions that are called within an ASSERT should all
be
> > constant, because they won't be called at all in release mode.
>
> I'm not convinced that is reasonable, but even if no side effects the
assert
> might take a significant amount of time (e.g. checking an object matches
> what is in a back-end database, or checking a graph has no cycles).
True. So probably adding the v_ macro is a very good idea.
Best,
John
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
Gennaro Prota wrote: > Thanks Aleksey. I was particularly interested to stlport.hpp > (incidentally: though that doesn't affect the good functioning of the > file, the space between # and endif: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/stdl ib/stlport.hpp.diff?r1=1.19&r2=1.20 > > surprises me a bit. Don't call me pedantic, but I'm a curious one :-) > I had seen the colored diff before and didn't notice it. Note that > without the space the line shown in green is, I guess, the following > one, so that's unlikely to get unnoticed when you visually try to > match the #if-s) Have no idea about it. I just restored the copy of the 1.20 revision laying on my hard drive. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] CVS status
John Maddock wrote: > That would be a big help - I have about a dozen changes to the regex-4 > branch that have been lost - and I haven't even begun to figure these out > yet :-( Just in case if you missed it - we have an option of getting access to the 2003-05-07 backup: > Additionally: > If you would like access to the backups from 2003-05-03 (known stable), > 2003-05-06/2003-05-07 (made before your repository was restored to > the known state from 2003-05-03), please let us know; if you believe > (based on work in the past few days) that your repository is generally > clean, we can restore the repository to its state as of this morning > and selectively use the 2003-05-03 backup to fill in any gaps/corruption > that you detect. Please let us know if we may be of further assistance > in this matter. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] smart assert (was: ENFORCE/ better assertion technique)
> > 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 happen at RUNTIME.
>
> 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 with gdb but I think it
can
> be set to do the same?)
>
>2. Boost::test will catch the exception; if I want to test a function
> asserts with bad inputs I can use BOOST_CHECK_THROW.
>
> So I'd like to see three separate actions, and be allowed to switch off
the
> first two (with a compile-time flag).
>
> Given that, I'm wondering if instead of hard-coding two or three actions
> that can be customized if you wouldn't be better allowing any number of
> callbacks to be registered, and then supplying some ready-made callbacks
to do:
>1. logging
>2. user prompting
>3. throw exceptions
Basically, the N actions will be able to be customized (that is, you'll be
able to add your own levels).
What you say, about throwing an exception, also will be possible, since
you'll be able to set a "handler" for each level of assertion.
So, for instance, for assertions with level Debug (default), you can set a
handler that will throw. Just like that! At run-time! (you can leave the
default handler for assertions, that will prompt the user, etc. , or just
set your own, which can throw an exception).
> >
> > 10. specifying all ASSERT's arguments
> >
> > When using BOOST_ASSERT, you should specify all arguments involved in
the
> > assert; otherwise, if the assertion fails, you might not get enough
> > information.
> >
> > Example:
> > // OK - all 3 params have been cared for
> > BOOST_ASSERT( (i > 1) || (j < 0) || (k != i) )(i)(j)(k);
> >
> > // bad - in case an assertion fails, not enough info is outputted!
> > // (k is not outputted)
> > BOOST_ASSERT( (i > 1) || (j < 0) || (k != i) )(i)(j);
> >
> > (compile-time switch, can be on/off; on by default)
>
> I didn't follow this one - are you saying the compiler will complain about
> the bad assert that doesn't include "(k)"? If you could do that you
wouldn't
> need the user to specify the variables at all would you?
Unfortunately, finding out if all of the arguments have been set or not
cannot happen at compile-time. I knew that ;-)
The switch is compile-time, meaning that:
- if on, at RUNTIME, I'll check if all arguments have been specified
- if off, I won't check anything.
Of course, I thought about this, and cannot find a solution that would allow
this checking to happen at the beginning of the program (in other words,
this will happen only the first time the code reaches an ASSERT). Anyway, if
you know of a way, please let me know!
>
>
> > We can have a "fatal error" level, in which case an exception could be
> > triggered.
>
> I thought all asserts should be considered fatal, so as suggested above I
> think BOOST_ASSERT should always throw an exception, and maybe you need
> BOOST_WARNING for non-fatal conditions you'd like logged or to inform the
> user about.
Not true (in my oppinion).
It happens that code might be "over-ASSERTed" (sometimes, some ASSERTs are
not needed). What has happened to me was that I developed some code, and
others have picked up and continued developing it. Some of the initial
constraints have been loosened, therefore, some of the ASSERTs became
unnecessary.
Had such an ASSERT throw, some handler might catch it, and this could go
undetected.
What do you think?
>
> > I'll allow for custom printing of variables (when an assertion fails).
> > ...
> > For instance, for a non-null pointer, you might want to print (some of)
its
> > contents. Or, for an STL container, to print its elements (or at least
its
> > size)
>
> This is interesting; what syntax do you have in mind for using this?
>
> For some types of objects it might be useful to specify a function to call
> if it asserts; I often have a debug_info() function in my classes. E.g.
>BOOST_ASSERT(obj.status()==0)(obj.debug_info())
>
> Will that work if debug_info() returns void?
It should.
I was thinking of a general class, like:
class print_obj
{
// with some specializations
template< class type>
void do_print( const type & val)
{ ...}
};
In case you're wondering why a class and not a function, is because I would
like it to hold context. For example, you might want something like this:
ASSERT( *first != *last)(boost::assert_range)(first)(last);
In case the assertion fails, I could log the whole first-to-last range.
Had the printer been a function, this would have not been possible.
As
[boost] Re: CVS status
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 state of everything), then _until I receive > the informative mail_, I do keep my copy. When I receive the mail I > know that the duty to keep the files is up to someone else. Of course > that doesn't protect against failures of the "last committor" machine, > but... As a further precaution we could advice for keeping a fresh > checkout for at least one day, regardless of informative mails > (provided that we can setup something similar). Thoughts? I think this is a bit more complicated that it should be. Why don't just create boost-wide commit emails mailing list? All changes will be reflected in archives, so in case of emergency you'll have all the data to replay missing commits. Of course, what happens if ml archive is destroyed too as the same time... but that's less likely. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ better assertiontechnique)
Under win32, my assert method uses
if (IsDebuggerPresent())
{
DebugBreak();// ammounts to int 3 on intel
}
Maybe that is the 4th alternative I couldn't think of earlier :-). I also
thought of one more: emailling the system administrator. Useful on servers.
which I find better than the debugger catching an exception. At my last
work place, we made asserts through exceptions but ended up with
exceptions being thrown in destructors and such which wasn't very nice,
especially if the destructor was being called during clean up because of
a previous exception.
I hadn't thought of such issues. Is uncaught_exception() implemented in all
modern compilers? Falling back on one of the other methods when it returns
true instead of throwing an exception avoids some of the problems.
Darren
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] synchronized with boost::threads?
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 needed threads in C++ as well, I thought of a
way how to reflect that feature into C++.
It seems to be easy to synchronize variables - see the
very minimalistic draft below. But what about synchronized
class methods etc.?
Is it worth to go further into that direction?
I mean, the Boost.Thread library seems to be designed with
safety in mind, but is still a little bit low-level.
Are there any efforts to enhance the library further?
- Roland
template class synchronized
{
public:
synchronized( T theValue = T() )
: value( theValue )
{}
void set( const T& theValue )
{
boost::mutex::scoped_lock lock( mux );
value = theValue;
}
T get() const
{
boost::mutex::scoped_lock lock( mux );
return value;
}
private:
T value;
mutable boost::mutex mux;
};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
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 interested to stlport.hpp (incidentally: though that doesn't affect the good functioning of the file, the space between # and endif: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/stdlib/stlport.hpp.diff?r1=1.19&r2=1.20 surprises me a bit. Don't call me pedantic, but I'm a curious one :-) I had seen the colored diff before and didn't notice it. Note that without the space the line shown in green is, I guess, the following one, so that's unlikely to get unnoticed when you visually try to match the #if-s) >and, comparing what is probably the most recent "before-the-disk-crash" CVS >snapshot to the current CVS state, it seems that collectively we've been >able to restore everything. Still, if we have resources for that, may be >it's worthy to set up a backup job somewhere to copy everything off-site, >nightly or so - we might not be so lucky next time. I'm not against that. However, as far as I've understood from the mail that Beman quoted, the sourcefourge people make daily backups anyway. I think what we should have (ideally) is not a daily backup, but a "newest version" backup (if nothing else, the "daily" and "nightly" concepts fail miserably for boost, since we have developers in many different timezones). 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 state of everything), then _until I receive the informative mail_, I do keep my copy. When I receive the mail I know that the duty to keep the files is up to someone else. Of course that doesn't protect against failures of the "last committor" machine, but... As a further precaution we could advice for keeping a fresh checkout for at least one day, regardless of informative mails (provided that we can setup something similar). Thoughts? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::pool speed tests
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 good default. Having all allocators share a single page size is good since it allows them to pool objects of different types together, if their sizes and alignments match. I.e. quick_allocator and quick_allocator can share pools. This helps a lot. > Where I'm going with this is if I know from profiling that typically > my program will peak at using 1000 objects, then I can simply change > the page size to be that big (maybe rounded up to a certain multiple > - does incorrect page size matter much if there is just one > allocation?). Just as I would use reserve() with vector, and just > like that I know it can expand if usage is non-typical. It seems to me that the right way to provide this functionality is to just add a reserve() member function; no need to fake it by changing the page size. But I'm not sure whether it's really worth it. Please experiment with it a bit. It may turn out that preallocation isn't really necessary. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] CVS status
> 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 collectively we've been > able to restore everything. Still, if we have resources for that, may be > it's worthy to set up a backup job somewhere to copy everything off-site, > nightly or so - we might not be so lucky next time. That would be a big help - I have about a dozen changes to the regex-4 branch that have been lost - and I haven't even begun to figure these out yet :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CVS status
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 collectively we've been able to restore everything. Still, if we have resources for that, may be it's worthy to set up a backup job somewhere to copy everything off-site, nightly or so - we might not be so lucky next time. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: dynamic_any
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 implement two operations move_to_xy and move_to_point:
> move_to_xy()(a, 10, 10);
> move_to_point()(a, Point(10, 10)); // ok
>
> But, looking at the single interface bottleneck and less clear
> implementation of supported operations, I prefer to use my-own move()(a,
> 10, 10).
One addition.
I always thought about dynamic_any as a concrete class and I never
considered deriving from it. But you can:
struct moveable
: dynamic_any::any >
{
void move(int x, int y)
{
move_to_xy()(*this, x, y);
}
void move(const Point & point)
{
move_to_point()(*this, point);
}
};
int main()
{
moveable a = get_moveable();
a.move(10, 10);
a.move(Point(10, 10));
}
The problem is closed.
--
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS problem?
On Wed, 07 May 2003 15:54:14 -0400, Beman Dawes <[EMAIL PROTECTED]> wrote: >At 03:30 PM 5/7/2003, Douglas Gregor wrote: > > >Would you mind adding these directories and files back? My checkout is >too > >old to be of use, so we really need those that have the newest files to > >check them back in. Then when others update, they'll see the new files > >and get conflicts if there were any problems with the files already > >re-committed. > >OK, I'll give it a try. Maybe I'm missing something here, but I thought a simple way to cope with this was to post a message on the list asking for people who did commits in the last 3 days. Out of my head, John Maddock is a likely candidate. Even if we don't find a person who checked out a fresh copy of the whole repository still the "union" of all the commits should give the right state (because each people has the newest version of the specific files he committed). No? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: smart assert (was: ENFORCE/ better assertion technique)
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 with gdb but I think
it can be set to do the same?)
Under win32, my assert method uses
if (IsDebuggerPresent())
{
DebugBreak(); // ammounts to int 3 on intel
}
(IsDebuggerPresent() is a win32 method to see if a debugger is attached
to the process)
which I find better than the debugger catching an exception. At my last
work place, we made asserts through exceptions but ended up with
exceptions being thrown in destructors and such which wasn't very nice,
especially if the destructor was being called during clean up because of
a previous exception.
But I don't know if this can be applied to all platforms.
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: smart assert (was: ENFORCE/ better assertiontechnique)
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 this as well. Here is one option: BOOST_PREPARE_ASSERT(int _result=some_lengthy_function()); BOOST_ASSERT(_result>10)(_result); I've used something like this in my own assert library, but have never been happy with having a local variable that is only there in debug mode. How would the v_ macro work? If not-idempotent function is given as parameter, it may have sideeffects (silly contrived example: pool resource allocator which gets exhausted in the middle of assert). I did think (a lot!) about this. But, it's reasonable to assume that functions/ member functions that are called within an ASSERT should all be constant, because they won't be called at all in release mode. I'm not convinced that is reasonable, but even if no side effects the assert might take a significant amount of time (e.g. checking an object matches what is in a back-end database, or checking a graph has no cycles). Darren ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] smart assert (was: ENFORCE/ better assertion technique)
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 happen at RUNTIME. 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 with gdb but I think it can be set to do the same?) 2. Boost::test will catch the exception; if I want to test a function asserts with bad inputs I can use BOOST_CHECK_THROW. So I'd like to see three separate actions, and be allowed to switch off the first two (with a compile-time flag). Given that, I'm wondering if instead of hard-coding two or three actions that can be customized if you wouldn't be better allowing any number of callbacks to be registered, and then supplying some ready-made callbacks to do: 1. logging 2. user prompting 3. throw exceptions Not sure how difficult that is to implement however. Also I cannot think of a 4th thing you'd want to do, so maybe this is not such a good idea. 10. specifying all ASSERT's arguments When using BOOST_ASSERT, you should specify all arguments involved in the assert; otherwise, if the assertion fails, you might not get enough information. Example: // OK - all 3 params have been cared for BOOST_ASSERT( (i > 1) || (j < 0) || (k != i) )(i)(j)(k); // bad - in case an assertion fails, not enough info is outputted! // (k is not outputted) BOOST_ASSERT( (i > 1) || (j < 0) || (k != i) )(i)(j); (compile-time switch, can be on/off; on by default) I didn't follow this one - are you saying the compiler will complain about the bad assert that doesn't include "(k)"? If you could do that you wouldn't need the user to specify the variables at all would you? We can have a "fatal error" level, in which case an exception could be triggered. I thought all asserts should be considered fatal, so as suggested above I think BOOST_ASSERT should always throw an exception, and maybe you need BOOST_WARNING for non-fatal conditions you'd like logged or to inform the user about. I'll allow for custom printing of variables (when an assertion fails). ... For instance, for a non-null pointer, you might want to print (some of) its contents. Or, for an STL container, to print its elements (or at least its size) This is interesting; what syntax do you have in mind for using this? For some types of objects it might be useful to specify a function to call if it asserts; I often have a debug_info() function in my classes. E.g. BOOST_ASSERT(obj.status()==0)(obj.debug_info()) Will that work if debug_info() returns void? Darren P.S. I like everything else you proposed, and the BOOST_ASSERT name is fine. Though if aiming for inclusion in C++ standard in the future maybe SMART_ASSERT or similar is better? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
