March 2005 - Boost - lists.boost.org

boost::bind now with limited operator support
by Peter Dimov 15 Mar '05

15 Mar '05

boost::bind now supports operator! and the relational operators ==, !=, <, <=, >, >=. For the latter, the left operand must be a bind expression, the right operand can be a value, a placeholder, or another bind expression. Not exactly a Lambda, but good enough for many common tasks. -- Peter Dimov http://www.pdimov.com

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): > > Firstly, I think we have some agreement that the signature: > > > > size_t hash_range( It first, It last ); > > > > is wrong > > I didn't get the impression of any agreement about that. > > > and there should be some way to provide an initial seed. > > Although, I agree with this. That's all I meant. I knew there wasn't much agreement over whether side effects are bad :-) My review was a lot more conservative than my comments in discussion. > > We have some agreement that using reinterpret_cast would be better. > > Yes, and this will be fixed. When I wrote it seemed there were still unresolved issues. In fact, I don't believe anyone has yet posted an acceptable hash_value for pointers. Presumably we want to shift out bits which are always 0 for alignment reasons. > It is proposed that the standard explicitly specifies the hash > functions (and I've been criticized for not doing that) but part > of the purpose of this library is to get real world experience > on what the specification should be. And change it, if necessary. OK. > I do intend to spend more time looking into alternatives in the future > (and will look into adding a constant to hash_combine very soon). OK. Although I suggested it, I'm not sure it's the best fix, as compared with using non-zero initial seeds. const size_t default_seed = 0x9e3779b9; // Or whatever. size_t hash_range( It first, It last, seed=default_seed ); A signature like that provides a hook to introduce variation between similar types if the author desires, and also allows ranges to be hashed as subranges with the output of one subrange feeding into the next. The default value allows the issue to be safely ignored by naive users. So it's a good idea anyway, and since it also fixes the problem with zeros maybe we don't need to fix that twice. This does leave the issue of other places where hash_combine is called. It would be sufficient if we could be sure that all used a non-zero initial seed, eg: size_t hash_value( std::pair<int,int> p ) { size_t hash = default_seed; combine_hash( hash, p.first ); combine_hash( hash, p.second ); return hash; } and the documentation would encourage that, but we can't really be sure of it. Another approach is to change all the primitive functions. For example: size_t hash_value( int i ) { return static_cast<unsigned int>(i) + default_seed; } Introducing the non-zero constant here is surely as efficient as in combine_hash, if not more so. Admittedly it doesn't eliminate the zero, it just moves it around, but it should massively reduce its dynamic frequency. (Actually it will eliminate the zero where it matters most, ie for types like bool, char and short which are smaller than size_t.) > Did you see Peter's original proposal? Yes, I had followed most of the links. > > 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 [...] > I don't think it's either. Peter? Peter has now said it is a design aim. That even you weren't sure illustrates my point :-) > When hash_range is called with a seed argument, it would be equivalent > to calling hash_combine for pair<int, int>. If I understand the principles being advocated here, pair< pair<int,int>, pair<int,int> > should have the same hash_value as int[4]. How do you achieve that without giving hash_value( pair ) an initial seed? ----- I find myself increasingly drawn to the idea of a hasher object. The main signature should be like: template <typename T> Hasher &hash( Hasher &hasher, const T &t ); with implementations looking like, eg: template <typename First, typename Second> Hasher &hash( Hasher &hasher, const pair<First,Second> &p ) { hash( hasher, first ); hash( hasher, second ); return hash; } Then hash_value, if we still need it, would be like: template <typename T> size_t hash_value( T &t ) { Hasher hasher; hash( hasher, t ); hasher.finalise(); return hasher.value(); } but would rarely be called directly. This solves the problem of the default value, allows us to store intermediate results bigger than size_t (which may be important for cryptographic-strength hashing), and the finalise() step provides a hook for the final mixing/avalanching which some algorithms use (eg Paul Hsieh's). > Perhaps it would be better spelt as: > > template <class It> > void hash_combine(std::size_t& seed, It begin, It end); Yes, I considered that. I wasn't sure whether overloading the name would help or hinder - hash_range and hash_combine are not substitutable for each other. > Well, we did discus the type of review before it started, and nobody > raised any objections. I don't object to quick reviews in principle (although if someone can only contribute, eg, on Sunday mornings, a 5-day period is going to leave them out completely). > > 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. > > Is this in C++? Yes. The main problem was zeros. My hash primitives produced zeros and my hash_combine turned zeros into more zeros. Just as with the initial boost proposal. > I would have thought that type safety would have helped avoid > such problems. This was specifically an issue with optional or alternate types. For example, I had something similar to: size_t MyType::hash_value() const { return use_a ? hash_value(a) : hash_value(b); } where a and b could be different types. We can avoid that mistake in library classes like boost:variant, but that doesn't prevent it recurring in user code. When I am dealing with types without much intrinsic variation, eg bools, I found it important to exploit such variation as I did have as much as possible. Hashing false and 0 to different values helped. > Thank you for reviewing the library and bringing up several good points. My pleasure. -- Dave Harris, Nottingham, UK

3 3

boost::filesystem in Windows 95
by Jorge Lodos 15 Mar '05

15 Mar '05

Hi We have a code base for Windows that compiles with common settings for all Windows platforms. When using boost::filesystem, this is no longer possible, due to the fact that Windows implementation in operations_posix_windows.cpp uses the API function GetFileAttributesExA, not available in Windows 95. GetFileAttributesExA could be replaced by FindFirstFile, which gives the same information and is available in all Windows platforms. This API is used in two different places, BOOST_FILESYSTEM_DECL bool _is_empty( const path & ph ) implementation and BOOST_FILESYSTEM_DECL boost::intmax_t file_size( const path & ph ) implementation. Using FindFirstFile instead of GetFileAttributesExA we would get: BOOST_FILESYSTEM_DECL bool _is_empty( const path & ph ) { # ifdef BOOST_POSIX ........ # else WIN32_FIND_DATA ; HANDLE hf = ::FindFirstFileA(ph.string().c_str(), &ffd); if (hf == INVALID_HANDLE_VALUE) boost::throw_exception( filesystem_error( "boost::filesystem::is_empty", ph, fs::detail::system_error_code() ) ); CloseHandle(hf); return ( ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY ) ? is_empty_directory( ph ) :( !ffd.nFileSizeHigh && !ffd.nFileSizeLow ); # endif } BOOST_FILESYSTEM_DECL boost::intmax_t file_size( const path & ph ) { # ifdef BOOST_POSIX ....... # else // by now, intmax_t is 64-bits on all Windows compilers WIN32_FIND_DATA ; HANDLE hf = ::FindFirstFileA(ph.string().c_str(), &ffd); if (hf == INVALID_HANDLE_VALUE) boost::throw_exception( filesystem_error( "boost::filesystem::file_size", ph, fs::detail::system_error_code() ) ); CloseHandle(hf); if ( (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) !=0 ) boost::throw_exception( filesystem_error( "boost::filesystem::file_size", ph, "invalid: is a directory", is_directory_error ) ); return (static_cast<boost::intmax_t>(ffd.nFileSizeHigh) << (sizeof(ffd.nFileSizeLow)*8)) + ffd.nFileSizeLow; # endif } Is there any chance this could be solved in boost::filesystem? Thank you for boost :-) Best regards Jorge

2 1

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

15 Mar '05

In-Reply-To: <001201c527e4$7405efa0$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > 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. > > Maybe, but this is not an argument for making the hash values different. True. Arguments for that have been given elsewhere. One argument is to maximise variation (and for types like bool it is desperately needed). Another is to allow treating of 32-bit values as bytes. For example, size_t hash_range( const int *first, const int *last ) { return hash_range( static_cast<const unsigned char *>(first), static_cast<const unsigned char *>(last) ); } may be a good implementation on some platforms. It does 4 times as many mixing steps (assuming sizeof(int) == 4) as the proposed algorithm. It is, I think, how the designer of the proposed hash_combine algorithm expected it to be used. However, it yields hash values for int * different to the values for char *, so with the current design aims we can't use 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] ) ? > > No. The seed version of hash_range is used when you want to compute the > hash function of a sequence, but you don't have access to the whole > sequence at once. It's goal is not to provide a way to change the > initial seed, but to make it possible to continue from an intermediate > seed. But suppose I have pair< pair<int,int>, pair<int,int> > ? Shouldn't that yield the same hash value as int[4] ? -- Dave Harris, Nottingham, UK

5 5

ANN: review of FSM library starts
by Pavel Vozenilek 15 Mar '05

15 Mar '05

Review of Finite State Machine library written by Andreas Huber starts today, February 21, and lasts 10 days. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Pavel Vozenilek FSM review manager

7 19

FSM Review
by Jody Hagins 15 Mar '05

15 Mar '05

I am sorry this is late. I made the mistake of introducing my kids to snow skiing. Now they can not get enough of it. Thus, we were gone again until Wednesday (yes, I let them skip a few days of school to go skiing). * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? I think the documentation is relatively complete. However, I am not exactly thrilled by the requirement on the reader to understand UML diagrams. On the other hand, this library is intended to represent UML in C++ (at least to my understanding), so I'm not sure what else can be done. A link to a basic tutorial on UML state machine diagrams would be appropriate in the "UML to boost::fsm Mapping Summary." I know you link to the 730 page OMG document on UML, but I'd also like to see something that describes the basic UML for state charts. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? I think the requirements dictate the design. Specifically, the desire to mimic UML statecharts in C++. As stated before, the design brings with it some performance tradeoffs that will make this library unusable to some. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? I think it is obvious that the library should be separated, though I do not think this issue itself should be a stumbling block for acceptance. Exception handling is very important, and I do not buy the rationale that allowing destructors to throw is not a problem in practice. I also do not think I really understand "two stage exit." * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? I did not look too much at the implementation, so I can not comment much here. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? I think we have to define real-time. Traditionally, real-time systems have hard completion time requirements (e.g., the XYZ event must be processed in under 50ms). Even though I have performance issues with this library, I think it can still be utilized in many real-time situations. Andreas has stated several times that the dispatch time will be small compared to the handling time. However, I find this argument a bit lacking, especially for hard real-time requirements, where each cycle taken for dispatch is stolen from the reaction handler. My current application requirements do not fit the traditional definition of real-time. However, my SMs need to be as fast as possible, because in a real sense, my code is competing with other code. Without going into too much detail, when an "opportunity" is available, it is only available to the first one to see it, respond, and take that opportunity. Thus, my real-time requirement is that I have to be faster than anyone else playing my game. I think using this library would put me at a disadvantage in that particular space. However, I do have some applications in which this library could be used successfully (if I were inclined to learn enough UML to make sense of all the details). The documentation is clear enough about the performance issues. In fact, it may be too clear, as some people seem to see problems that may not exist in most applications. One last thing on performance, since it has been a hot topic in relation to this library. I do not think it has sufficient performance to warrant use in all my applications, and I assume the same for many others. However, it does have sufficient performance to be used in a large number of applications. If the docuemntation is clear (which it is), then users can decide when/how it can be used. I could make similar performance claims agains almost every boost library (and I have made them on this list about shared_ptr and signals). However, that does not mean we should eliminate those libraries from boost, nor does it mean that they should never have been accepted (but I would like to see a larger commitment to address performance issues in all currently accepted libraries). I would, however, like to see a separate submission which has a focus on performance, and I would really like to see the performance issue of this library revisited, especially with input from some of the folks here who claim expertise in that area. * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? I have used sevaral versions of SMC, solutions from Samek's "Practical Statecharts in C/C++," and my own hand-crafted stuff. I think SMC is the easiest to use, though it also offers the least flexibility. With moderate use, I think this library could become the standard tool for implementing state machines, with the caveat of every tool: it may need to be replaced if it is too slow. However, I also think that this tool requires a more structured design of your state machine than ad-hoc methods. Thus, if speed were an issue, translating this code to something else would not be too difficult. One thing I have not seen in other reviews is a comparison to GUI state machine tools. I know this is a library, with very different requirements. However, having virtually no experience with GUI tools that build FSMs, I'd be interested to see how this code stacks up with code generated by such tools. Specifically, I have avoided them because I want more control than they allow (or at least allowed when I first looked at them). Does anyone have experiences to offer in this regard? * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? I used it on linux, with gcc. I am probably the last person in this community to offer porting advice to older compilers. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read all the documentation, and played with a few examples. Specifically, I tried to implement a subset of a current state machine to compare ease of use and performance. This library seemed more difficult to use, but I attribute most of that to inexperience. I am convinced that with some moderate level of experience, I could write state machines more easily with this tool. * Are you knowledgeable about the problem domain? I would not consider myself an expert, by any stretch of imagination. However, I have done my fair share of work coding state machines. I have used a small number of tools, and I have crafted my own, so I am at least comfortable with the problems represented by such a library. And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes, with two conditions. 1. The name should definitely be changed. I am not sure, however, what a new name should be. I tend to favor one of Andreas' alternatives: umlfsm. 2. I also think there should be some commitment to revisit the performance issues. I am not sure how this works, but I'd be satisfied with a commitment from Andreas, possibly accompanied by a request to the Boost community for assitance. I am not certain that an acceptable solution can be found, but I think the issue at least needs to be addressed again, specifically with input from the Boost community.

12 37

[Boost-bugs] [ boost-Feature Requests-1163952 ] handle double '/' in the boost::filesystem
by SourceForge.net 15 Mar '05

15 Mar '05

Feature Requests item #1163952, was opened at 2005-03-15 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1163952&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Serg Repalov (rsrus) Assigned to: Nobody/Anonymous (nobody) Summary: handle double '/' in the boost::filesystem Initial Comment: Hi. Sometimes I make some path by hand. For example std::string str = "./"; //... some code .... std::string str2 = str + "/path/to/file"; The result is ".//path/to/file". If I try to make path from it: boost::filesystem::path fs_path2(str2, fs::native); I got exception. Is it possible to correct function path::m_path_append to handle this situation (double/triple/... separator in the middle of string)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1163952&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

Re: [boost] [FSM library] review result: accepted with fewconditions
by Iain Hanson 15 Mar '05

15 Mar '05

On Tue, 2005-03-15 at 19:10 +0100, Pavel Vozenilek wrote: > FSM library written by Andreas Huber has been > accepted into Boost, with few conditions > and few recomendations. > > > Thanks, Andreas, for your work and stamina > to get thus far! > Yes and congratulations to Andreas. > > The documentation is now very dense, splitting > it into smaller parts may help. More hyperlinking > would also help a lot. > Then could there also be a version suitable for printing structured pretty much as it is now please. /ikh

2 1

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

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

15 Mar '05

In-Reply-To: <018201c52567$1b710ca0$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > But as I said, benchmarking hash functions is pointless. Real programs > do not compute the hash value of a random 256 byte buffer five million > times. They usually need to do something with the hash value. This > something typically involves a division on a prime to obtain a modulus, > several pointer chasings, and at least one equality comparison (which > on a 256 byte buffer will have considerable impact). I'd add that my own application caches the results of the hash at highish level, so it doesn't actually matter that much if it is slow. The equality comparison is only needed if the hashes are equal. If you are doing something like adding values to a set, and all the values are in fact different, then hopefully the hashes will be different and the equality tests never needed. In my own code I use a mixture of hashing and interning. This means that if objects are equal they probably have the same address. If they are different they probably have different (cached) hashes. Full byte-by-byte compares of all the data are rarely needed. -- Dave Harris, Nottingham, UK

1 0

template_assert
by Johan Paulsson 15 Mar '05

15 Mar '05

(If this is off topic, has already been discussed, or is stupid, I'm sorry) I wanted a static assert without #define, I ended up with this: template<bool MustBeTrue, int TemplateAssertError = 1 / static_cast<int>(MustBeTrue)> class template_assert {}; so template_assert<true> means TemplateAssertError = 1 / 1, no error template_assert<false> means TemplateAssertError = 1 / 0, error The only compiler I have is MSVC++ 2003. I have no idea how other compilers like it, but to me this seems like a better alternative to BOOST_STATIC_ASSERT. Is it? An example, with the code that will trigger template_assert commented out: // template<class Type> struct test { typedef template_assert<sizeof(Type) == sizeof(int)> assert_type; void do_nothing() {} }; template<bool Boo> void function() { template_assert<Boo>(); test<int> works; works.do_nothing(); //test<char> fails; //fails.do_nothing(); } void start() { function<true>(); //works //function<false>(); //fails } // In MSVC++ 2003 i can also use: template<bool Boo> void function() { template_assert<Boo>; //<-- no parenthesis ... but i suppose this is not portable (I don't have a copy of the C++ standard). Thank you all for making boost! /Johan Paulsson

2 1

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

15 Mar '05

On Tue, 2005-03-15 at 12:06 +0000, Paul A Bristow wrote: > > | -----Original Message----- > | From: boost-bounces(a)lists.boost.org > | [mailto:boost-bounces@lists.boost.org] On Behalf Of David B. Held > | Sent: 15 March 2005 00:13 > | To: boost(a)lists.boost.org > | Subject: [boost] Re: FSM Review > > | 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'. > Sorry, but check the archives before "speculating" on when comments have been made. I argued for state charts to be implemented in terms of STT at the pre-review in May 2004. > 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. > 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. /ikh

1 0

Boost.Thread docs and more (1.32)
by Johan Nilsson 15 Mar '05

15 Mar '05

Hi, I was browsing the website for Boost.Thread 1.32 updates and became somewhat confused. This is just the few items I noticed during a quick browse. 1. The library isn't mentioned along with other updated libraries on the start page. 2. Quote from 'Design/The Next Phase': "The next phase will address more advanced synchronization concepts, such as read/write mutexes and barriers.". I guess this is just one of the mentioned "remaining inconsistencies" from the release notes. 3. In the release notes it is also stated that recursive_mutex is now implemented using a critical section under Win32. AFAIK this was already the case with 1.31 (or perhaps even earlier?). I also glanced a bit at the recursive_mutex implementation under Win32 and it looks a bit weird to me (this is just an extract): --- recursive_mutex.cpp --- ... recursive_mutex::recursive_mutex() : m_mutex(0) , m_critical_section(false) , m_count(0) { m_critical_section = true; if (m_critical_section) m_mutex = new_critical_section(); else m_mutex = new_mutex(0); } recursive_mutex::~recursive_mutex() { if (m_critical_section) delete_critical_section(m_mutex); else delete_mutex(m_mutex); } ... The if/else clause exists in virtually all methods even though there is no way to affect it from client code. Is this some kind of preparation for future improvements, just some cut and paste from recursive_try_mutex, or ...? 5. Last (but not least): Why aren't the more recent contributors mentioned a bit more up-front in the documentation - I think they deserve a lot more credit than this? // Johan

1 0

Re: [boost] No tests on como?
by Bronek Kozicki 15 Mar '05

15 Mar '05

Bronek Kozicki <brok(a)rubikon.pl> wrote: > 2 como does not support dynamic libraries at all; this is going to be > improved with next version (hopefully to be released soon) my poor memory does not serve me well. Apparently there is some support for consuming DLLs (like system libraries), however support for building them is still lacking. B.

1 0

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

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

[Boost-bugs] [ boost-Bugs-1163077 ] EdgeListS = setS for adjacency_list does not work
by SourceForge.net 14 Mar '05

14 Mar '05

Bugs item #1163077, was opened at 2005-03-14 10:48 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=1163077&group_… Category: graph Group: None Status: Open Resolution: None Priority: 4 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: EdgeListS = setS for adjacency_list does not work Initial Comment: The adjacency_list class template requires the EdgeListS selector to indicate a Sequence container (and may very well require the default listS). setS, for instance, does not work. See http://lists.boost.org/MailArchives/boost-users/msg09557.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1163077&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

[wiki] New content filtering to reduce spam
by Jeff Garland 14 Mar '05

14 Mar '05

All - I've instituted a new content filter on the Wiki to try and cut off the spamming without going to a login or other user intrusive mechanism. The timing of this feature turned out to be important as a sophisticated spambot that evades the ip banning strategy by using many different ip addresses (presumably using zombie machines) has been attempting to SPAM the wiki all day today. The new content filter has sucessfully stopped this bot. Note that if a spammer is successful I am now reverting all spam content from the Wiki history so that there is no change of googlebot finding it. For the moment, I'm not going to publish the regular expressions I'm using to filter, but suffice to say, normal boost content should be unaffected. If you get an error indicating content has been blocked due to spam, send me and email. Thanks, Jeff

2 1

Hash function review
by John Maddock 14 Mar '05

14 Mar '05

A little late in day, here we go: >What is your evaluation of the design? The design is basically fixed by the TR, so there's not much to review here. The extensions to the TR proposed by Peter Dimov, and implemented here look fine to me as well. >What is your evaluation of the implementation? Modulo the suggestions to the pointer hashing, it looks very good: I spent some time examining the floating point implementation, along with the associated test cases, and everything that could be tested looks like it is. I agree with those opinions expressed here that it's better to have a reliable implementation, that produces good hash values, than an artificially fast version that produces bad hash values. I have one query regarding hashing of integer types, regarding hashing of long long, Daniel says: "Also, it will need a different hash function to the other integer type as the current one won't take account of the higher bits. I want to take my time over things like this and get it right." But I think this is a (mostly theoretical) issue already: type long may have more bits than size_t does. I don't think this is a big issue though, it should effect very few platforms, and shouldn't hold up acceptance of the library. >What is your evaluation of the documentation? Also looks very good, I would like to see some more description of how the implementation differs from the TR (all the bits are there in the docs, it's just not clear which are part of the TR, and which are the extensions). >What is your evaluation of the potential usefulness of the library? Can't believe we haven't had this in Boost already. It's about time. >Did you try to use the library? With what compiler? Did you have any >problems? I've spent some time examining and running the test cases, everything that should pass does so with: gcc-3.3.2 Intel 7, 8.1 and 9Beta VC++ 6, 7, 7.1 and 8Beta. The tests are failing with Borland, due to a problem with Boost.Test. >How much effort did you put into your evaluation? A glance? A quick >reading? In-depth study? A couple of hours reading the code and the docs. >Are you knowledgeable about the problem domain? I don't claim to be any kind of expert in hashing. >Do you think the library should be accepted as a Boost library? Yes, please ;-) John.

1 0

[test] still regressions with IsDebuggerPresent()
by Stefan Slapeta 14 Mar '05

14 Mar '05

There are still regressions caused by a missing definition of IsDebuggerPresent(). These failures have been introduced by the recent changes in boost.test. What is to do here? see http://tinyurl.com/6vdo9 Cheers, Stefan

2 1

Sockets: proposal for a library design
by Boris 14 Mar '05

14 Mar '05

I updated the Wiki pages for a net library at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. After collecting all the information I found at the Wiki pages for the socket and multiplexing library I try to explain how a net library should basically look like. The proposal includes various I/O models and is based on I/O streams. As usual any comments are appreciated, Boris

6 10

[serialization] current CVS not working for CW
by Joaquín Mª López Muñoz 14 Mar '05

14 Mar '05

Hello, None of the CW compilers being tested seems able to build the serialization lib against the current CVS. I seem to recall there were no problems of this kind a month ago or so. I know the author's probably aware of this, just wanted to know about the status of this problem. Thank you, Joaquín M López Muñoz Telefónica, Investigacion y Desarrollo

4 4

RE : FSM Review : Performance Issues
by jdspalding＠comcast.net 14 Mar '05

14 Mar '05

******************************************************************************* BOOST Re: FSM Review : Performance Issues. I'd like to add some overall comments about the FSM's perceived performance issues. To clarify my bias, previous comments, I have already submitted a positive review, focusing on usage issues. Context: On Sat, 12 Mar 2005 , Dave Garland wrote >On Sat, 12 Mar 2005 15:57:10 -0500, David Abrahams wrote >> >> Haven't a few people been reporting that they won't even begin to >> apply this one because of particular limitations? Anyone who needs >> higher performance won't even get started. >Sure, and on the other hand we've had at least one testimonial that this was >the best fsm library they found -- served them well in a project. I've heard >the same sort of argument from people comparing std::string to a char*. >std::string: Discussion : I believe the discussion of performance in the proposed boost FSM library is going in an unrewarding direction. Undefined design possibilities are being weighed against a working system. (notice : I am going to be sympathetic to the "working system".) On the "design possibilties" side there seem to be a number of major issues. - double dispatch is O(n), we'd like O(1). - overall performance is slow, state transitions in XXX nSec are too slow for a proposed application. - some people have the idea that the techniques used to allow FSM to extend over multiple translation units could be improved. Again and again someone writes in and says the design does not feel right, if we did XXX, FSM is likely to be able to fix YYY. However, the concrete solution is not yet conceived, and for now, a general plausability argument will have to do... Proposal: I think we could adopt a structured approach to evaluate these competing claims. A) One viewpoint of the FSM library is through the filter of application performance tradeoffs. IMHO we have exhausted the qualitative approach, and need the definiteness of the quantitative. I would think the FSM critics have the obligation here to provide support to their view, that FSM performace is inadequate. A.1) It is said that performance considerations will keep FSM from being considered for some applications. => Then could we specifically, and quantitatively define a class of applications for which FSM, as it exists today, would be inadequate? (model app) - in the timed performance area, what are the model app's FSM performace metrics, such as number of states, use of orthogonal states, depth of state nesting, number of events fired per second, number of events handled per second? - what are the model app's non FSM performance metrics, perhaps normalized to FSM metrics, such as lines of code or execution time, per state change, or per event fired? - please also include some details about the context for the app's execution, usage area, etc., to assist the readers from other experience domains. A.2) It is said that O(n) double dispatch is inadequate, that better design is required for acceptance. => To really assert this we really have to have a complete model of FSM's runtime behavior. Since this is different in different usage scenarios, what we really need are several usage scenarios, and an analysis/measurement of where FSM spends its time. I think Andreas has mentioned that he thinks other areas than double dispatch are more important. IMHO this is a quantitative issue, per usage scenario. B) A second viewpoint of the FSM library is that of usage requirements in the application's code. Here there are at least two areas of contention - B.1) The implications of the requirement for compilation in multiple translation units. - B.2) The overal ease of use of the FSM library's API. Finally, here is my submission of data for a model usage of FSM, in the above framework. ****************************************************** Quantitative data : example : from J. Spalding's use of FSM area : industrial control. A.1) Performance metric Number of states : 15-20. maximum state nesting depth : 5. use of orthogonal states : no. maximum number of events per second (burst) : 10. events handled per second (burst) : 10. context : Use of FSM in a machine control application. FSM controls application's execution "mode", and the hardware error monitoring state. remarks : model app not stressing FSM performance. A.2) Runtime behavior profile not carried out. FSM performance trivial component of model application. B.1) Multiple translation units. model application code was broken across multiple translation units, no particular problems occurred. B.2) API Ease of Use. API was expressive, easy to configure to solve the problem. The only difficulties encountered were found in tracing compile time initial useage mistakes. This is also a strength of the approach, incorrectly configured FSM machines will not compile. *********************************************************** My Opinion : per FSM acceptance into Boost: - I like the FSM API, think performance today is adequate for many/most applications, think UML connection is a plus, voted for FSM acceptance. - Seeing statements such as 100 nSec cost per event handled prevents serious use of FSM, does offend me, without a supporting application performance model/context. IMHO Andreas has requsted such info many times, and has not been rewarded with any quantitative data. - IMHO, If we were evaluating FSM for an engineering use today, it would be accepted, due to good API, good documentation. The only way FSM could fail is if FSM code grabbed > (XX) % of the app's compute cycles, or made an unacceptable latency hit. The alternatives, at least in the boost discussion of it, are all proposed concepts requiring evaluation & development. - Further it would be quick work to use FSM to prototype a proposed use, and numerically evalute its time/space/latency cost. Just write the proposed FSM on the target machine, install it with a test harness that puts out events at the required rate, and you have a use/not use decision with hard data. If FSM were included in Boost, then this evaluation might be accomplished a number of times in the future, and the fsm interest group may acquire data justifying a performace oriented new implementation/library. ***********************************************************

1 0

Re: Sockets: proposal for a library design
by Don G 13 Mar '05

13 Mar '05

Hi Boris, Thanks for all the effort and getting something posted! On first blush, my thoughts are as follows: I would suggest that a proposed Boost.Net library should focus on networking in a more abstract manner, and not be merely a socket encapsulation. IMHO, sockets are a terrible API and should be hidden as fast as possible. A socket wrapper class is appropriate, but I would not go to any trouble to change the socket API. Simply wrap the resources and provide portable access to the underlying system. The real end-user part of the Net library should not talk about sockets (unless one provides a method like get_native to return the socket handle, and that method is defined as non-portable). I think all desired I/O models should be available at run-time (see below). In my own work in this area I have seen that this approach does not greatly effect the implementation. In other words, there is virtually nothing to be gained by making async I/O optional at compile-time. As others have also suggested, I would agree that the net facilities not be tied up into I/O streams. It would be better to provide the network facilities and then layer on I/O streams for those that want it. There are really only a few abstract entities to worry about: Url, Address, Stream, Datagram, Acceptor. In my work (not related to Boost), I've also created a Network class to serve as the abstract factory and contain a thread pool for doing the async I/O. I believe your diagrams use "Client" and "Server". I think these terms are a bit too generic. I prefer the term "Acceptor". Usage examples: shared_ptr<Network> net (new SomeSpecificNetwork(some_arguments)); Url some_url = "http://www.boost.org"; shared_ptr<Address> addr = net->new_address(some_url); shared_ptr<Stream> str = addr->new_stream(); str->connect(); // now it's connected (blocking) shared_ptr<Address> localhost = net->new_local_address("ntp://"); shared_ptr<Datagram> dg = localhost->new_datagram(); // on the ntp port localhost = net->new_local_address("ftp://"); shared_ptr<Acceptor> ac = localhost->new_acceptor(); // "ftp" port str = ac->accept(); // blocking accept I've omitted any nonblocking/async methods for brevity. IMHO, blocking, nonblocking and free-threaded-async-w/callback are the only models worth providing. These models can be ported anywhere and can be implemented via whatever mechanism is best for the given platform. A select() based version can be made to work just about anywhere with minimal #ifdef logic, but may be less than ideal when the system supports poll() or NT I/O completion ports. One thing I think is essential when using a blocking model is cancellation. For example, I have a reset() method on Acceptor, Address, Datagram and Stream that can be called at any time to cause blocking methods to terminate with a cancel exception (obviously this must be from another thread). Ironically, these reset() methods meant I could not use blocking socket calls to implement my blocking methods - recv() cannot be canceled once it blocks (at least not portably)! The big issue in nonblocking I/O is how to notify the application that things have changed and now would be a good time to try more I/O. I like the free-threaded callback for this as it fits closely with async I/O and that way the nature of the I/O mechanism can still be encapsulated. Throughout the above I use the term "free threaded callback". By that I mean that the user supplied callback will be invoked directly by a worker thread. The reason for this is that it is the only way to approach the efficiency of a hand-rolled select/poll loop. When select() returns, the fd_set would be examined and steps taken to prepare for the next call to select(). Since multiple operations could complete, whatever state machines exist are pumped inside a processing loop between select() calls. When the abstraction comes in and hides the loop behind callbacks, if the callbacks are made directly, we add only the overhead of making the callbacks. If, on the other hand, all callbacks where marshalled out, the loop would not have the information needed to formulate the next call to select() and would likely have to be interrupted repeatedly to get to the proper state. The dangers of this approach should be obvious (deadlock to say the least). The user code is now forced to understand the execution model in order to properly code a callback. What I found is that a short list of allowed operations is sufficient. Any async I/O methods are OK, as are nonblocking methods, etc.. After that (long winded) explanation, what I have also seen is that very few applications need the performance that free-threaded callbacks provide and would opt out of the complexity if they could. My solution to this was an auto-marshalling callback. I'm not sure what facilities Boost provides for queued function<> calls, but the idea is to provide a callback that queues a callback. The pseudo code for me was something like this: str->async_read(buf, n, channel.bind_async_call(this, &This::foo)); The "channel" was my entity that could enqueue calls. The "(this, &This::foo)" would actually be a function<> object or something. The return from bind_async_call() is a function<> object that performs the actual call to channel.async_call() passing the user callback. Whew! Slightly more than $0.02, I know. :) Best, Don --- Boris <boris(a)gtemail.net> wrote: > I updated the Wiki pages for a net library at > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. > > After collecting all the information I found at the Wiki pages for > the socket and multiplexing library I try to explain how a net > library should basically look like. The proposal includes various > I/O models and is based on I/O streams. > > As usual any comments are appreciated, > Boris __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

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