- Boost - lists.boost.org

patches for embedded VC4
by Ulrich Eckhardt 11 Mar '05

11 Mar '05

Hello! I'm currently trying to port Boost to embedded Visual C++ 4. Attached are a patch against this afternoon's CVS and toolset definition for Boost build v1. Some explanations for the patch: --------------------------------- EVC4 comes with several different compilers, all of which are cross compilers for various architectures. Else, those compilers are mostly bug-to-bug compatible to the one that comes with VC6. One problem though is that e.g. the ARM compiler has _MSC_VER=1201 while the MIPS compiler has _MSC_VER=1202 and the one for x86 has _MSC_VER=1200 (like VC6). The C++ standardlibrary is IMHO barely worth talking about, anything but the most primitive types of use require STLport, unfortunately in their yet unreleased version 5 (use 'cvs checkout -r STLPORT_5_0 STLport' in case you want to try). There are a change to boost/config/stdlib/stlport.hpp that is required for STLport 5. If you look at the patch, you will see that most changes are explained by removing '#if _MSC_VER==1200' in favour of '#if _MSC_VER<1300'. At first glance those are not really equivalent, but there are some considerations that will make it sensible: - if (which I doubt will ever happen) there come any updates to those compilers they will still have version numbers < 1300 - if VC6 and similar suffer a defect, chances are good that older compilers also suffer the same problems - there is a line that generates an error anyways should you try to compile boost code with <1200, older compilers are simply not supported. Another set of changes is that sometimes the use of '#pragma once' was made dependant on _MSC_VER>=1200, while other places used _MSC_VER>=1020. MS themselves use _MSC_VER>=1000. I think this pragma was already supported long before VC6, so the second alternative seems to be right. I replaced a few of such cases. I noticed that some places use BOOST_WORKAROUND while others use _MSC_VER directly. For #pragma once that makes still sense, since you don't want to first include the header for the macro, but in other cases I'm not so sure. Is there a tendency to uniformly use BOOST_WORKAROUND? If so, and since I'm touching a lot of those checks already, should I replace those? The change in boost/detail/lwm_win32.hpp is something where I don't claim I really understand what it does. Removing it breaks compilation, I don't know how to test if it really works. The changes in boost/function/function_template.hpp are something that shouldn't break anything, except if the brackets where in fact an undocumented workaround for some other bug.... Working on this, I noticed that some files I checked out of CVS were write protected!? Is that just my setup, intentional or by accident? I didn't investigate further. Some explanations on the toolset file: --------------------------------------- This is far from complete. There are several architectures that aren't yet supported, some aren't even supported by STLport (yet). Lots of debug code are still present. This also requires changes to some other places, in particular the names of libraries need to be changed, for autolinking in the headers, for building in some part (I forgot which) of the build files. Also, I found that MS Windows CE suffers from not being able to load DLLs with names longer than 31 chars, meaning that the normal boost naming conventions can't be used. This is a major bummer, but I don't see a workaround other than that. I'm throwing this work in progress at the list so I can get feedback earlier. So, if there are issues, don't hesitate to bring them forth. cheers Ulrich Eckhardt

4 5

The case for fold_seq
by Larry Evans 11 Mar '05

11 Mar '05

Is there any interest in a proposed mpl sequence, fold_seq, derived from mpl::fold and contained in boost-sandbox.sourceforge.net/vault/ in cppljevans/mpl/fold_seq_test.zip? This zip contains: * a test driver, fold_seq_test.cpp * a header file, fold_seq.hpp * bjam output of driver for intel * bjam output of driver for gcc. A better name for fold_seq might be cummulative_app since each element is a "partial_application" of the ForwardOp "operation" to part of the Seqence, where ForwardOp and Seqence are the arguments to fold, as described here: http://www.boost.org/libs/mpl/doc/refmanual/fold.html The reason for term "partial_application" is that it corresponds to "partial sum" described here: http://mathworld.wolfram.com/PartialSum.html Alternative names include "prefix reduction" or "scan": http://nf.apac.edu.au/training/MPIRefs/MPI_1.1/node84.html#Node84 Anyway, it seems that it's a useful extension to fold, since, as seen by the above references, the corresponding math concept occurs often. In addition, the test driver in the vault contains test_partial_product, where the value's at each element of the fold_seq correspond to elements in a cummulative product: http://mathworld.wolfram.com/CumulativeProduct.html Such a cummulative product could be used to calculate, at compile time, the strides for an instance of mult_array. Also, fold_seq could be used as a replacement for the get_side_type template class mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/118867 and used to access the elements in a tuple, as demonstrated by the test_tuple_access function in the test driver. I'd be glad to discuss improvements or reasons why it's unneeded. TIA.

1 1

Need help: for N-arity operators in C++.
by Pavel Chikulaev 11 Mar '05

11 Mar '05

Hi all! Can anyone help me? I've got a problem with my library "Lazy". Here's the code: template<typename T, int N> class B {}; template<typename T> class C : B<T, max_possible_N_of_all_specializations_B<T> > {}; //The question is - How To write //max_possible_N_of_all_specializations_B? So, if I have these template specializations of B: template<> class B<int, 4> { enum { value = 4}; }; template<> class B<int, 920234> { enum { value = 920234 }; }; C<int>::value should be 920234. Does anyone knows how to do it? Thanks in advance. P.S. It's critical for my library to have max_possible_N_of_all_specializations_B. -- Pavel Chikulaev

5 15

Log utility
by Suman Cherukuri 11 Mar '05

11 Mar '05

I wrote a logging library using boost libraries and other standard C++ functions. I'm fairly satisfied with it and using in my own product. I think it'd be a good addition to Boost. What do you all think? --Suman

3 2

Update of the (not yet officially proposed) Function Types library
by Tobias Schwinger 11 Mar '05

11 Mar '05

Dear Boost community, after three complete rewrites and numerous steps of incremental refinement (some of it based on feedback from you) I am proud to hereby present my attempt to provide a "truely boostish" metaprogramming facility to work with function-, function reference - and (member) function pointer types. The functional range includes: - type classification ("is T a * function ?") - type decomposition (e.g. "what is the result of the function T describes ?") - type synthesis ("create a * function with these subtypes !") All of the above work with variadic functions and (configuration dependent) with arbitrary calling conventions. Common applications are: - generating callbacks (the most prominent special case of this is argument binding) - extracting meta infromation from function prototypes - concept checking (e.g. "let's see if this is a setter/getter pair...") - systematic overload selection See the Documentation for further information. [ -> http://tinyurl.com/4fw9n ] A downloadable archive has been put into the vault. [ -> http://tinyurl.com/4oe7q ] Its quality has improved by an order of magnitude since my first naive attempts, last year - and not at least because of those of you who helped. Thank you ! I decided to use the next couple of days for finalizing refinement and to wait for some more feedback to confirm or disprove my suspicion that the submission is "review ready", before sending out a formal request. Regards, Tobias

2 7

[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