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
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(_result10)(_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
[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
[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::anympl::listmove_to_xy, move_to_point
{
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] 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
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
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_allocatorint and quick_allocatorvoid* 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
[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.19r2=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
[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: [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
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: 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
... 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
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
[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] boost::lexical_castbool(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 typename Source class lexical_stream_common_stuffbool, Source 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
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] 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
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
[boost] MPL CVS still bustificated?
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 v11; -- foo.cpp: In instantiation of `boost::mpl::push_backv10, int[11]': foo.cpp:9: base `boost::mpl::push_back_traitsboost::mpl::aux::vector_tag9 ::algorithmv10, int[11]' 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] 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
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] 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] 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
[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] MPL CVS still bustificated?
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 mpl::push_backv10, int[11]::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] 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] 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
