- Boost - lists.boost.org

[boost::foreach] and bcc32-5.6.4
by Russell Hind 11 Mar '05

11 Mar '05

Has anyone tried BOOST_FOREACH with bcc32-5.6.4? I've just tried the example BOOST_FOREACH(char ch, "Hello") { std::cout << ch; } And get a string of errors of the following: (line 11 of main.cpp is the BOOST_FOREACH line). I'd really like to be able to use this library so if anyone can give any help in getting it to work, it would be really useful. Thanks Russell [C++] main.cpp(1): [C++ Error] main.cpp(11): E2354 Two operands must evaluate to the same type [C++ Warning] main.cpp(11): W8032 Temporary used for parameter 1 in call to 'boost::for_each::boost::for_each::container<char *,boost::mpl::false_> wrap<char *>(char * &)' [C++ Error] main.cpp(11): E2354 Two operands must evaluate to the same type [C++ Error] main.cpp(11): E2285 Could not find a match for 'boost::for_each::contain<T>(undefined,bool,undefined)' [C++ Warning] main.cpp(11): W8032 Temporary used for parameter 1 in call to 'boost::for_each::boost::for_each::container<char *,boost::mpl::false_> wrap<char *>(char * &)'

10 28

[date_time] test failures
by Caleb Epstein 11 Mar '05

11 Mar '05

http://tinyurl.com/5hnvv The date_time regression tests in the gregorian subdir called "testgenerators" and "testgenerators_dll" fail to compile on Solaris due to the use of a variable called "sun". Unfortunately, there is a preprocessor macro sun == 1 which gets defined on this platform that ends up turning the declaration: greg_weekday sat(Saturday), tue(Tuesday), fri(Friday), sun(Sunday); into greg_weekday sat(Saturday), tue(Tuesday), fri(Friday), 1(Sunday); I'd suggest either #undef sun at the top of the file or changing the name of this variable. Also, there are few other failures (testclocks, testlocal_time, testlocal_time_facet) due to a missing declaration of time_ in local_date_time_base. Example: http://tinyurl.com/5xd8h testtz_database is failing because it can't find its input file (probably because of the working directory the tests are run from). Perhaps this file should be found starting from $BOOST_ROOT? -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

[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