- Boost - lists.boost.org

Patch - boost::shared_ptr used in redefinition of global operators new/delete
by Korcan Hussein 17 Mar '05

17 Mar '05

shared_ptr causes an infinite recursion when used in the redefinition of global operators new/delete. This is caused by sp_counted_base_impl being allocated on the heap via global operators new/delete. There currently are alternative allocation schemes which clients can select via macros but all current schemes (eventually) explicitly invoke global operators new/delete to de/allocate memory. The proposed patch Ive included just adds another choice of allocation scheme to sp_counted_base_impl with the existing ones by doing exactly the same method. It forwards de/allocation requests to C memory functions std::malloc and std::free. Clients of shared_ptr may select the alternative allocation scheme by defining the macro BOOST_SP_USE_MALLOC_ALLOCATOR before inclusion of shared_ptr/smart_ptr.hpp. >From Korcan Hussein.

1 0

Re: [Boost-testing] Re: [test] [thread] including unit_test_suite_ex.hppfails to compile
by Caleb Epstein 17 Mar '05

17 Mar '05

On Fri, 11 Mar 2005 10:25:53 -0500, Gennadiy Rozental <gennadiy.rozental(a)thomson.com> wrote: > > "Caleb Epstein" <caleb.epstein(a)gmail.com> wrote in message > news:989aceac050311071548498e@mail.gmail.com... > > One of the Boost.Thread library test programs (test_mutex.cpp) fails > > to compile due to the inclusion of the header file > > <boost/test/unit_test_suite_ex.hpp>. This file includes another file > > which does not exist: > > > > http://tinyurl.com/3t83x > > > > This test seems to be failing across several platforms. > > boost/test/unit_test_suite_ex.hpp is not needed anymore. Use > boost/test/unit_test.hpp instead. Here's a patch. Can someone please apply? I don't have write access to the repository: Index: libs/thread/test/test_mutex.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/test/test_mutex.cpp,v retrieving revision 1.11 diff -u -b -r1.11 test_mutex.cpp --- libs/thread/test/test_mutex.cpp 19 Aug 2004 19:38:39 -0000 1.11 +++ libs/thread/test/test_mutex.cpp 14 Mar 2005 14:10:03 -0000 @@ -17,7 +17,6 @@ #include <boost/thread/condition.hpp> #include <boost/test/unit_test.hpp> -#include <boost/test/unit_test_suite_ex.hpp> #define DEFAULT_EXECUTION_MONITOR_TYPE execution_monitor::use_sleep_only #include <libs/thread/test/util.inl> -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: Boost.Threads Bug (recursive_try_mutex)
by Jonathan Biggar 17 Mar '05

17 Mar '05

Mark Rodgers wrote: > Bill, > > recursive_try_mutex::do_trylock() (BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE > implementation) contains the following: > > assert(res == 0); > > Surely that should be > > assert(res == 0 || res == EBUSY); This bug still exists in 1.32! -- Jon Biggar Levanta jon(a)levanta.com

2 1

[Proposal] Library which adds n-arity operators support to C++ plus reducing temporaries.
by Pavel Chikulaev 16 Mar '05

16 Mar '05

I'm currently working on library "Lazy". Library description: Library eases creation of classes which needs lazy evalution and n-arity operators and I guess will be as efficient as Gnu MP class but with pretty syntax. (Not yet tested but I do believe it is so). Library features are: * n-arity operators support; * operator aliasing, such as a + -b will be computed as a - b; * custom operators; * no unnecessary temporaries during evalution and assigning; * easy usage. Library's sample usage: //Matrix.h #include "lazy.hpp" class transpose_tag {}; //Tag class class Matrix { LAZY_CLASS(Matrix) static lazy::type<Matrix> Matrix_; //Similar to Andrei Alexandrescu's Type2Type template public: Matrix(); Matrix(const Matrix &); void swap(void Matrix &); //Libray won't work without swap function. //If name of your swap function isn't swap then use LAZY_CLASS_EX(Matrix, YourSwapFunctionName) Matrix & operator = (const Matrix &); //lazy constuctors which enables lazy operators Matrix(LAZY_OP(Matix_ + Matrix_)); //Matrix operator +(Matrix, Matrix) Matrix(LAZY_OP(Matrix_ * Matrix_)); //... Matrix(LAZY_OP(-Matrix_); Matrix(LAZY_OP(Matrix_ + Matrix_ * Matrix_)); //ternary operator //Now enable operators LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ * Matrix_); LAZY_ENABLE_OP(Matrix_ = -Matrix_); LAZY_ENABLE_OP(Matrix_ = Matrix_ + Matrix_ * Matrix_); //Actually we can make declaration of lazy operators and enabling them using only one macro e.g. LAZY_CONSTUCTOR(Matrix_ = Matrix_ * Matrix_ * Matrix_); //Aliasing LAZY_ALIAS(Matrix + -Matrix_ = Matrix_ - Matrix_); //Custom operation Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_))); LAZY_ENABLE_CUSTOM_OP(transpose, Matrix_ = lazy::custom_op<transpose_tag>(Matrix_)); //same as Matrix transpose (const Matrix &) but there won't be any temporary objects }; //Matrix.cpp Matrix::Matrix(LAZY_OP(Matix_ + Matrix_) op) { //Construct matrix object //lhs matrix = op._1 //rhs matrix = op._2 } Matrix::Matrix(LAZY_CUSTOM_OP(transpose_tag, (Matrix_) op) { //Construct matrix object tranposed to op._1 } //etc //Now the use of Matrix class Matrix a, b, c, d; //... a = b + c; //No tempories at all //Using normal practice it will take two temporary objects (no NRVO or RVO ) a = b + -c; //Will be evaluates as a = b - c; No temporaries again //Using normal practice it will take three temporary objects (no NRVO or RVO) a = b + c * d; //Will use ternary operator. No temporaries again a = transpose(b); //Custom lazy operation. No tempories again Maybe the library is very similar to uBLAS's matrix_expression and vector_expression. But with my approach there is no need to code matrix_expression and vector_expression at all and it is easy to create new classes which needs lazy evaluation and n-arity operators. So what do you think? Is there any similar approaches available? Is there any need of such library?

2 7

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

16 Mar '05

In-Reply-To: <012301c5299e$0e2b2f90$6501a8c0@pdimov2> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > This is because you ignored the "use_a" member when computing the hash > value. I didn't ignore it; hash_value uses it, albeit not in the best way. > We can't prevent these mistakes in general; if you omit a member > (that affects the equivalence relation) when computing the hash value, > the computation is just wrong. In this case the computation was correct, and indeed carefully chosen, but produced needlessly many collisions. > A hash_value that encodes the type will just hide the error from you if > a and b have different types The point is that even the corrected version is needlessly throwing away some valuable entropy. It's not about hiding the error, it's about having the best possible hash function. -- Dave Harris, Nottingham, UK

3 3

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

16 Mar '05

In-Reply-To: <01b201c52987$e0bbb950$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > If you _know_ how the default hash function will perform on your key > set, you can make the decision of whether to use it or not, and if the > hash function is standard, you do not have to re-evaluate your decision > each time you change platforms. I do appreciate the benefits of stability. What isn't clear is whether it trumps hash quality. This is a judgement call, in that it partly depends on which issue is more important to you. Ultimately if you want stability you can get it by using your own hasher. If you want the best quality the platform can deliver, then that's intrinsically non-portable; it should be provided by the vendor but in a standard way. We could both be made happy if boost provided 2 hashers as standard, one for stability and one for quality. However, I don't think we want to go that route at this stage, and anyway there can only be one default. This is /not/ a deal-breaker for me. I won't reject the proposal because it favours stability over hash quality. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <01c301c52989$d50a2f40$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > I think that it is better to fix the zero trap in hash_combine, because > this does not depend on users remembering to initialize the seed to > default_seed, instead of zero. Did you see my suggestion of changing the primitive hash_value functions instead? That also does not depend on users remembering to initialise the seed. size_t hash_value( int v ) { return size_t(v) + default_seed; } And similarly for long, etc. Is there a reason to reject this? > 2. Add a hash_range overload that takes a seed. > > 2a. void hash_range( size_t & seed, It first, It last ); > 2b. size_t hash_range( size_t seed, It first, It last ); > 2c. size_t hash_range( It first, It last, size_t seed ); > > which are listed in order of my preference. So we're talking about a family of 3 functions: 2a: void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); size_t hash_range( It first, It last ); 2b: void hash_combine( size_t &seed, T value ); size_t hash_range( size_t seed, It first, It last ); size_t hash_range( It first, It last ); 2c: void hash_combine( size_t &seed, T value ); size_t hash_range( It first, It last, size_t seed=0 ); I think 2b is very error-prone, because of the lack of consistency between how hash_combine and the seeded version of hash_range return their results. 2a is less error-prone, but it seems needlessly confusing to have the two versions of hash_range return their results in different ways. In general there's a lot of similarity between hash_combine and hash_range which those versions fail to bring out. I'd rather be more consistent, eg: (a) size_t hash_combine( size_t seed, T value ); size_t hash_range( size_t seed, It first, It last ); or: (b) void hash_combine( size_t &seed, T value ); void hash_range( size_t &seed, It first, It last ); (Perhaps with overloads to catch passing a non-size_t first argument.) I don't see much value in adding a hash_range which doesn't take a seed. Especially with (a), because we can easily pass 0 explicitly. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <019d01c52985$a04f54f0$6801a8c0@pdimov> pdimov(a)mmltd.net (Peter Dimov) wrote (abridged): > You also need equal_ptr<MyType>. Indeed. > Also, it is easy to break the above unordered_set my modifying some > of the MyTypes. Yes, that's something to be aware of. I use the approach on types which are immutable, so it doesn't arise. > size_t Derived::hash_value() const > { > size_t seed = my_unique_value; > > hash_combine( seed, Base::hash_value() ); > hash_combine( seed, m_value ); > > return seed; > } That leaves the problem of assigning a different my_unique_value to each subclass, bearing in mind that different subclasses may be written by different people, teams or organisations. Without some kind of system people may just copy and paste code from one class to another and not change the value. -- Dave Harris, Nottingham, UK

2 1

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

16 Mar '05

In-Reply-To: <989aceac05031508512fb3bd43(a)mail.gmail.com> (reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfe r-encoding:references; b=R/dgT5RcmFTM4l6wo1FsmJV0WmZRxxS4UwfDvrZfxiBXu3i07NjqdqXmY0k93EfeA2rzuv0U dyun6iZo4Mn86mrySznULAY97Xn/zgqN3tU49cmIB/EtvwNWQzyHhnrH/iKu8pfDQoo6swyqX4 AJ8ih0MJXLu4umRrhBw7YSD2E=) wrote (abridged): > > However, it yields hash values for int * different to the values for > > char *, so with the current design aims we can't use it. > > It also has the undesirable side-effect of making the hash value > depend on the machine endianness. The same set of integers would hash > to different values on (say) Sparc and Intel machines. True - another variant of the stability issue. -- Dave Harris, Nottingham, UK

1 0

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

16 Mar '05

In-Reply-To: <d174ak$vp3$1(a)sea.gmane.org> nesotto(a)cs.auc.dk (Thorsten Ottosen) wrote (abridged): > are you saying we don't want to hash a Base* as a void*, but use > object properties instead? Sometimes. It's a reasonable thing to do. It's what my own app actually does. It shouldn't be the default, of course. Mainly I'm saying that equality tests sometimes need to be polymorphic, and when they are the corresponding hash_value needs to be as well. So sometimes we will be comparing hash values from different types. (Other people here have claimed that never happens.) -- Dave Harris, Nottingham, UK

1 0