- Boost - lists.boost.org

Re: Re: FSM review
by Dave Gomboc 15 Mar '05

15 Mar '05

> Rejection is not permanent. If a library has flaws and they > are substantial enough then it should be rejected so that > when changed, it can be reviewed again. > > I would like to see a state chart lib in boost but not as it > currently stands. I would not mind if it was accepted as > *beta* which would tell users that it has caveats. Given that the author has already had almost an entire year's notice on this issue, I think giving the current library some sort of "beta" status would be a mistake. This issue won't be resolved one way or the other until a) the review manager ignores the entirely reasonable expectation of constant-time state dispatch, and accepts the library into Boost anyway, or b) the existing code is changed to support constant-time dispatch, perhaps under certain constraints (e.g. when one doesn't use certain features), or c) code is added to the library that converts the specified machine during compilation into something that dispatches in O(1) (e.g. by an algorithm that converts M: S* x T -> S* into M': S' x T' -> S). If c) is the route chosen, whether to invoke this procedure could be made selectable by the user so that one can choose between a) minimizing compile-time (and minimizing risk of encountering compiler limitations, if such a risk exists), and b) maxmizing the performance (and optionally, minimizing the memory footprint) of the state machine at runtime. Dave

1 0

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 15 Mar '05

15 Mar '05

In-Reply-To: <d11prg$uvt$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > Well, we did discus the type of review before it started, and nobody > raised any objections. That's partly because it sounded like the interface was fixed and known good. Where-as we are now agreed that hash_range is going to take at least one additional parameter and possibly be renamed (to hash_combine) and the return type maybe changed to void; so the interface is not fixed. Had I known that I might have objected to the fast-track, but the only way to know it would be to actually review the proposal. Maybe if we are in a hurry we should delete hash_range and hash_combine from the initial official interface, while still using them for the implementation. That would enable the containers to move forward. > On a related note, I am going to be requesting a review for the > unordered associative containers soon. It has been suggested that since > they are based on TR1 they should have a shorter than normal review > (but longer than this one). So I guess you think it should have a full > length review? I have no idea. I am less interested in the containers than in the hashing. I don't think I've ever implemented a hashing container in C++. I don't currently plan to contribute to the containers review. -- Dave Harris, Nottingham, UK

2 1

Re: [boost] [review] hash functions
by brangdon＠cix.compulink.co.uk 15 Mar '05

15 Mar '05

In-Reply-To: <002901c527e7$9f9fb620$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > The problem is that hash functions vary wildly in quality. Leaving the > default function unspecified (or implementation defined) is good if you > are lucky and the implementation you happen to use is good. It's a > tradeoff. I think if we provide a good quality default implementation, and also a good rational (and the rational is important here), then vendors are unlikely to change it to something worse. Vendors avoid unnecessary work. The eventual standard could recommend a specific implementation in a non-normative Note. > A fixed and predictable default means that you don't have to measure > the quality of the hash function for every implementation to which you > port your program. Your original tests are still valid. In general, performance varies between platforms. If one implementation has the fixed string optimisation and the other doesn't, my benchmarks for one will not apply to the other. I am not yet convinced that hashing deserves to be a special case. On the other hand, it does seem to be an area which can benefit from innovation. Eg a platform may have a super-fast near-cryptographic-strength algorithm implemented in hardware, and we're saying they can't use it? > The other side of predictability - that the hash function is not > affected by types or the particular representation of a sequence of > values - means that you don't necessarily have to re-run the > performance benchmark of your unordered_maps when you refactor the key > to use int[3] instead of struct { short, short, short }, or a wstring > instead of a string. I think you need to repeat your benchmarks anyway. You may find that values which used to fit in cache no longer do so. Or vice versa. If you are hashing pointer values then the collisions will vary from one run of the program to the next. Even if you can get stability for some set of program edits, there will always be other edits which don't get it. Reordering the hash_combines, or refactoring an object's state, for example. -- Dave Harris, Nottingham, UK

2 1

Re: [boost] Re: [review] hash functions
by brangdon＠cix.compulink.co.uk 15 Mar '05

15 Mar '05

In-Reply-To: <d1409a$kc1$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > Think about how such a class would be stored in the proposed unordered > associative containers. If you use unordered_set<base*> then the hash > function will be called for the pointer, not the class. I imagine you would use a hasher which dereferenced the pointer. template<typename T> struct hash_ptr { size_t operator()(const T *p) const { return hash_value( *p ); } }; And perhaps this should be included in boost too? Eg this: unordered_set< shared_ptr<MyType>, hash_ptr<MyType> > looks reasonable to me. > If Thorsten writes ptr_unordered_set<base> then there might be a > problem with boost::hash<base>. Although it will equally apply to > std::equal_to<base>. Absolutely. In general when writing hash_value() you need to look at the corresponding equality operator. For example: bool Derived::operator==( const Base &base ) const { if (Base::operator==( base )) if (const Derived *p = dynamic_cast( const Derived * >(&base)) if (m_value == p->m_value) return true; return false; } Ideally we look at this and we decide there ought to be something in the hash_value which corresponds to the dynamic_cast. But what? We can try using hash_value( typeid(*this) ). However, that will be relatively slow and may not give good results, depending on how it is implemented. We could use our own type IDs, but allocating them is tricky. So it is tempting not to bother, and instead use: size_t Derived::hash_value() const { // return combine_hash( Base::hash_value(), m_value ); size_t hash = Base::hash_value(); combine_hash( hash, m_value ); return hash; } which is correct, but will produce more collisions than if we'd used the typeid. If hash_value( m_value ) yielded different results for different types of value, then the number of collisions would be reduced. The stability requirement compromises the quality of hashing. -- Dave Harris, Nottingham, UK

3 2

Re: [Boost-testing] Re: [test] numerous tests broken
by Caleb Epstein 15 Mar '05

15 Mar '05

On Tue, 15 Mar 2005 11:44:51 -0500, Gennadiy Rozental <gennadiy.rozental(a)thomson.com> wrote: > > errors_handling_test > > ifstream_line_iterator_test > > test_fp_comparisons > > test_tools_test > > Most of this test/compiler combination should pass. Failures caused by some > mix-up between test, Boost.Build and configuration file. I did not have a > time to localize the issue. I don't understand this answer. Are you saying the problem is fixed or you haven't yet had time to investigate it? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Logo: version for candidate libs
by rasmus ekman 15 Mar '05

15 Mar '05

When the winning logo is selected, ask the designer to please create a version with the word "Candidate" stamped over or just below. It could also be somewhat greyed-out or whatever. This logo may be used in docs for libraries at all steps until acceptance; the Boost logo should be reserved for acccepted libs. (sorry if already suggested - haven't read all posts) re

2 2

Re: FSM Review
by Johannes Brunen 15 Mar '05

15 Mar '05

David B. Held and Paul A Bristow wrote: >> It will be a sad day when Boost rejects a good library because >> another library in a different part of the design space is >> theoretically faster. > IMO this hits the nail on the head. > As with too many reviews, there have been very interesting, > but essentially speculative, alternative ideas, > produced not during the 'proposed library' development phase, > but somewhat destructively and at the 'last minute'. > > These should not be a reason for rejection, > but should spur development of different > (and hopefully in some ways better) ideas to submit in future. I would like to second that. With best regards Johannes Johannes Brunen DataSolid GmbH Nobelstr. 3-5 41189 Mönchengladbach Tel.: 02166 / 955 789 Email: JBrunen(a)DataSolid.com Internet: www.DataSolid.com ____________ Virus checked by G DATA AntiVirusKit Version: AVK 15.0.3667 from 15.03.2005 Virus news: www.antiviruslab.com

1 0

Re: [boost] Re: Sockets: proposal for a library design
by Willam Lee 15 Mar '05

15 Mar '05

A C++ framework for network is very useful and long for. I have seen the ACE, but felt it too weight. The proposed library seems a lightweight one and the socket wrapper is appropriate. I think if user manage the sockets one by one, the proposed library will work perfectly. But in common network applications, a server usually serves on several sockets or ports with a select() style function. In this condition, how to process multiple socket class for different connection the proposal ? In the pseudo code, select() function is a member function of socket, maybe it can only process the 'this' socket. Finally I don't like build socket lib based on iostream, but the net lib can provide some operator like "<<" , ">>" to simulate the iosteam-style calling. Thanks Boris's work. best regards William Lee _________________________________________________________ Do You Yahoo!? 150万曲MP3疯狂搜，带您闯入音乐殿堂 http://music.yisou.com/ 美女明星应有尽有，搜遍美图、艳图和酷图 http://image.yisou.com 1G就是1000兆，雅虎电邮自助扩容！ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_…

3 2

boost::begin/end disappeared?
by Caleb Epstein 15 Mar '05

15 Mar '05

A number of regression tests failed today on gcc-3.4.3+ (both mine and Martin Wille's runs) for failure to find boost::begin and boost::end. I'd suspect something changing in the Range library, but nothing looks obivous. Anyone? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[test] numerous tests broken
by Caleb Epstein 15 Mar '05

15 Mar '05

This has been happening for several days. A number of the Boost.Test regression tests are failing across most/all platforms: http://www.meta-comm.com/engineering/boost-regression/cvs-head/developer/te… errors_handling_test ifstream_line_iterator_test test_fp_comparisons test_tools_test Gennadiy? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0