- Boost - lists.boost.org

Re: [boost] Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 0:52 am Asunto: [boost] Re: [review] hash functions > Alberto Barbati <abarbati(a)iaanus.com> writes: > > > Ah! And there's one more case in which we are helpless, although > I'm > > curious to see an implementation that exploits such latitude: > the > > wording used in the standard does not guarantee that the mapping > from > > pointers to integers always produce the same value over time. In > other > > words: > > > > char* p = new char; > > size_t i1 = reinterpret_cast<size_t>(p); > > size_t i2 = reinterpret_cast<size_t>(p); > > assert(i1 == i2); // ??? > > char* q1 = reinterpret_cast<char*>(i1); > > char* q2 = reinterpret_cast<char*>(i2); > > assert(p == q1 && q1 == q2); > > > > The standard guarantees that the second assert passes, but says > nothing > > about the first assert. > > There are other cases too. reinterpret_cast could map all > pointers to > the same integer. If you allow me to be a little pedantic, this is not the case. reinterpret_cast<> guarantees back conversion, so it can't possibly map every pointer into the same integer. As for the rest of your argument, I agree 100%. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

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

13 Mar '05

In-Reply-To: <007e01c52597$b62c1980$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > pair<int, int>, int[2], struct { int a; int b; } are different > representations of the same thing; it is not strictly necessary for > them to use the same algorithm, but it's desirable and will eliminate a > source of confusion and mistakes. Really? What kind of mistakes? In my experience, if you want two different things to hash the same, you need to write their hash functions with that in mind. It is a special case which justifies not using the default hash function. > void hash_range( size_t & seed, It first, It last ); > > should this function be added. You are welcome to spell the above as > > size_t hash_range( size_t seed, It first, It last ); I am also tempted by: size_t hash_range( It first, It last, size_t seed=0 ); perhaps replacing the 0 with some other default value. So people can ignore it if they don't need it. But doesn't this mean that hash_value( pair<int,int> ) also needs a seed argument, if you want it to match hash_range( int[2] ) ? -- Dave Harris, Nottingham, UK

2 2

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

13 Mar '05

In-Reply-To: <d0vsa6$bkm$1(a)sea.gmane.org> abarbati(a)iaanus.com (Alberto Barbati) wrote (abridged): > 2) provide the hash function (with reintepret_cast<>) only for those > platforms that we are able to check in advance that will satisfy those > requirements and make any use of such function produce a static assert > for all other platforms In the case of (2), the platform may provide another implementation which can be used. For example, perhaps the pointers are segment+offset and the offset part is suitable. In my view, boost should be allowed to vary the implementation of the hash functions to suit the local platform. One interesting case is compacting garbage collectors. These already have problems with std::less() and I'd rather not make things worse by over-specifying hashing. -- Dave Harris, Nottingham, UK

1 0

Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Domingo, Marzo 13, 2005 2:18 pm Asunto: Re: [boost] [aligned_storage][repost] problems with GCC 4.0.0 20050309 > JOAQUIN LOPEZ MU?Z wrote: > > The class aligned_storage in boost/aligned_storage.hpp has > > the following decl: > > > > template < > > std::size_t size_ > > , std::size_t alignment_ = std::size_t(-1) > >> > > class aligned_storage; > > > > GCC 4.0 complains about the default value for aligmnent_ saying > > that: > > > > '(size_t)((-1))' is not a valid template argument for type > > 'unsigned int' because it is a non-constant expression > > > > which is ruining some of the regression tests. > > Is GCC right or shall I submit a bug report at gcc.gnu.org/bugzilla? > > I don't see anything in the standard or in the issue lists that > prohibits > size_t(-1) as an integral constant expression. Bug report. > Alas, I tried to isolate this into a simple snippet #include <cstddef> template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1)> class aligned_storage { }; int main() { aligned_storage<1> as; } but then the problem goes away. Would some kind soul with access to GCC 4.0.0 care to take a look at this? The actual problem is shown at: http://tinyurl.com/4hxy5 Thank you very much, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 13 Mar '05

13 Mar '05

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Domingo, Marzo 13, 2005 4:52 am Asunto: [boost] Re: [review] hash functions > JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> writes: > > > ----- Mensaje original ----- > > De: David Abrahams <dave(a)boost-consulting.com> > > Fecha: Domingo, Marzo 13, 2005 0:52 am > > Asunto: [boost] Re: [review] hash functions > > > >> Alberto Barbati <abarbati(a)iaanus.com> writes: > >> > >> > Ah! And there's one more case in which we are helpless, > although > >> I'm > >> > curious to see an implementation that exploits such latitude: > >> the > >> > wording used in the standard does not guarantee that the > mapping > >> from > >> > pointers to integers always produce the same value over time. > In > >> other > >> > words: > >> > > >> > char* p = new char; > >> > size_t i1 = reinterpret_cast<size_t>(p); > >> > size_t i2 = reinterpret_cast<size_t>(p); > >> > assert(i1 == i2); // ??? > >> > char* q1 = reinterpret_cast<char*>(i1); > >> > char* q2 = reinterpret_cast<char*>(i2); > >> > assert(p == q1 && q1 == q2); > >> > > >> > The standard guarantees that the second assert passes, but > says > >> nothing > >> > about the first assert. > >> > >> There are other cases too. reinterpret_cast could map all > >> pointers to > >> the same integer. > > > > If you allow me to be a little pedantic, this is not the > > case. reinterpret_cast<> guarantees back conversion, so it can't > > possibly map every pointer into the same integer. > > 4 A pointer can be explicitly converted to any integral type large > enough to hold it. The mapping function is implementation-defined > [Note: it is intended to be unsurprising to those who know the > addressing structure of the underlying machine. ] > > 5 A value of integral type or enumeration type can be explicitly > converted to a pointer. 64) A pointer converted to an integer of > sufficient size (if any such exists on the implementation) and back > to the same pointer type will have its original value; mappings > between pointers and integers are otherwise implementation-defined. > > There's no guarantee that the integer type will have sufficient size. OK, with that provision in mind I buy your thesis now. > > > As for the rest of your argument, I agree 100%. > > Now you agree with all of it ;-) > (I hope) > Definitely! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[review] hash functions
by Thorsten Ottosen 13 Mar '05

13 Mar '05

Dear All, It's a pleasure to announce that the review of Daniel James' hash functions library starts today (8th of March) and ends the 12th of March. The library is fairly small and can be seen as an extension to boost.functional. Therefore the review is a fast-track review. >From the introduction of the library: "boost::hash is an implementation of the hash function object specified by the C++ Standard Library Technical Report. It is being proposed as an addition to Boost.Functional" "The hash functions have several possible uses, but the main intention of boost::hash is for indexing a hash table such as the unordered associate containers in the Technical Report, or the hash index for the Boost Multi-Index Containers Library. A hash table stores its values in buckets which are numbered by their keys' hash values. Given a key, the bucket the object lies in can be quickly found be calculating its hash value and looking in the corresponding bucket. This requires the hash function to be fast - since the point is to find the object quickly. Collisions need to be minimised, to reduce the number o objects in each bucket, and thus the number of comparisons required to find objects in a bucket." . If you decide to do a review, please follow the guidelines described in http://www.boost.org/more/formal_review_process.htm#Comments The library can be downloaded from http://boost-sandbox.sourceforge.net/vault/index.php?directory=Hash best regards Thorsten, review manager -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

12 48

Re: [boost] Re: FSM Review
by 辉李 13 Mar '05

13 Mar '05

Hi all, I'm a new guy in boost list. --- Alexander Nasonov <alnsn(a)yandex.ru> wrote: > Because classical approach to implement POAManager > and the like > is not overly complex and because no special skills > are needed, > new library should have several advantages (to give > answers to problems > 1-3, at least) and it should have very clear and > easily understandable > model. > Tutorial of this library should describe how to > solve typical problems > of classical approach. > Support Alexander's opinion., I have seen the tutorial of FSM library, I think the tutorial is too UML-style. As I know FSM has been used widely before UML become popular. Some classical usage of FSM have simple state transfer and action style, but has many states. The tutorial should give some examples in the classical style, or we should call this library boost::FSM::UML-style. The performance of FSM is very important for some application with simple usage of FSM. When using a FSM lib, the user of this kind of FSM should not pay the loss in performance for the functions they don't need. If the trade between performance and functionality can not satisfy some FSM users in this design, maybe the boost can accept this library but should provide an opportunity for accept other design of FSM with high performance but some simple functionality. 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_…

1 0

Reporting non-fatal errors in Boost libraries
by Aaron W. LaFramboise 13 Mar '05

13 Mar '05

Most of the time when a library routine encounters an error, that error is fatal, and the proper course of action is fairly obvious: throw an exception, return a singular value, or similar. However, in some cases, we encounter errors that are non-fatal, and simply giving up is not the most appropriate course of action. The error encountered may be inconsequential to successful completion, or we may have gotten notification of the error too late for it to make a difference, or design considerations may prevent us from terminating. A common example is encountering an unrecoverable error in a destructor while closing a file. These errors must be reported. However, without making special provisions for doing so, its unclear exactly how to report them. As we're in code for generic libraries, suggestions such as printing to std::cerr are clearly unacceptable. We also want to avoid encumbering the library interface with error-handling clutter that may never be used. How should Boost libraries be designed so as to allow these errors to be reported? Do existing Boost libraries have problems with these situations, and if so, how have they solved it? Aaron W. LaFramboise

4 5

To whomever modified Boost Web Site index.htm last time, and didn't check it into CVS
by Misha Bergal 13 Mar '05

13 Mar '05

I might have incidently lost your changes :-(. Next time please follow the instructions at http://tinyurl.com/5oyp4. -- Misha Bergal MetaCommunications Engineering

1 0

[type traits] is_convertible issue
by David Abrahams 12 Mar '05

12 Mar '05

Hi, Mike, a Boost.Python user, ran into a problem that amounts to this: #include <boost/type_traits/is_convertible.hpp> struct S { virtual void f()=0; }; boost::is_convertible<S&,S> error; Shouldn't is_convertible handle cases like this by stripping references before testing? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0