- Boost - lists.boost.org

Re: [boost] Re: FSM Review
by Iain Hanson 15 Mar '05

15 Mar '05

Hi Dave, I've taken the liberty of correcting my poor spelling in the quoted parts of my message of last night. My only excuse is that it was late :-(. ( And I am a native English speaker :-( ). On Mon, 2005-03-14 at 22:34 -0600, David B. Held wrote: > Iain K. Hanson wrote: > > [...] > > There is no doubt ( in my mind ) that Andreas has done some very > > good work. The issue is whether this library is suitable for > > acceptance into boost. IIUC boost is predominately about best of > > breed libs. > > Yes. And sometimes there is more than one best in the breed. Agreed. We have a collection of containers to deal with genuine trade- offs. > > > The primary philosophy in C++ is you don't pay for what you don't use. > > ...And yet, we have iostreams. I don't know the history of iostreams or std::string but I'd be surprised and a little disappointed if there flaws were known and yet they were still admitted to the std. I know iostreams pre-dates the std so perhaps its historical. > > Andreas has deliberately taken a different approach. He has chosen > > to go for the all singing, all dancing heavy weight approach. > > ...Much like shared_ptr<>, which got into TR1. And I dare say that > shared_ptr<> is used in far more performance sensitive contexts than > the FSM. If we declared that shared_ptr<> is the end-all, be-all > smart pointer for C++, I would be as unhappy as you are. For very different reasons. shared_ptr deals with safety. The current FSM proposal takes a feature like state specific storage and every user has to pay for it whether they need it or not even if there is another cheaper way to provide it. ( there always is ). > > > He has explained his approach on this list. You pay for State > > Specific Storage whether you want it or not. You currently get > > non-linear event dispatch ( without orthaganal regions ) if you > > use outer states. And you get horrible performance on transitions > > ( with loss of state specific storage when you transition out of > > a state ). > > And if that were a deal-breaker, people wouldn't be using the > library, would they? Apparently, there are applications where > these are not the critical metrics, and people have already found > use for it. I'm sure its useful. Just as iostreams and std::string are useful. But I don't think that std::string would get through a boost review if presented for the first time today. And nor would it deserve to. Associative containers have O ( log N ) performance for a number of operations because of the underlying algorithm. The current FSM ( State Chart ) proposal has its performance characteristics because of the choices made by the author not for any fundamental underlying reason. All state charts can be collapsed to a STT. > > > I know that if I hand write a GOF state pattern I can get close > > to the scalability of the FSM lib but with constant time event > > dispatch through a single indirection and can change state through > > a single assignment. > > But can you provide all the other features of the FSM proposal? If > not, then you're comparing apples to oranges, right? Of course. At the end of the day, the most an FSM lib can give us is the elimination of some boiler plate code. The doing away with cut and paste. I think few will be willing to pay the performance price to do away with boiler plate and cut & paste. > > FSM is the domain but whether it is spelt STT or StateChart is > > irrelevant one can be mechanically collapsed to the other. But > > the fsm proposal does not do this. > > > > If we have a StateChart lib in boost it should scale as well as any > > other library in boost > > I'm not quite sure what you're saying here, but clearly there is > precedent for solutions at different granularities/complexities > /performance tradeoffs in Boost. Consider tokenizer/regex/spirit. > Consider compose/bind/lambda. If you think that Boost needs a > low-level FSM that concentrates on performance over abstraction, > you may be right. But if you think that it does not need an FSM > library that focuses on abstraction and ease of use, it would > appear that some users might disagree with you. > I think that you are mistaking me. I strongly believe in solutions at different granularities and the trade-offs that they require. If this proposal was an just an std::map and presented as the containers library then it would just need docs to be corrected to say that it is part of a containers lib. ( Just as Andreas has agreed his proposal should be spelt StateChart ). My issue is that this is a std::vector with the performance and weight of std::map. When we know this up front then *I believe* it is a good reason to vote for rejection. /ikh

1 0

[addressof] patch for Borland
by Eric Niebler 15 Mar '05

15 Mar '05

Borland doesn't like boost::addressof when used with arrays. It won't let you reinterpret_cast from an array reference to a char &. Russell Hind was good enough to test the following patch for me and confirmed that it works around the problem. (This is needed to get BOOST_FOREACH to work with Borland.) If no one objects, I'll apply the patch myself. -- Eric Niebler Boost Consulting www.boost-consulting.com Index: addressof.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/addressof.hpp,v retrieving revision 1.7 diff -b -d -u -r1.7 addressof.hpp --- addressof.hpp 27 Jul 2004 03:43:33 -0000 1.7 +++ addressof.hpp 14 Mar 2005 18:15:31 -0000 @@ -33,6 +33,22 @@ &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } +// Borland doesn't like casting an array reference to a char reference +// but thes overloads work around the problem. +# if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) +template<typename T,std::size_t N> +T (*addressof(T (&t)[N]))[N] +{ + return reinterpret_cast<T(*)[N]>(&t); +} + +template<typename T,std::size_t N> +const T (*addressof(const T (&t)[N]))[N] +{ + return reinterpret_cast<const T(*)[N]>(&t); +} +# endif + } #endif // BOOST_UTILITY_ADDRESSOF_HPP

4 8

Re: [boost] Re: boost/pending/mutable_queue missing clear() function
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 Mar '05

----- Mensaje original ----- De: Douglas Gregor <doug.gregor(a)gmail.com> Fecha: Lunes, Marzo 14, 2005 9:29 pm Asunto: Re: [boost] Re: boost/pending/mutable_queue missing clear() function > > On Mar 14, 2005, at 12:55 PM, David Abrahams wrote: > > > Douglas Gregor <doug.gregor(a)gmail.com> writes: > > > >> On Feb 11, 2005, at 5:39 PM, Lloyd J Lewins wrote: > >> > >>> I notice that mutable_queue is missing a clear() function, > i.e. a low > >>> overhead way of emptying the entire queue (without resorting to > >>> repeated > >>> pops). However, I think clear() can be implemented as follows: > >>> > >>> void clear() { clear(); } > >>> > >>> Which is efficient and (often) fast. > > > > Surely that one only runs until you blow the stack. Am I missing > > something? > > No, but neither did I :) The correct code (in CVS of course) is: > > void clear() { c.clear(); } > A silly and totally OT std-riddle: would an optimizer be allowed to rewrite void clear() { clear(); } as if: void clear() {} ? If not, why not? (with observable behavior in mind) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[iostreams] Major interace changes planned -- comments requested
by Jonathan Turkanis 14 Mar '05

14 Mar '05

Hi All, Several important extensions of the Iostreams library have been on hold for over a month while I have tried to resolve the issue described in this message. Unfortunately it didn't get much attention during the review, so I'm hoping I can generate some discussion now. I'm sorry about the length of this message; I've been stuck on this for a long time and would really appreciate some help. I. The Problem --------------------------- Standard iostreams do not work well with non-blocking or asynchronous i/o. I would eventually like to extend the library to provide support for non-blocking and async i/o, and when I do so I expect I will have to introduce some new Device concepts. However, I would like to modify the *current* filter concepts so that they will work unchanged when non-blocking and asynchronous devices are introduced. There are several reasons for this: 1. Proper isolation of concepts. A filter represents a rule for transforming character sequences; ideally, how the sequence is accessed should not be relevant. For example, it would be silly to require separate versions of a toupper_filter for blocking and non-blocking i/o, since they would both represent the same simple rule. 2. Maximal code reuse. While it would just be silly to require several versions of a toupper_filter, it would be extremely wasteful to require several versions of more complex components like compression or encryption filters. 3. Reduced complexity of the library. The library already has a large number of concepts; I don't want to double or triple the number of filter concepts when non-blocking and async i/o is introduced. II. The Solution (the easy part) --------------------------- I believe it will suffice to: - provide the functions put() and write() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been written to the underlying data sink even though no error has occurred. - Provide the functions get() and read() (both filter member functions and the free functions with the same names) with a way to indicate that fewer than the requested number of characters have been read from the underlying data source, even though no error has occurred and EOF has not been reached. This is easily achieved for put() and write(), and almost as easily for read(): - Instead of returning void, put() can return a bool indicating whether the given character was successfully written. - Instead of returning void, write() can return an integer indicating the number of characters written. - Currently, when read returns fewer characters than the requested amount it is treated as an EOF indication. Instead, we can allow read to return the actual number of characters read, and reserve -1 to indicate EOF, since it is not needed as an error indication. III. The Solution (the ugly part) --------------------------- The function get presents more of a challenge. Currently it looks like this (for char_type == char): struct my_input_filter : input_filter { template<typename Source> int get(Source& src); }; The return type already serves a dual purpose: it can store a character or an EOF indication. Unfortunately, with non-blocking or async i/o there are now three possible results of a call to get: 1. A character is successfully retrieved. 2. The end of the stream has been reached. 3. No characters are currently available, but more may be available later. My preferred solution is to have get() return an instance of a specialization of a class template basic_character which can hold a character, an EOF indication or a temporary failure indication: template<typename Ch> class basic_character { public: basic_character(Ch c); operator Ch () const; bool good() const; bool eof() const; bool fail() const; }; typedef basic_character<char> character; typedef basic_character<wchar_t> wcharacter; character eof(); // returns an EOF indication character fail(); // returns a temporary failure indication. wcharater weof(); wcharater wfail(); [Omitted: templated versions of eof and fail] Alternatively, the member functions good, eof and fail could be made non-member functions taking a basic_character. IV. Examples (feel free to skip) --------------------------- With these changes, the uncommenting_input_filter (http://tinyurl.com/3ue9r) could be rewritten as follows: class uncommenting_input_filter : public input_filter { public: explicit uncommenting_input_filter(char comment_char = '#') : comment_char_(comment_char) { } template<typename Source> character get(Source& src) { character c = boost::io::get(src); if (c.good() && c == comment_char_) while (c.good() && c != '\n') c = boost::io::get(src); return c; } private: char comment_char_; }; Similarly, usenet_filter::get (http://tinyurl.com/6xqvk) could be rewritten: template<typename Source> int get(Source& src) { // Handle unfinished business. if (eof_) return EOF; if (off_ < current_word_.size()) return current_word_[off_++]; // Compute curent word. current_word_.clear(); while (true) { character c; if (!(c = boost::io::get(src)).good()) { if (c.eof()) eof_ = true; if (current_word_.empty()) return c; else break; } else if (isalpha((unsigned char) c)) { current_word_.push_back(c); } else { // Look up current word in dictionary. map_type::iterator it = dictionary_.find(current_word_); if (it != dictionary_.end()) current_word_ = it->second; current_word_.push_back(c); off_ = 0; break; } } return this->get(src); // Note: current_word_ is not empty. } V. Problems ---------------------------- 1. Harder to learn. Currently the function get and the concept InputFilter are very easy to explain. I'm afraid having to understand the basic_character template before learning these functions will discourage people from using the library. 2. Harder to use. Having to check for eof and fail make writing simple filters, like the above, slightly harder. I'm worried that the effect on more complex filters may be even worse. This applies not just to get, but to the other functions as well, since their returns values will require more careful examination. 3. Performance. It's possible that the change will have a negative effect on performance. I was planning to implement it and then perform careful measurements, but I have run out of time for this. I think the effect will be slight. VI. Benefits ------------------------ A positive side-effect of this change would be that I can rename the filter concepts InputFilter --> PullFilter OutputFilter --> PushFilter and allow both types of filter to be added either to input or to output streams. Filter writers could then choose the filter concept which best expressed the filtering algorithm without worrying whether it will be used for input or output. VII. Alternatives. 1. Adopt the convention that read() always blocks until at least one character is available, and that get() always blocks. This would give up much of the advantage of non-blocking and async i/o. 2. Add new non-blocking filter concepts, but hide them in the "advanced" section of the library. All the library-provided filters would be non-blocking, and users would be encouraged, but not required, to write non-blocking filters. If you've made it this far THANK YOU!!! Please let me know your opinion. Jonathan

6 49

[range] rationale for transform_range() algorithm?
by Eric Niebler 14 Mar '05

14 Mar '05

Background: I have been working on range-based algorithms and adaptors. The algorithms are variants of the std::algorithms that accept ranges instead of a [begin,end) iterator pair. The adaptors are like the iterator adaptors, except they adapt ranges. Following the principal of least surprise, I want to call my range adaptors filter_range, indirect_range, reverse_range and transform_range (to parallel filter_iterator, indirect_iterator, etc). But I can't do this, because there already is a transform_range, and it's a function! Problem: At the bottom of iterator_range.hpp is this: template< typename SeqT, typename Range, typename FuncT > inline SeqT transform_range( const Range& r, FuncT Func ) { SeqT Seq; std::transform( begin( r ), end( r ), std::back_inserter(Seq), Func ); return Seq; } I'm not sure why. It looks like a range-based algorithm, but ... why provide only one? (Two actually -- copy_range is there also.) And why call it transform_range() instead of just calling it "transform" and making it part of a complete range-based algorithm library? Solution: I suggest the functions copy_range() and transform_range() should be removed or moved into a "deprecated" namespace, freeing up the identifier "boost::transform_range" to be a type, analagous to boost::transform_iterator. Development should proceed on a range-based algorithms library to fill the need that the existing "transform_range()" function is meeting. Thoughts? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 10

boost/pending/mutable_queue missing clear() function
by Lloyd J Lewins 14 Mar '05

14 Mar '05

I notice that mutable_queue is missing a clear() function, i.e. a low overhead way of emptying the entire queue (without resorting to repeated pops). However, I think clear() can be implemented as follows: void clear() { clear(); } Which is efficient and (often) fast. I don't think there is any need to "clear" the index_array (since the constructor for mutable_queue doesn't initialize its contents) Lloyd J. Lewins Fellow, Raytheon Co., llewins(a)raytheon.com +1 (310) 647-8832

3 3

bug fixes for boost::filesystem::exists on Win32
by Robert Mathews 14 Mar '05

14 Mar '05

Hi: I was trying to do something simple with the boost::filesystem library on Win32 && I noticed that it has trouble with UNC paths. I think I noticed 2 bugs with boost::filesystem::exists (possible patch attached). Finally, I also had a question about what consistutes a "part" of a path. Here's the context: I was trying to get all of the parts of a path, starting at the front and moving to the end in order to find out at which point a path was invalid. So, I wrote a path-checker that went something like this: using namespace std; namespace fs = boost::filesystem; void check_path(const string iPath) { fs::path::default_name_check(fs::native); fs::path aCurrentPath; for(fs::path::iterator aItr1=iPath.begin(); aItr1!=iPath.end(); aItr1++) { aCurrentPath /= *aItr1; bool aExists(fs::exists(aCurrentPath)); if(!aExists) { cout << "Hey, this was invalid path and it failed at aCurrentPath" << endl; return false; } } return true; } The function works fine if you give it paths like "D:/foo/bar", but a UNC path like \\computername\share\foo\bar doesn't work. The reason is that the path::iterator returns the following results for the beginning of the UNC path: "//computername" "/" "share" "/" "foo" ... etc and "//computername" is not a valid path. I've got a couple of questions about this: 1) Why is the separator "/" a separate part of the path? Shouldn't there be a way to only get the directory parts of the path w/o the separators? Just curious .. I couldn't find a reference to that in the discussion list. 2) boost::filesystem::exists("//computername") will return false, always. That seems like the wrong answer, given that the path::iterator has returned it as a part of the path. I notice that the filesystem code does otherwise understand UNC paths otherwise. 3) boost::filesystem::exists("//computername/nofreelunch") will return true, if even "nofreelunch" doesn't exist. Looking at the implementation of filesystem::exists in boost libs/filesystems/src/operations_posix_windows.cpp line 324, I'd like to propose the following changes to fix cases 2 & 3. To fix case 3 above, the error code return for an invalid share is not PATH_NOT_FOUND, but ERROR_BAD_NETPATH. That's a simple addition to the list of error codes to check. That should be uncontroversial. To fix case 2 above, one must notice that you have a UNC path with 1 element - ie, a computer name. At the point you can either follow the hint in the code and simply return true, or you can call a different WIN32 function to see if the server exists. Attached is a proposed patch for both issues. Thanks. begin 666 operations_posix_windows.cpp.patch M26YD97@Z(&]P97)A=&EO;G-?<&]S:7A?=VEN9&]W<RYC<' -"CT]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T-"BTM+2!O<&5R871I;VYS7W!O<VEX7W=I;F1O=W,N M8W!P"2AR979I<VEO;B R-3(W,2D-"BLK*R!O<&5R871I;VYS7W!O<VEX7W=I M;F1O=W,N8W!P"2AW;W)K:6YG(&-O<'DI#0I 0" M,S(Q+#$P("LS,C$L,S@@ M0$ -"B @(" @("!]#0H@(" @(" @<F5T=7)N('1R=64[#0H@(R @(&5L<V4- M"BT@(" @("!I9B(a)Z.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN M8U]S='(H*2 I(#T](#!X1D9&1D9&1D8I#0HK"2 @<W1R:6YG(&%0871H*'!H M+G-T<FEN9R@I*3L-"BL)("!B;V]L(&ES54Y#4&%T:"AA4&%T:"YS:7IE*"D@ M/B S("8F(&%0871H+G-U8G-T<B@P+#(I(#T]("(O+R(I.R O+R T/4QA<F=E M(&5N;W5G:"!P871H('1O(&AA=F4@82!L96%D:6YG("\O(&%N9"!A="!L96%S M=" Q(&UO<F4@8VAA<F%C=&5R#0HK"2 @<W1R:6YG.CIS:7IE7W1Y<&4@84YE M>'13;&%S:"AA4&%T:"YF:6YD7V9I<G-T7V]F*"(O(BPR*2D[#0HK"2 @8F]O M;"!I<T]N;'E#;VUP=71E<DYA;64H:7-53D-0871H("8F"0D)"0D)+R\@;6%K M92!S=7)E('1H:7,@82!53D,@<&%T:"!O9B!S;VUE('1Y<&4N#0HK"0D)"0D) M"2 @*&%.97AT4VQA<V@@/3T@<W1R:6YG.CIN<&]S('Q\"2\O(&QO;VL@9F]R M("\O8V]M<'5T97)N86UE#0HK"0D)"0D)"2 @("AA3F5X=%-L87-H(#T]("AA M4&%T:"YS:7IE*"D@+2 Q*2 F)B!A4&%T:"YS:7IE*"D@/B S("\O(&%L;&]W M("\O8V]M<'5T97)N86UE+R!A;F0@9F5N8V4@;V9F("<O+R\G(&EN<'5T( T* M*PD)"0D)"0D@(" I*2D[#0HK"2 @:68H:7-/;FQY0V]M<'5T97).86UE*0T* M*R-I9F1E9B!F86YC>5]C:&5C:VEN9PT**PD)(" O+R!)(&1O;B=T(&MN;W<@ M:68@>6]U('=A;G0@=&\@9V\@=&AI<R!F87(@;W(@;F]T/PT**PD)(" O+R!9 M;W4G;&P@:&%V92!T;R C:6YC;'5D92 \;&TN:#X@86YD(&QI;FL@86=A:6YS M="!.971A<&DS,BYL:6(@)B8@=&AE;B!W;W)R>2!A8F]U="!A;&P@=F%R:6]U M<R!V97)S:6]N<R!O9B!W:6YD;W=S("XN( T**PD@('L-"BL)"2 @3%!315)6 M15)?24Y&3U\Q,# @85-E<G9E<DEN9F\H3E5,3"D[#0HK"0D@($Y%5%]!4$E? M4U1!5%53(&%3=&%T=7,H3F5T4V5R=F5R1V5T26YF;T$H#0HK"0D)"0D)"0D) M"2 @<&@N<W1R:6YG*"DL#0HK"0D)"0D)"0D)"2 @,3 P+ T**PD)"0D)"0D) M"0D@("A,4$)95$4J*2 F85-E<G9E<DEN9F\-"BL)"0D)"0D)"0D)("D[#0HK M"0D@(&EF*&%397)V97));F9O*0T**PD)"2 @3F5T07!I0G5F9F5R1G)E92AA M4V5R=F5R26YF;RD[#0HK"0D@(')E='5R;B!A4W1A='5S(#T]($Y%4E)?4W5C M8V5S<SL-"BL)("!]#0HK(V5L<V4-"BL)(" O+R!!="!L96%S="P@:68@>6]U M(')E8V]G;FEZ92!T:&%T('1H:7,@82!C;VUP=71E<B!N86UE+"!Y;W4@8V]U M;&0@9&\@=V]R<V4@=&AA;B!T;R!A<W-U;64@:70@;6EG:'0@97AI<W0N#0HK M"2 @<F5T=7)N('1R=64["0D)#0HK(V5N9&EF"2 @#0HK"2 @96QS92!I9B@Z M.D=E=$9I;&5!='1R:6)U=&5S02@@<&@N<W1R:6YG*"DN8U]S='(H*2 I(#T] M(#!X1D9&1D9&1D8I#0H@(" @(" @>PT*(" @(" @(" @(%5)3E0@97)R(#T@ M.CI'971,87-T17)R;W(H*3L-"BT@(" @(" @("!I9B@H97)R(#T]($524D]2 M7T9)3$5?3D]47T9/54Y$*2!\?" H97)R(#T]($524D]27TE.5D%,241?4$%2 M04U%5$52*2!\?" H97)R(#T]($524D]27U!!5$A?3D]47T9/54Y$*2!\?" H M97)R(#T]($524D]27TE.5D%,241?3D%-12DI#0HK(" @(" @(" @:68H*&5R M<B ]/2!%4E)/4E]&24Q%7TY/5%]&3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E]) M3E9!3$E$7U!!4D%-151%4BD@?'P@*&5R<B ]/2!%4E)/4E]0051(7TY/5%]& M3U5.1"D@?'P@*&5R<B ]/2!%4E)/4E])3E9!3$E$7TY!344I#0HK"0D)*&5R M<B ]/2!%4E)/4E]"041?3D544$%42"D-"BL)"2 @("D-"B @(" @(" @(" @ M("!R971U<FX@9F%L<V4[("\O($=E=$9I;&5!='1R:6)U=&5S(&9A:6QE9"!B M96-A=7-E('1H92!P871H(&1O97,@;F]T(&5X:7-T#0H@(" @(" @(" @+R\@ M9F]R(&%N>2!O=&AE<B!E<G)O<B!W92!A<W-U;64@=&AE(&9I;&4@9&]E<R!E M>&ES="!A;F0@9F%L;"!T:')O=6=H+ T*(" @(" @(" @("\O('1H:7,@;6%Y M(&YO="!B92!T:&4@8F5S="!P;VQI8WD@=&AO=6=H+BXN(" H2DT@,C P-# S %,S I#0H` ` end

1 0

[serialization] BOOST_CLASS_EXPORT regression?
by Vladimir Prus 14 Mar '05

14 Mar '05

Hello, I've have a header file like this: namespace lvk { namespace nm_model { namespace runtime { class IntTraceItem {}; }}} BOOST_CLASS_EXPORT(lvk::nm_model::runtime::IntTraceItem); The header is included in two files. It used to work before, but I've just updated to CVS state of the serialization lib, and get: src/runtime/bin/gcc/debug/threading-multi/TraceArbiter.o(.bss+0x0):src/runtime/TraceArbiter.cpp:16: multiple definition of `boost::archive::detail::guid_initializer<lvk::nm_model::runtime::IntTraceItem>::instance' src/runtime/bin/gcc/debug/threading-multi/Trace.o(.bss+0x0):src/runtime/Trace.cpp:21: first defined here I attach the testcase. When I run g++ -I ~/Work/boost-rc s1.cpp s2.cpp the first error is about duplicate symbols. Am I doing something wrong or is this a regression? - Volodya

3 5

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

14 Mar '05

In-Reply-To: <d0kr8r$gl6$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > 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. I see I have missed the deadline. Oh, well. Several queries have been raised during the review, some of which have merit. Firstly, I think we have some agreement that the signature: size_t hash_range( It first, It last ); is wrong and there should be some way to provide an initial seed. I am not yet decided on what the best signature should be; I am tempted towards a 3rd argument with a default value, but I can also see some merit in mimicking hash_combine() by making the seed the first argument. Secondly, the proposed implementation for hashing pointers produces undefined behaviour because it subtracts pointers not in the same array. We have some agreement that using reinterpret_cast would be better. Thirdly, I think there is also a legitimate query over whether the default hash_range should provide better quality hashes for arrays of bytes, eg along the lines discussed in: http://www.azillionmonkeys.com/qed/hash.html With boost interface is more important than implementation, but apparently implementations of the hash library will not be allowed to vary. My impression is that the proposed implementation of hash_combine: seed ^= hash_value(v) + (seed << 6) + (seed >> 2); was designed to combine 8-bit character values; do we have any evidence it also performs well to combine 32-bit values? Perhaps hash_value(v) would be better treated as an array of 4 bytes? Fourthly, there seems to be a design philosophy behind the current proposal which is not stated explicitly in the documentation. It apparently favours some notion of safety over speed and hash quality, where "safety" means that different objects should have the same hash values if they look at all alike to someone possibly. For example, the proposal has no specialisation for chars at all. I can't tell if that is an oversight, or whether it is a design aim that: char chars[] = { 1, 2, 3, 4 }; int ints[] = { 1, 2, 3, 4 }; assert( hash_range( chars, chars+4 ) == hash_range( ints, ints+4 ) ); I gather it is a design aim that hash_value( pair<int,int> ) match hash_range( int[2] ). Presumably if hash_range takes a seed argument, this means hash_value must too, else how can it match it? I am not sure about all this philosophy. I had kinda hoped that a boost hashing library would offer good quality industrial-strength hashing; that it would save me having to do my own research. Regardless, I think the aims and guarantees of the proposed library should be documented more explicitly. In conclusion, I feel that if we given only 5 days to review a proposal, that proposal needs to be spot on, uncontroversial, with all issues nailed accurately in advance. I don't think that is the case here. Although I think all the problems could be resolved, I don't think we have enough time to do that in the given review period. If I have to decide now, I'd say: This should not be accepted as a Boost library. Stock questions: I have not tried to compile the code. I have looked at the documentation, the source, and followed some of the references. I have raised design questions here and followed the discussion. Total time is a few hours. I am not an expert on hashing, but I have implemented my own hashing library. I have encountered practical problems due to different objects having the same hash values. -- Dave Harris, Nottingham, UK

6 14

[aligned_storage][repost] problems with GCC 4.0.0 20050309
by JOAQUIN LOPEZ MU?Z 14 Mar '05

14 Mar '05

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? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4