- Boost - lists.boost.org

Re: [boost] [install] The Windows GUI setup (for tools)
by Brian Braatz 25 Jun '05

25 Jun '05

> On Behalf Of Rene Rivera > > Once upon a time I needed to use Boost.Book and Quickbook so I went > through the various steps required to acquire and install enough of the > files to get that working on Windows. I vowed to put my efforts into an > installer so that others would not go through the same pain. So I made a > quick installer with my favorite install maker InnoSetup. Which I've > periodically updated, but haven't widely published it's location. I've > now made it more accessible as a release in the Boost-Sandbox project > (and because the vault has size limits): > > http://sourceforge.net/project/shownotes.php?release_id=337287 > [Brian Braatz Writes:] Thank you for sharing that (!!!!). (downloading now). I still cant build wave (haven't had the time to troubleshoot), and appreciate the pre-built library :) Do you have any future plans for this component? Thanks again, Brian

1 0

Re: [boost] [serialization] a proposal for an alternative to the new c
by JOAQUIN LOPEZ MU?Z 25 Jun '05

25 Jun '05

Hello Dave, ----- Mensaje original ----- De: brangdon(a)cix.compulink.co.uk (Dave Harris) Fecha: Sábado, Junio 25, 2005 2:37 am Asunto: Re: [boost] [serialization] a proposal for an alternative to the new c > In-Reply-To: <42BBC406.1A3FB240(a)tid.es> > joaquin(a)tid.es (=?iso-8859- > 1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?=) > wrote (abridged): > > The hardest part is checking for equality. My proposal is > > to follow a hash-based approach, which is effective both in > > terms of complexity and space (one word per tracked object.), > > and does not impose any special requirement on the serialized > > objects (for instance, an approach based on operator== would > > require that objects be equalitycomparable). > > [...] > > if(hash_addr!=0){ > > boost::hash_combine(*hash_addr,x); > > } > > Why do we need the test against 0? Is it supposed to improve > performance? > Hashing ought to be cheap - it is just bit-twiddling on primitives > - and > conditional branches are relatively expensive. It may be quicker > to always > hash. Well, the proposed pseudocode is only meant to illustrate the idea, certainly it could prove faster to hash unconditionally. > > It might be worth using #ifndef _NDEBUG or similar, though. > Yes. As this is merely a protection against incorrect user code, one should be able to turn it on/off or at least have it only in debug mode, much in the same way as the safety checks done by some STL implementations. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[any] More conversion flexibility?
by Falcon 25 Jun '05

25 Jun '05

There are two things I need for a project I'm currently doing. I'm curious if anyone thinks this could be added to the package boost.any, either in the class boost::any or as a separate class, as well as whether it would be of use to anyone else. :) 1. Implicit conversions to/from pointers and references. 2. Support for user-defined conversion hooks when using any_cast. These would be defined in terms of the contained type, not the converted-to type. Both are possible (I've already done it), but will have a runtime performance impact: * Two additional [inline] function calls and two comparisons per conversion, even if the types are the same. * Additional memory overhead to store information about the type (about sizeof(pointer)*6 per instance of boost::any). * Storage of user-defined conversions (in function pointers or function objects). Comments appreciated, Peregrine Falcon

1 0

[date_time]Streaming bugs
by Martin 25 Jun '05

25 Jun '05

1. The date_time library in the currenct CVS doesn't follow the standard formatted input/output requirements in the C++ standard. e.g. stringstream s("205-Jan-01"); date d; s >> d; will throw "Year out of valid range" exception instead of just setting the badbit. The resolution is to use the sentry object and catch exceptions: template <class charT, class traits> inline std::basic_istream<charT, traits>& operator>>(std::basic_istream<charT, traits>& is, date& d) { std::basic_istream<charT, traits>::sentry cerberos(is, false); if (cerberos) { std::ios_base::iostate status = std::ios_base::iostate (std::ios_base::goodbit); try { ... //use facet and set status if failed } catch (...) { is.setstate(std::ios_base::badbit); } if (status) is.setstate(status); } return is } --------------- 2. The default date format is "%Y-%b-%d" which is very confusing since it is using a date order that is not common in english speaking countries while it uses english month names. The default format should be "%x". (I know this will create problems with input parsing on some STL libraries but I think it is a better than the current solution where almost nobody can use the default). --------------- 3. The streaming functions all add a new facet to the locale if no current facet has been imbued. Wouldn't it be better to either have a singleton "default" facet for all streams or imbue the facet to the global locale instead?

2 1

Re: [boost] [mpl][tru64cxx] set failing
by JOAQUIN LOPEZ MU?Z 25 Jun '05

25 Jun '05

Hi Dave ----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Sábado, Junio 18, 2005 9:58 pm Asunto: Re: [boost] [mpl][tru64cxx] set failing > "JOAQUIN LOPEZ MU?Z" <joaquin(a)tid.es> writes: > > > mpl::set is currently failing > > > > http://tinyurl.com/9qzuh > > Because the component is broken and I checked in a testcase that shows > it to be broken. > I don't think this has to do with your newly checked testcase: the problem also shows outside MPL test suite: http://tinyurl.com/8vdtj Besides, last COMSOFT regression cycle is older than your commit. Joaquín M López Muñoz Telefíonica, Investigación y Desarrolo

6 26

Re: [boost] [serialization] a proposal for an alternative to the new c
by brangdon＠cix.compulink.co.uk 25 Jun '05

25 Jun '05

In-Reply-To: <42BC96BD.90901(a)dcook.org> darren(a)dcook.org (Darren Cook) wrote (abridged): > > Admittedly, hash-based checking is not 100% safe, ... > > I think this is unacceptable. If I have two objects A and B, and they do > happen to hash to the same value, then B won't get saved. However good > the hash code is does not matter: this would stop me using the > serialization library in anything mission critical. As I understand it, this hashing does not change the semantics of correct client code, or change what is stored in anyway. It merely provides a check for buggy client code. Specifically, client code which either changes an object while serialisation is in progress, or even worse, which serialises two distinct objects at the same address - those things are unsupported. The hashing doesn't detect all such mistakes, but it should detect a high percentage of them. When it does so, it flags a run-time error. It doesn't use the hash to decide whether to store the object, or otherwise try to work around the mistake. The hash value itself is never stored. Arguably it should assert. In fact, if I understand correctly, the hashing framework could be conditionally compiled out with _NDEBUG or similar. Have I got this right? I can also see some value in always calculating the hash, and storing it in the archive and using it to check integrity when loading it back in - but I don't think that was the original intention. Also it's not clear what should happen with pointer values, which probably won't hash consistently between runs. -- Dave Harris, Nottingham, UK.

2 1

performance test between boost::signals and sigc++-2.0
by Christophe Prud'homme 25 Jun '05

25 Jun '05

Dear Boosters I am using quite intensively boost::signals but I noticed a relatively high cost. I wrote a small test program that confirmed it with a comparison to sigc++-2.0. The code has been compiled with g++-3.3 -O3 and this is a very recent boost cvs snapshot(compiled in release mode). It was run on a Debian(sid)/GNU/Linux ibm thinkpad T40p (pentium M) I vary the number of slots (0 to 4) and calls and I have a dummy slot class and a less dummy slot class to test with. here are the timings: ================================================================== call dummy::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0 0 nan 0 10000 0 0 nan 0 100000 0.05 0 inf 0 1000000 0.5 0.01 50 0 10000000 4.95 0.11 45 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.01 0.01 1 1 100000 0.1 0.02 5 1 1000000 1.08 0.14 7.71429 1 10000000 10.55 1.34 7.87313 2 100 0 0 nan 2 1000 0 0 nan 2 10000 0.02 0 inf 2 100000 0.14 0.02 7 2 1000000 1.45 0.14 10.3571 2 10000000 14.6 1.46 10 3 100 0 0 nan 3 1000 0 0 nan 3 10000 0.02 0 inf 3 100000 0.19 0.01 19 3 1000000 1.84 0.15 12.2667 3 10000000 18.44 1.53 12.0523 ================================================================== call A::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0.01 0 inf 0 10000 0 0 nan 0 100000 0.05 0 inf 0 1000000 0.48 0.01 48 0 10000000 4.87 0.11 44.2727 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.02 0 inf 1 100000 0.12 0.01 12 1 1000000 1.15 0.22 5.22727 1 10000000 11.46 2.17 5.28111 2 100 0 0 nan 2 1000 0.01 0 inf 2 10000 0.01 0.01 1 2 100000 0.16 0.03 5.33333 2 1000000 1.61 0.32 5.03125 2 10000000 16.17 3.14 5.14968 3 100 0.01 0 inf 3 1000 0 0 nan 3 10000 0.02 0 inf 3 100000 0.21 0.04 5.25 3 1000000 2.09 0.41 5.09756 3 10000000 20.83 4.06 5.13054 Am I using boost::signals the wrong way? has boost::signals some added features that reduce its performance ? I apologize in advance if it has already been discussed before but I didnot find a relevant discussion in the archives or on google. I found some feature comparison here http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html For my application the number of calls are typically between 1e6 and 1e8 with a few slots (1 to 10 ). The cost of boost::signals framework is quite high. Best regards C. -- Christophe Prud'homme Office MA B2 534 CMCS-IACS EPFL CH-1015 Lausanne, Switzerland Tel: +41 (0)21 693 25 47 Fax: +41 (0)21 693 43 03

4 3

Re: [boost] [serialization] a proposal for an alternative to the new c
by brangdon＠cix.compulink.co.uk 25 Jun '05

25 Jun '05

In-Reply-To: <42BBC406.1A3FB240(a)tid.es> joaquin(a)tid.es (=?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?=) wrote (abridged): > The hardest part is checking for equality. My proposal is > to follow a hash-based approach, which is effective both in > terms of complexity and space (one word per tracked object.), > and does not impose any special requirement on the serialized > objects (for instance, an approach based on operator== would > require that objects be equalitycomparable). > [...] > if(hash_addr!=0){ > boost::hash_combine(*hash_addr,x); > } Why do we need the test against 0? Is it supposed to improve performance? Hashing ought to be cheap - it is just bit-twiddling on primitives - and conditional branches are relatively expensive. It may be quicker to always hash. It might be worth using #ifndef _NDEBUG or similar, though. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] [serialization] a proposal for an alternative to the newconst-saving rule
by JOAQUIN LOPEZ MU?Z 24 Jun '05

24 Jun '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Viernes, Junio 24, 2005 3:49 pm Asunto: Re: [boost] [serialization] a proposal for an alternative to the newconst-saving rule > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: > > > The new rule introduced in Boost.Serialization that forbids saving > > of non-const objects has proved a little controversial. My point of > > view is that the rule, albeit far from perfect, provides some > > level of safety against hard to track errors. Others' opinions > differ.> > > The current rule is a rough approximation to what IMHO would > > constitute the right enforcement: everytime a trackable object > > is saved, check wether an object with the same address has been > > previously saved and, if so, make sure that the object didn't > change. > I don't understand what bugs this is going to catch. Certainly in > this case, > > for( ... > X x(... ); > ar << x; > > the low-level problem isn't that x is changing, but that it's a > different object each time. Of course. > Two temporally different x's might well > be identical. Yes, but saving the same unchanged object twice, which is perfectly legal, passes the hash test, so the rule admits all valid cases and detects at least some of the invalid ones --in practice, most of them, actually. > > But all of this misses the high-level problem: the author of the code > doesn't know what he's doing. You simply can't serialize objects from > distinct scopes with tracking into the same archive, because there may > be aliasing. Totally agreed, this is what we are trying to detect in order to protect the author of the code. > And there's nothing we can reasonably do to detect that > problem when the aliased objects have the same type Nothing? I'm afraid I don't get you. A perfect aliasing detection mechanism is probably impossible to implement, but the hash test at least approximates it. This is better than providing no safety mechanism, as I understand you advocate. Or put another way: if the hash test fires the alarm, we are *sure* the user's code was incorrect. And if the user's code is correct, the hash test will pass. If you allow me to draw an analogy, this is similar to primality testing in maths: a 100% accurate primality test is complexity-wise unfeasible, but many statistical tests are fast, do not yield false negatives and get most of true negatives right. Am I being too cryptic? Sometimes my English skills play tricks on me. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

boost/mpl/numeric_cast.hpp
by Gennadiy Rozental 24 Jun '05

24 Jun '05

error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format

4 3