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

[test] [thread] including unit_test_suite_ex.hpp fails to compile
by Caleb Epstein 11 Mar '05

11 Mar '05

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. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Fixed Size Matrix
by Jason Hise 11 Mar '05

11 Mar '05

I saw that boost already has a pretty impressive linear algebra suite, with many specialized types of matrices. Though these are all very useful, I was wondering if there might be room for one more type of matrix: one which makes each size of matrix a unique type (I did not see such a matrix in the docs, but please correct me if I overlooked it and it does already exist). Using such matrices, it would be possible to validate the legality of certain operations at compile time (for instance, only matrices of compatible sizes can be multiplied). A very stripped down version of the class might look like this: template < typename T, unsigned int X, unsigned int Y > class matrix { // maintains Y rows, each containing X Ts internally }; template < typename T, unsigned int X, unsigned int Y, unsigned int Z > matrix < T, Z, Y > operator * ( const Matrix < T, X, Y > & lhs, const Matrix < T, Z, X > & rhs ); // multiplication defined only for compatible matrices Is there any interest in such a class? -Jason

8 10

Logo comments
by Jonathan Turkanis 11 Mar '05

11 Mar '05

Hi All, Here are my remarks about some of the logo candidates. My thoughts were heavily influenced by resizing some of the logos and plugging them into the documentation of the candidate Boost Interfaces library. I found that some logos which I liked isolation didn't do so well when viewed in the context of documentation. I considered preparing a demonstration showing what all the submitted logos would like when used in documentation; I decided this would be unfair, however, since a logo that doesn't look so good with the current Boost documentation might look great if the look and feel were adjusted to match the logo. As a result of the experiment, I have two general observations: A) logos which have some sort of shading, or which employ several closely-related but not identical colors, look far better than logos which don't. The logos with shading make the others look flat and boring. This immediately eliminates many of the logos B) logos with non-white backgrounds don't work well After playing around with many designs myself, I also came to the conclusion (which David Abrahams also recently expressed): C) the letters "C++" and the scope resolution operator "::" simply aren't very visually appealing. Now for particular logos. (For brevity, when I have a negative opinion about some aspect of a logo, I will state it without attempting to be polite; I don't intend to offend any of the logo authors.) 29 - The miniature version does not do it justice. There's a larger version here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostLogo. At the time Eric posted it, I though it was the best candidate (I liked variant d). However, when I viewed it in the context of documentation, it didn't work in at all, falling victim to B) above. The region where the logo sits tends to be wider than its height, so it looked either too narrow, or too high. Also, the inner detail was lost; it looked like a solid blue square. 38 - This was easily the most appealing at the time I conducted the experiment. I asked a friend, who is a graphic designer, to look at the logos, and he also picked this one. Unfortunately, to me it immediately calls to mind a pair of dice. To others, apparently, it calls to mind children's blocks. I believe this makes it less suitable than some of the other attractive logos. It's okay if a logo doesn't have an immediate association with Boost; if it has an immediate association with something unrelated, however, that's a problem. 67 - This is clearly one of the best logos. Unfortunately, when I reduced it in size and inserted it in documentation, it looked, I'm sorry to say, just terrible. Against a pure white background, the logo's gray background made it look dirty. See B), above. The answer must be to change the background color, but I'm uncertain how to do this without destroying one of the logo's most beautiful features: the tiny white border along the bottom and left edges of the logo's main elements. Without this tiny detail, the logo looks pretty flat; see A), above. I think it's important to get some concrete suggestions on how to deal with this problem before the logo is accepted. 75 - I see that a number of people find this logo attractive, but I have some serious problems with it: Whereas some logos suffer from the problem that you have to look at them too long before you understand them, this one is the opposite: it looks very nice when you just glance at it or view it out of the corner of your eye; unfortunately, it does not stand up to closer scrutiny. When I examine it, my first thought is: "what is it supposed to be?" This is not good for a logo, IMO: when you look at a logo, it should be clear that a it represents something concrete or that it is a purely abstract design. (If a concrete representation is hidden in what first appears to be an abstract design, that's okay too.) The reason I find myself asking what this particular logo is meant to represent, I think, is that it's not sufficiently complex to hold its own as an abstract design. Once I ask myself what the logo represents, I can only conclude that it depicts a stack of paper. This is a big problem: aside from the fact that Boost has little to do with a stack of paper, stacks of paper are simply uninteresting. The second problem is that the 3D effect of the overlapping rectangles make the text look flat. 83 - This is also one of the more attractive logos, but like 38 it calls to my mind associations unrelated to Boost. In particular, I immediately think of looking at paint samples or carpet swatches. 52 - This is nice but suffers from problem B) 60 - Well-designed, but contains too much detail. Also, the crescent shapes look more like cartoon images of the moon then the letter "C". 92 - The captions "Plug it in", "Pieces that fit," etc. make the logos look cluttered; otherwise they look pretty good. However, I don't buy the explanation that the logo "at first appears to be a jigsaw puzzle piece" but can also be seen as people talking around a table: - no one will know that this is the intended interpretation unless they are told. Even if someone notices the alternate interpretation, there's no clue that this is intended - the logo will *always* appear to be a puzzle piece; at best it will *also* appear to be people sitting around a table. The problem with this is that "finding a piece of the puzzle" is one of the most overworked metaphors in English. (I don't know if this is true in other languages.) Best Regards, Jonathan

14 39

[aligned_storage] problems with GCC 4.0.0 20050309
by Joaquín Mª López Muñoz 11 Mar '05

11 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 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

1 0

YALo: Yet Another Logo
by David B. Held 11 Mar '05

11 Mar '05

This should give some idea as to what I think of as a "scalable logo" or a "scale-free logo". It's rather crude yes, but that's partly the point. Instead of rendering the word "Boost" in a nice font of the same or some appropriate color, I shamelessly stole one from another logo. The colors aren't really important, because they aren't the point (a graphic artist could pick much better colors). I don't know if rounded edges are better or straight lines. And perhaps even this example has more angles than I like in a scale-free logo. Perhaps we could even do without the fins, I'm not sure. The angles could be adjusted to be more pleasing. Now some might say: "Well, Rene made an abstract looking rocket too." And that is true. But Rene's rocket has some very subtle features, like the edges near the flames, which is an area of "high entropy" so to speak. My rocket has no detail frills, and could easily be compressed to an absurdly small vector file. Perhaps something with a nonnegative amount of artistic talent could play with the idea a bit without adding too much information to the logo. I realize that the contest is closed, but I'd like to explore a more simplistic direction just to get an idea of some areas of the design space that I don't think have been hit very heavily. I don't intend the word "Boost" to be a necessary part of the logo. I just think that in large-scale contexts, a caption would be nice, whether it be on the side or the bottom or a word or a phrase. Any takers? Dave

2 1

Re: [boost] Re: Re: Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 10 Mar '05

10 Mar '05

Hi Peter, ----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 11:51 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > JOAQUIN LOPEZ MU?Z wrote: > > > > The idea is that you can alter only some part of the > > hashing scheme and benefit of the preexisting definitions: [...] > > I think I see your point. You want something like this: [...] > will automatically propagate it downwards if one invokes > hash_value on > vector<vector<vector<int> > >. Sort of, I think. Your formulation is somewhat more generic in that you pass combiners around where I rely on tag dispatching (the *_impl markers.) > Interesting, but overkill, IMO. ;-) Can't say the contrary :) I see it as I way to get everybody happy: regular users don't notice the difference and playful ones can easily plug in their superhashing schemes. Anyway. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: Re: Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 10 Mar '05

10 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 10:35 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > JOAQUIN LOPEZ MU?Z wrote: > > > > Maybe the following approach could be taken to > > allow for alternative implementations to be plugged into > > the framework: [...] > > > unordered_set<my_type,boost::hash<my_type,crypto_impl> > us; > > The proposal is not a framework, it contains two simple tools for > constructing hash_value overloads for compound types and a suite > of > _default_ hash functions. > > Alternative implementations (who may or may not use the supplied > tools) are > supported by unordered_set by simply using > > unordered_set< my_type, my_hash > us; > > There's no need to plug them in. The idea is that you can alter only some part of the hashing scheme and benefit of the preexisting definitions: template<typename It> std::size_t hash_range(It first,It last,crypto_impl) { ... } // third_party_type is an external type with its own // hash_value overload unordered_set< std::vector<third_party_type>, boost::hash<std::vector<third_party_type>, crypto_impl> > us; // here, we automatically get an impl of hashing for // strings using the crypto_impl hash_range unordered_set< std::string, boost::hash<std::string, crypto_impl> > us2; But I won't defend this to death :) I just felt like throwing the idea in. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

stl-like containers of pointers
by Felipe Magno de Almeida 10 Mar '05

10 Mar '05

I heard that boost is going to have all the stl-like containers, but with reference semantics and will treat the indirection in the iterators and etc... I would like to know where I can get this. It is not in the cvs either... Thanks in advance, -- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com

2 10

Re: [boost] Re: Re: Re: [review] hash functions
by JOAQUIN LOPEZ MU?Z 10 Mar '05

10 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Jueves, Marzo 10, 2005 6:01 pm Asunto: Re: [boost] Re: Re: Re: [review] hash functions > Thorsten Ottosen wrote: > > > > so basically you're saying that any collision is much worse than a > > slower hash function because we must use == to go through the > bucket ? > > Something like that, yes; of course it depends on the level of > slowness. > Cryptographic hash functions are typically overkill. Increasing > the number > of collisions slightly is tolerable (but can easily negate the > effect of the > faster hash function). Hitting a pathological case where a > significant > percentage of the key set maps to the same bucket is a serious > problem. > Maybe the following approach could be taken to allow for alternative implementations to be plugged into the framework: struct std_impl{}; template<typename T,typename Impl=std_impl> struct hash { std::size_t operator()(const T& x)const { return hash_value(x,Impl()); } }; template<typename T,typename Impl> std::size_t hash_value(const T& x,Impl impl) { return hash_value(x); } // standard hash_value overloads for integral types and pointers ... // template<typename T,typename Impl> void hash_combine(size_t& seed,const T& x,Impl impl) { seed^=hash_value(x,impl)+(seed<<6)+(seed>>2); } template<typename A,typename B,typename Impl> std::size_t hash_value(const std::pair<A,B>& x,Impl impl) { std::size_t seed=0; hash_combine(seed,x.first,impl); hash_combine(seed,x.second,impl); return seed; } template<typename It,typename Impl> std::size_t hash_range(It first,It last,Impl impl) { std::size_t=0; for(;first!=last;++first){ hash_combine(seed,*first,impl); } return seed; } template<typename E,typename T,typename A,typename Impl> std::size_t hash_value(const std::basic_string<E,T,A>& x,Impl impl) { return hash_range(x.begin(),x.end(),impl); } // same as previous for the rest of STL containers This framework is transparent to the regular user, who never specifies an alternative implementation and can define hashing for her own types as before: std::size_t hash_value(const my_type& x) { //... } unordered_set<my_type,/* boost::hash<my_type> */> us; But the "advanced" user can tweak one or more parts of the hashing framework ad libitum: struct crypto_impl{}; std::size_t hash_value(int x,crypto_impl) { // smart hash for ints } // we modify also range hashing template<typename It> std::size_t hash_range(It first,It last,crypto_impl) { std::size_t seed=0; std::size_t n=1; for(;first!=last;++first){ hash_combine(seed,*first,crypto_impl); seed*=n; // for instance n*=2; } return seed; } unordered_set<my_type,boost::hash<my_type,crypto_impl> > us; What do you think? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

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

10 Mar '05

In-Reply-To: <d0pe8q$tdi$1(a)sea.gmane.org> daniel(a)calamity.org.uk (Daniel James) wrote (abridged): > But it will be easy to make mistakes for more complicated (possibly > recursive) types. Especially since hash_combine is not associative or > transitive. I could see that leading to mistakes. I can see that it's possible to call the function with the wrong arguments, but that kind of problem can be addressed with documentation and/or by careful naming. I don't think that's worth distorting the interface and introducing side effects and spurious variables and inefficiency to fix it. > And it would be quite easy to forget to call hash_value (because > many types are implicitly convertible to std::size_t) Since that conversion is all hash_value does, why does it matter? That said, I agree the second argument should not be hash value. If we care about the first argument, perhaps the problem could be identified with an overload or specialisation. template < typename T, typename S> size_t hash_combine( S seed, const T &v ) { BOOST_STATIC_ASSERT( false ); } template <typename T, typename S> size_t hash_combine<>( size_t seed, const T &v ) { const size_t c = 0x12345678; // Or some other value. return seed ^ (hash_value(v) + c + (seed<<6) + (seed>>2)); } (I'm not so hot on templates so the above may be wrong, but I hope it conveys the idea.) > size_t my_hash_function(int x[4]) { > using namespace boost; > > return hash_combine( > hash_combine(hash_value(x[0]), hash_value(x[1])), > hash_combine(hash_value(x[2]), hash_value(x[3]))); > } I agree this is wrong. I think: return hash_combine( hash_combine( hash_combine( hash_value( x[0] ), x[1] ), x[2] ), x[3] ); is reasonable and ideally would be supported. > An alternative would be to implement hash_combine as an object. > Something like: > > struct hash_seed { > hash_seed(); > template <class T> void combine(T const&); > std::size_t value() const; > }; > > Then it could initialise itself to whatever it wants. Do you mean the seed should be an object? I can see advantages to that, although it seems like overkill. Adding an optional seed argument to hash_range and/or hash_combine sounds like a good idea, though. -- Dave Harris, Nottingham, UK

3 2