June 2005 - Boost - lists.preview.boost.org

[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

State machine framework with dynamic configurability
by David Abrahams 24 Jun '05

24 Jun '05

Cross-posted from c.l.c++.m: -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 3

documentation doesn't build anymore
by Peter Simons 24 Jun '05

24 Jun '05

I can't build the "doc/" directory of the current boost CVS version any longer: budweis:/usr/local/src/boost-current/doc$ bjam --v2 /usr/local/src/boost-current/tools/build/v2/build/feature.jam:193: in feature.attributes from module feature error: "<link-runtime>" is not a valid feature name /usr/local/src/boost-current/tools/build/v2/build/property.jam:409: in property.translate-paths from module property [...] Am I the only one who has that problem? Is there a simple fix, maybe? Any ideas, anyone? Peter

4 10

[Test] [All Library Developers] multiple definitions
by David Abrahams 24 Jun '05

24 Jun '05

I just tried to compile something with the test library and two translation units. Boom! It was this definition, which appears in boost/test/impl/execution_monitor.ipp. signal_handler* signal_handler::s_active_handler = NULL; //!! need to be placed in thread specific storage I can hardly blame Gennadiy, though, having made this mistake myself many times. The reason I noticed this was that I have just started a simple practice that should root out these problems in my own code: I build a program that #includes all my headers in two translation units. For example: // ---- main.cpp ---- #include <boost/python.hpp> extern int f(); int main() { return f(); } // ---- main.cpp ---- #include <boost/python.hpp> int f() { return 0; } Presto! Instant linker errors pointing me at offending definitions. Every library should include a test like the one above. You may be wondering how to work around these issues when you really need header-only capability and can't stick the definition in a source file. In this case, the fix was easy: since the variable in question is a static member, just refactor it into a templated base class. class signal_handler; template <int = 0> struct signal_handler_ { static signal_handler* s_active_handler; }; class signal_handler : signal_handler_<> { ... }; //!! need to be placed in thread specific storage template <int N> signal_handler* signal_handler_<N>::s_active_handler = NULL; When you need a namespace-scope variable, things get a bit more interesting. You might consider sticking one in an unnamed namespace, but then you run a great risk of violating the One Definition Rule (see 3.2 in the standard) when identical template specializations and inline functions that use the variable are instantiated and use distinct objects in two translation units. Boost.Bind's placeholders have this problem. The answer is to initialize a *reference* in the unnamed namespace to a single, common object: namespace whatever { class foo {}; template <class T, int = 0> struct unique_instance { T& get() { static T x; return x; }; }; namespace { foo& bar = unique_instance<foo>::get(); } } -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 10