- Boost - lists.boost.org

Regression report for Releases?
by Jeff Garland 23 Mar '05

23 Mar '05

Do we have the results of the 1.32 regression tests somewhere? I'm curious what the actual final release results were, but I can't find them anywhere. I thought at one time we maintained them on the website? Anyway, it be really nice to snapshot the final test web pages and include them in the release package. That way everyone could simply look at the results and get an idea about how their compiler/platform might work with that release -- of course that should be on the website too. Jeff

7 45

[Boost-Bugs] [ptr_container]
by Pavel Chikulaev 23 Mar '05

23 Mar '05

Hi all, It's quite strange that I can't write something like that: ptr_vector<int> v; ptr_vector<int>::const_iterator i = v.begin(); //won't compile on VC7.1 ptr_vector<int>::iterator j = v.begin(); //It works ptr_vector<int>::ptr_const_iterator ip = v.ptr_begin(); //won't compile on VC7.1 ptr_vector<int>::ptr_iterator jp = v.ptr_begin(); //it works but const ptr_vector<int> cv; ptr_vector<int>::const_iterator k = cv.begin(); //works as expected ptr_vector<int>::const_iterator kp = cv.ptr_begin(); //works as expected but std::vector<int *> v2; std::vector<int *>::const_iterator = v2.begin(); //works just fine Obviously, this is a bug. -- Pavel Chikulaev

1 0

[program_options] Patch to fix 64bit error and warning
by Jonathan Wakely 23 Mar '05

23 Mar '05

The attached patch fixes a 64 bit portability problem where std::string::size_type is assigned to unsigned, which is shorter than size_t on x86-64 and so will be truncated. This means the following comparison to std::string::npos is always false. Patch also prevents a warning with GCC; since the compiler doesn't know that boost::throw_exception never returns it thinks that cmdline::translate_property() can reach the end of the function without returning. The patch simply removes the "else" so that throw_exception is always called if control reaches the end of the function. A better solution might be to mark boost::throw_exception() with __attribute__((unused)) for GCC. The first change is required, the second is optional. jon -- "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

2 3

Re: Asynchronous I/O
by Hans Malherbe 23 Mar '05

23 Mar '05

--- Don G skryf: >Of the mechanisms discussed, I am not sure I understand what you mean >by async I/O with only one thread. I can imagine a nonblocking/select >style approach that has no extra threads, but as soon as the main >thread is not waiting on I/O itself (my interpretation of "async"), >there needs to be threads to do the waiting. The main thread does the waiting. In Windows NT you will either wait on the event flag in the OVERLAPPED structure or specify a completion routine and wait in an alertable state with the SleepEx or one of the *WaitFor*ObjectsEx functions. Groete Hans Malherbe ______________________________________________ "This information is intended only for the person or entity to which it is addressed and may contain private, confidential, proprietary and/or privileged material and may be subject to confidentiality agreements. Any review, retransmission, dissemination, or any other use of or taking of any action in reliance upon this information, by persons or entities other than the intended recipient, is prohibited. If you received this in error, please contact the sender and delete the material from all storage media. The company is neither liable for proper, complete transmission of the information contained in this communication, any delay in its receipt or that the mail is virus-free"

1 0

Re: Re: FSM review
by Andreas Huber 22 Mar '05

22 Mar '05

Rob Stewart wrote: [snip] > Without digging out the previous messages and confirming the > matter, I think Jonathan's suggestion, quoted above, was simply > that *when* the user wants separate translation units *and* the > features that would typically require tight coupling, you could > introduce a weaker link -- some form of indirection -- that would > slow the resulting FSM or even complicate its specification, but > would at least permit the functionality. I think that's close to what I understood... [snip] > This is right on target. *Since* the current design, with all of > its requirements is so much slower, then the onus is on Andreas > to explain why the requirements his library meets exceed those > met by other FSM libraries and directly lead to the performance > overhead. Clear distinctions regarding the performance > improvements gained by avoiding the performance draining features > in an FSM while still using this library will help to demonstrate > that situation, too. [and] [snip] >> Normally, in designing a framework one considers a small handful >> (say two to six) of alternate designs which view the subject matter >> from completely different perspectives. In your case, what were >> those alternate designs? > > Note that Jonathan is asking that those alternatives be > documented. That way, other developers who wonder why you didn't > try X will see that you did and they'll see why you decided it > was not appropriate. I have agreed to add such documentation in one of my previous answers. >> Let me make one last attempt to explain what should be in the >> rationale. Look at section 16.2 of "The C++ Programming Language", >> 3d ed. Here Stroustrup gives two design criteria for a containers >> library, and then discusses three designs: >> >> "Specialized containers and iterators" - satisfies the first >> criterion "Based Containers" - satisfies the second criterion >> "STL" - satifies both criteria >> >> I'm not suggesting that you give such a detailed treatement as >> Stroustrup. However, if you were to give a similar overview of the >> landscape of possible FSM frameworks, and thoughtfully discuss the >> tradeoffs in flexibility and performace which each involves, >> reviewers might have some confidence that you are aware of the >> techniques which might be used to construct a fast, flexible FSM >> framework, and have carefully considered the design. >> >> This type of overview would probably be a useful component of any >> library's documentation; in your case it is made absolutely >> essential by the performance figures you cite. > > I don't think I can add any more to that. I think it is > reasonable and clear. It is but I'm not sure how this is relevant (I already agreed to add such documentation). -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

implicit_cast has been removed, but this is sad
by Jens Theisen 22 Mar '05

22 Mar '05

implicit_cast was once in cast.hpp, but as the comments says, it has been removed due to uncertain purpose. I have to purposes of which I am wondering how to do them otherwise: 1. take the address of the conversion 2. initialise a std::vector< int > with a boost::assign::list_of in a constructor initialiser The latter is a bit subtle. list_of uses a templated conversion operator to containers (but technically everything) and std::vector's ctor are then all tried with taking converted arguments, which leads into an ambiguity. Using implicit_cast solves the problem, since then the constructor call to std::vector and the call to the conversion operator in list_of are both taken as user defined conversions, and there can only be one of them. vector< int > v = list_of(1)(2); // works vector< int > v(list_of(1)(2)); // ambiguous ctor() : v(implicit_cast< vector< int > >(list_of(1)(2))) { } // ambiguous ctor() : v(list_of(1)(2)) { } // ambiguous Any thoughts on this? Regards, Jens

4 12

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

22 Mar '05

In-Reply-To: <d1on4o$ijr$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > > Admittedly hash_combine is also (nearly) redundant, being definable > > as: > > > > void hash_combine( size_t &hash, const T &t ) { > > hash_range( hash, &t, &t+1 ); > > } > > > > if T does not overload address-of. Note this is currently true because hash_range is defined as having the effect of: void hash_range( size_t &hash, It first, It last ) { for (; first != last; ++first) hash_combine( hash, *first ); } so calling hash_range on a range of 1 element returns the same result as calling hash_combine with that element. > Since nested vectors give different hash values to their flattened > form, I don't think a single element vector should have the same hash > values as it's element. It doesn't. One is: return hash_value( t ); the other is: size_t hash = 0; hash_combine( hash, t ); return hash; All the proposed definitions of hash_combine make these different. There is at least an xor, and possible a constant added. -- Dave Harris, Nottingham, UK

2 1

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

22 Mar '05

In-Reply-To: <003501c52a54$a28c4b90$6601a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > size_t hash_value( int v ) { > > return size_t(v) + default_seed; > > } > > I wonder what do we gain from this. As you pointed out when I first suggested adding the constant in hash_combine: This would mean N fixes for a sequence of length N, when one simple fix is enough. The initial value of the seed is arbitrary so we can vary it at will. hash_combine, on the other hand, is based on research and has apparently been selected as one of the best amongst the shift+xor family. This doesn't mean that it's sacred, just that if we change it we'll no longer be able to just point at a PDF as a rationale but will need to do our own research (which might be a good idea anyway, though.) :-) > From the point of view of hash_combine the effect is the same The difference shows when you have something like: struct A { int x, y; }; struct B { A a, b, c; }; size_t hash_value( const A &a ) { size_t hash = 0xbead1; hash_combine( hash, a.x ); hash_combine( hash, a.y ); return hash; } size_t hash_value( const B &b ) { size_t hash = 0xbead2; hash_combine( hash, b.a ); hash_combine( hash, b.b ); hash_combine( hash, b.c ); return hash; } Here hash_combine is called 9 times, but hash_value(int) is only called 6 times, so we get different results depending on where the constant is added. > and we now rely on the user overloads of hash_value to not produce > a zero. That's surely reasonable. The hash_value of any user-defined class should be defined in terms of the hash_values of primitives, and boost provides all of those. > This reflects their intended use. The two argument overload is used > when one has a whole range and wants its hash value, as in the > hash_value overload for std::vector, for example. I actually think this is going to be fairly rare. This is mainly because there will usually be a constant thrown in to represent the type of the object. (I appreciate you won't do that for std containers, but I maintain its a good idea for user-defined types.) The 2-argument version is strictly redundant as it must be defined in terms of the 3-argument version. It's just a convenience function, used mainly by the std containers. Admittedly hash_combine is also (nearly) redundant, being definable as: void hash_combine( size_t &hash, const T &t ) { hash_range( hash, &t, &t+1 ); } if T does not overload address-of. Incidently, do you agree we will sometimes want to pass a hash value as the second argument to hash_combine? Like: hash_combine( hash, hash_range( first, last ) ); hash_combine( hash, obj.get_hash( some_arg ) ); If not, then maybe we should have a hash_combine that just combines hashes. At the moment the combining is mixed in with the getting; it's not a very orthogonal API. -- Dave Harris, Nottingham, UK

3 3

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

22 Mar '05

In-Reply-To: <004c01c52edb$d07ee5e0$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > > Is it worth considering using x + x / sizeof(*p) instead? > > This will not work for incomplete types, including void. Good point :-) > I'd prefer equal hash_values for an incomplete T*, complete T*, > and void* with the same value. Indeed. Presumably this means casting to void* eg for the case where sizeof(void*) != sizeof(char *). > We'll lose one potential bit of enthropy when alignof(x) == 16, but > this seems sufficiently rare in practice. I was a bit concerned about cases where the heap produces a de facto alignment. Especially if there is a different pool for each size of object, or a user-defined X::operator new() that allocates from a huge array of X. I guess it can't be helped. -- Dave Harris, Nottingham, UK

1 0

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

22 Mar '05

In-Reply-To: <007b01c52ede$3ceefd80$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > So, in my opinion, your original suggestion is still the best one, even > though I did not seem to agree at first. ;-) OK. > > If not, then maybe we should have a hash_combine that just combines > > hashes. At the moment the combining is mixed in with the getting; > > it's not a very orthogonal API. > > ... yes, hash_value( size_t ) is the identity function partly for this > reason. Cool. (And this is another argument for adding the non-zero fix in hash_combine rather than hash_value.) -- Dave Harris, Nottingham, UK

1 0