- Boost - lists.boost.org

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

Boost Graph - internal datastructures of graph
by Peter Billen 14 Mar '05

14 Mar '05

Hello all, I was wondering what internal datastructures are used in the different graph concepts (Graph, IncidenceGraph, etc.), to achieve efficient implementations of these different concepts. Is this documented somewhere? I couldn't find anything about the implementations on the website. Is this discussed in the book? I am aware I can browse through the code, but I thought it might be a good idea to ask it first here. Thanks for your replies, -- Peter

2 1

[Boost-bugs] [ boost-Bugs-1163091 ] push_relabel_max_flow may be broken
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163091, was opened at 2005-03-14 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&group_… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: push_relabel_max_flow may be broken Initial Comment: The push_relabel_max_flow algorithm seems to be dereferencing past-the-end iterators. The initial bug report is here: http://lists.boost.org/MailArchives/boost-users/msg10032.php Doug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163091&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0