March 2005 - Boost - lists.preview.boost.org

[logo] what I prefer
by Gennadiy Rozental 17 Mar '05

17 Mar '05

Hi, I wanted to share my thoughts on the logos currently submitted. But first I want to state couple things that IMO worth considering (this is driven my experience, for last release I was tried for month to invent some kind of logo for Boost.Test and obviously failed): 1. IMO logo should be transparent - essentially it should work with most pastel and white colors 2. The shouldn't be border - logo should be natural part of the page 3. No funny fonts - in long run it doesn't work 4. No funny/complex objects - it maybe fun to draw. fun to look first N times, but then it became annoying. This criteria would eliminate a lot of current submissions 6. Logo should be scalable - in a sense that it should work ok in different resolutions 7. There preferable should be something beyond the text - plain text with minimal variations doesn't initiate any recognizability Here couple logos I believe worth considering (This is not an order of my preference): 1. #99 - very solid submission. Look professional, simple. ++ could be used for icon. IMO It bring slogan: boost - blur(beyond,extend, e.t.c) the bounds of C++. May be some extra graphic symbol could be added 2. #10 - simple recognizable, easily scalable (including icon), brings a connotation of ++. Though I would definitely change a colors. May be some extra text are in order 3. #67 Even we kinda agreed that it bring unwanted associations the connotation of building blocks seems good. May be we could reorder'em differently: o o o o o o o ooo or o Also I believe it should be transparent That's about it. Genandiy

8 17

RE: [boost] [ boost-Bugs-1164057 ]boost::filesystem::exists has b ugs with UNC paths
by Martin Bonner 17 Mar '05

17 Mar '05

----Original Message---- From: Robert Mathews [mailto:rmathews@envoyww.com] Sent: 17 March 2005 14:56 To: boost(a)lists.boost.org Subject: [boost] Re: [Boost-bugs] [ boost-Bugs-1164057 ]boost::filesystem::exists has bugs with UNC paths >> Initial Comment: >> boost::filesystem::exists(path("//computer")) always >> fails, even if the computer exists. I shall call this, Issue A. >> boost::filesystem::exists(path("//computer/share")) >> always succeeds, even if the share doesn't exist. ... and this Issue B. > Can anyone actually comment on when or if this bug might actually get > fixed? It's an obvious bug, the fix is a trivial amount of work - it > comes with a patch that I've tested on Win32 .... Well, as I have indicated above, there are two separate and distinct issues. Issue B does seem like a bug to me. On the other hand, does your fix change it so that //computer/printer is reported as a filesystem? That would be a step backwards. Issue A seems correct behaviour to me. A server is *not* a filesystem - it is a place that filesystems can be found. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

function<>::contains
by Peter Dimov 17 Mar '05

17 Mar '05

I added a test case to bind that tests bind objects with function<> and function<>::contains; function<> doesn't have such test cases. In the process I patched the implementation of function<>::contains to work on MSVC 6. However contains_test.cpp will still fail on MSVC 6, because it's misnamed: it mainly tests target() and operator== and I didn't attempt to fix these. I added contains2_test.cpp to the function<> test suite that only tests contains(). It should now pass on MSVC 6. -- Peter "bind (mostly) works on VC 6" Dimov http://www.pdimov.com

2 1

[mpl] rational_c
by Andy Little 17 Mar '05

17 Mar '05

Hi again, The problem: For some Integral Constants values mpl::divides<A.,B> truncates. The solution: A new operator... mpl::rational_divides<A,B> When it is desired not to truncate, this form will preserve the fractional part by if necessary converting to a rational number. With this operator in place it is also possible to 'reduce' rationals to integers where possible and further to keep integral constants as integral types by default, knowing that conversion will be automatic if a fraction is required to prevent loss of precision. No mpl::divides<A.,B> is available if A or B is a rational types, because it is assumed that if you are using rationals you require the fraction preserving behaviour. A numeric_cast to an integral type can be used to solve this where necessary. Errors of using divides<A,B> on rationals will show at compile time. Thanks to Alexey Gurtovoy for the conversion mechanism As an example: int main() { // current division operator typedef boost::mpl::divides< boost::mpl::int_<2>, boost::mpl::int_<3> >::type int_div; // error no mpl::divides allowed for rationals /* typedef boost::mpl::divides< boost::mpl::rational_c<int,2>, boost::mpl::rational_c<int,3> >::type XXX;*/ // when some type might be a rational and rational behaviour rather than truncation is required: typedef boost::mpl::rational_divides< boost::mpl::rational_c<long,2>, boost::mpl::int_<3> >::type rat_div1; //also works on int_'s etc... typedef boost::mpl::rational_divides< boost::mpl::int_<2>, boost::mpl::int_<3> >::type rat_div2; typedef boost::mpl::rational_divides< boost::mpl::rational_int<2>, boost::mpl::rational_int<3> >::type rat_div3; // also 'promotes' to int_ where possible typedef boost::mpl::rational_divides< boost::mpl::rational_int<210>, boost::mpl::rational_int<3> >::type rat_div4; // also 'promotes' to int_ where possible typedef boost::mpl::rational_divides< boost::mpl::int_<210>, boost::mpl::integral_c<long,3> >::type rat_div5; std::ofstream os("output.txt"); os << typeid(int_div).name() <<'\n'; os << typeid(rat_div1).name() <<'\n'; os << typeid(rat_div2).name() <<'\n'; os << typeid(rat_div3).name() <<'\n'; os << typeid(rat_div4).name() <<'\n'; os << typeid(rat_div5).name() <<'\n'; } output: (VC7.1) struct boost::mpl::integral_c<int,0> struct boost::mpl::rational_c<long,2,3> struct boost::mpl::rational_c<int,2,3> struct boost::mpl::rational_c<int,2,3> struct boost::mpl::int_<70> struct boost::mpl::long_<70> regards Andy Little

2 3

[string_algo] A tiny bug in the first trimming example.
by Jurko Gospodneti� 17 Mar '05

17 Mar '05

Hi. There seems to be a bug in the first trimming example for the string_algo library. (link: http://www.boost.org/doc/html/string_algo/usage.html#id576378) My guess is the line: string str3=trim_right_copy(str2) was meant to be: string str3=trim_right_copy(str1) or otherwise the comment beside it is incorrect. Hope this helps, Jurko Gospodnetiæ

1 0

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