February 2007 - Boost - lists.preview.boost.org

Is the Md5 license compatible with Boost?
by Henrik Sundberg 15 Mar '07

15 Mar '07

Found this Boost::Md5: http://www.garret.ru/~baranov/boost_md5/lib/md5/md5.html Is this going to be a part of Boost? Is the Md5 license ok for Boost at all? /$

4 5

Posting signatures, again.
by Rene Rivera 15 Mar '07

15 Mar '07

Not dredge up the subject of signature content up. But I do have a request, for comments and a suggestion. Even though I do have feelings about the content of signatures, I understand that most don't, so I don't care if people put whatever content they want in them. But I do care about *formatting* of the signatures. There's been a recent rash of signatures that are not clearly marked as such. Hence to me it makes for harder reading of postings as I end up confusing the body text with the sig text. May I suggest that people follow accepted netiquette rules in this regard. Signature block <http://en.wikipedia.org/wiki/Signature_block> Netiquette <http://en.wikipedia.org/wiki/Netiquette> -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

[Boost][Python] Fails for gcc-cygwin-3.4.4
by Darren Garvey 15 Mar '07

15 Mar '07

Hello, (Please ignore this if these fails have been sorted out already.) All the fails for gcc 3.4.4 on cygwin seem to be down to __int64 not being defined properly. According to google, cygwin on Windows doesn't define __int64 (at least for gcc). Adding "-D__int64=long long" to the command line sounds (<cxxflags>?) like it should fix it, although I've no idea if making users do that themselves is frowned upon? Some links: http://tinyurl.com/2k5922 http://tinyurl.com/2txysc Regards, Darren

5 8

[defer] - comments?
by simon meiklejohn 14 Mar '07

14 Mar '07

Anyone had a play with the defer library in the vault and want to comment on its usefulness? It clearly shares much in common with the asio Dispatcher concept but with the freedom to define more general Dispatchers. (e.g. 'Create thread per callback' and 'Dispatch Callback via Message Pump', both of which violate the specific guarantees of the asio Dispatcher concept, that the callback occur in a thread that has called asio::demuxer::run().) One potential application for defer would be in conjunction with asio, creating the thread(s) which call demuxer::run() in a succinct form. Cheers Simon

3 2

[1.34.0] msvc 7.1 & stlport
by Vladimir Prus 10 Mar '07

10 Mar '07

The link errors we get with msvc 7.1 and stlport are caused by wchar_t mismatch. 7.1 defaults to non-native wchar_t and default stlport build uses that default. Boost.Build explicitly enables wchar_t as native type, so when using non-native-wchar_t-build stlport, we get linker errors. Solutions are: 1. Disable native wchar_t in Boost.Build for STLPort configurations. 2. Build STLPort with native wchar_t Do folks with practical experience with msvc 7.1 and stlport have an opinion which one is better? If (2) is better, is the procedure for buildind stlport with native wchar_t documented anywhere? - Volodya

5 5

[1.34.0] Regressions state
by Vladimir Prus 06 Mar '07

06 Mar '07

This is the summary of regression results as I see it: 0. The regression framework seems OK. It's also more reliable now -- thanks to Aleksey, who made XSLT processing more strict, and fixed process_jam_log not to loose some output. 1. We have a number of regressions with intel-linux-9.0. They come from two runners -- Martin and Sandia. In Martin's result most failures are due to an command line option that intel-9.0 does not understand, and Martin's results were not updated since I've checked in the fix. Sandia's results are post fix, and I see no linker errors. There are some failures that look genuine. 2. We have a large number of regression with msvc-stlport configurations. Most are linker errors, which suggests misconfiguration or Boost.Build bug, or both. I'll work with Roland on a solution. 3. There are some fails that look genuine. I think the right way to get 1.34 released now, as far as regression tests are concerned is this: 1. Completely freeze the list of tested compilers. This means that anything not tested now is not tested. Notably, we'll have no coverage for mingw or cygwin versions of gcc. 2. Have me and Roland fix stlport issues. 3. Start pinging developers about remaining failures. I think we should adopt a policy that will guarantee that all failures be resolved in a reasonable time -- namely, if a failure is not fixed by a certain date, it's marked expected and we move on. That cut-off date might be two weeks from the next Monday -- Feb 26. Both (1) and (3) will certainly have an effect on release quality -- we'll mark some failures as expected instead of fixing them, and we won't see failures on some configuration. However, I believe having a release sooner is more important at this point. Thomas, I would like you to express your opinion on this plan. Opinions from other Boosters are also appreciated! - Volodya

10 23

generating unique ordinal value at compile time
by Matthias Schabel 05 Mar '07

05 Mar '07

For various reasons, it would be really nice to be able to generate a series of unique ordinal values (say integers, but really anything that is easily less_than_comparable) at compile time. A concrete example : struct system1 : ordinal<0> { }; struct system2 : ordinal<1> { }; etc... Now, if these tags can be defined in user code in various places, it can be difficult to ensure that there is no duplication of the ordinal values. What I want is something like this: struct system1 : ordinal<get_next_system_ordinal()> { }; struct system2 : ordinal<get_next_system_ordinal()> { }; where I don't really care what the specific order is, just that the ordinal values are unique... Anyone have a bright idea on how to accomplish this? Preprocessor? Matthias

8 14

Boost.Bimap - new name for the container?
by Matias Capeletto 05 Mar '07

05 Mar '07

Hi all, Thanks to John Maddok test of Boost.Bimap we discovered that some compilers (VS7.1 for example) may have a hard time recognizing between the "bimap" namespace and the "bimap" class if you try to compile the following code: using namespace boost::bimap; using namespace boost; typedef bimap<int, double> bm_type; If you switch the using statements this problem is gone in VS7.1 but persist in VS8 The following code compiles in VS7.1 using namespace boost; using namespace boost::bimap; typedef bimap<int, double> bm_type; You can use the container with the full namespace path in order to solve this problem: using namespace boost; using namespace boost::bimap; typedef ::boost::bimap::bimap<int, double> bm_type; Is this a problem that can be solved with a warning in the docs? Do you think it may be better to rename the "bimap" class to something else like "bidirectional_map"? Ideas are welcome Regards Matias

5 7

Boost.Bimap - first/second and left/right
by Matias Capeletto 05 Mar '07

05 Mar '07

Hi all, I think we must discuss this issue together so we can settled it down. Lets analyze the rationale step by step. (1) Interface for the bidirectional mapping. That interface have to be compatible with existing code that work with standard maps. The best way IMHO to achieve this is that you can view the container from the two sides and see something compatible with std::map<X,Y> for the left one and with std::map<Y,X> for the right one. (2) This force us to use first/second notation for the left view (first is the left element and second the right one) and for the right view (where the names are inverted, first is the right element and second is the left one) If you have code like: template< class Pair > class PrintPair { void operator()( const Pair& p ) { std::cout << p.first << "-->" << p.second << std::endl; } } template< class Map > void print( const Map & m ) { std::for_each( m.begin(), m.end(), PrintPair< Map::value_type >() ); } typedef bimap<int,std::string> bm_type; bm_type bm; bm.insert( bm_type::value_type(1,"one") ); bm.insert( bm_type::value_type(2,"two") ); It will work with both sides views print( bm.left ); // 1 --> one // 2 --> two print( bm.right ); // one --> 1 // two --> 2 (3) (from other thread) For bm (the above view) we have some options: a) bm can be left without any special function and so force the user to write .left or .right to refer to it. b) bm can be the same as bm.left. This IMHO introduce an asymmetry to the interface. The left view became the more important than the right view. c) bm can be used for something new. Give the user a new view of the mapping: a set of relations. This design is symmetric. It forces the user to write .left to refer to the std::map<X,Y> view but this is a good thing, because is documented in the code what view is being used. This option is more elegant and powerful that the other ones. Because it is a new view we can use the symmetric left/right notation for it members so the design is complete. If we use first and second, the above view could be confused with the left view. Jeff has proposed to go with (a) In the current framework this is achieve using: typedef bimap<A,B,unconstrained_set_of_relation> bm_type; The library use (c) because it is very useful to be able to insert the elements or ask for the size, etc directly. And because it allows us to extend the framework by selecting different set of relations. So first/second are used in the side views and left/right in the above view. What do you think about this? Regards Matias

4 6

[Bimap] Review
by Fernando Cacciola 05 Mar '07

05 Mar '07

Hello Matias, Here's a partial review, focused on the first things I observed so far. 1. The very first thing I see is a nice bold question: "What is a bimap?" However, everything that follows doesn't feel like a good answer. Is more like the explanation of the missing answer. For such a concrete question I would expect a concrete answer like: "A Bimap is a data structure that represents bidirectional relations between elements of two collections", or something like that. Furthermore, at this introductory point in the tutorial, the very first mention of "bm.left" should IMHO be closely followed by its definition, yet the statement "is signature compatible with std::map<A,B>" is a bit simplistic at that. The same goes for bm.right and 'bm' itself. 2. The next thing one sees is the nice diagram. It's so nice that it sticks and weights in the understanding of the nature of a bimap. Even if one reads through the text, the picture drives the understanding. At least that's how it works in my head. However, it's a bit misleading, and I finally figured what, IMHO, is wrong with this picture :) Bare with me... On the one hand I see two sets, X and Y (drawn as Venn diagrams), and a biyective relation (the arrows). Pretty straightforward. On the other hand I see class bimap<X,Y>, followed by set< relation<X,Y> >, which one interprets as it's true nature given the way it is presented. Now, on yet another hand, or a left foot maybe, I also see bimap<X,Y>::left, which is really a map<X,Y>, and then a bimap<X,Y>::right, which is really a map<Y,X>. Eventually, I realized one of the most important aspects of a bimap: its triality (yes, this is a word). It is at the same time a set of elements (which happen to be relations), a map from left to right, and a map from right to left. Thus, set< relation<X,Y> > is not the only true nature of a bimap even though it stands up-front in the picture. In fact, it could be argued that the reverse view is the whole point of bimap<>. It's the reason of its existence. That is, the set< relation<X,Y> > nature of it, even if useful and novel, is secondary. One could have the same for an ordinary map for that matter. So, on the one hand, I would focus the presentation on the symmetric views first, then extend it to incorporate the (secondary) set-of-relations interface. So, let's see the pictorialization of the two symmetric maps. In the current picture, you see the left map sightly on top of the set X, and the right map slightly on top of the set Y. Bur this draws the subconscious association between the left map and X and the right map and Y. However, a map is a relation, so *both* elements are part of a map. Therefore, the picture should better relate both X and Y to each of the maps. Furthermore, these maps overlay each other over the same data structure, they are not just two disjoint maps. I noticed that part of the confusion comes from the fact that each map is enclosed in disjoint ballons, and, actually, those ballons have no real iconic value (they don't represent anything useful by themselves). The maps could be drawn at both sides of the sets and the ballons could be drawn to enclose both sets, such that at the intersection of both ballons, you see "the bimap" (the two sets and the relations between them). Also, to further guide the role of each map as a directed view of the relation, I would use two colors and two single-headed arrows, one of each color, instead of one double-headed arrow as it is now. Finally, I would put the set< relation<X,Y> > role at the bottom, to move the focus away from it, and its ballon would also enclose the two sets. In the end, there are three ballons all intersecting at the region containing the Veen diagrams, expressing the fact that a bimap<> offers three views over the same thing. 4.The following is from the second tutorial page (headed "The Tutorial") 4.a.It says: "New concepts are however presented to extend the mapping framework to bidirectional maps" That is confusing because at that point of the reading, there is no such thing as "a mapping framework". I would say "the std map class" instead. 4.b. The expression "new framework" is also confusing. A "new" something must relate to an "old" soemthing, and boost::bimap, IMO, should NOT be seen as something "new" while std::map as something old. I would say "the Bimap framework" instead (this applies to many other pages in the docs) 4.d. Here's the first time the expression "set type" is used. This expression is used all over the documentation but there is problem: the term "set" is not defined so one is forced to imagine its definition. Is it an STL set? Is it a mathematical set? Does it have special requirements? Granted, one eventually realizes you meant a mathematical set instead of an STL set, but even then, Bimap is purposedly designed to relax all such requirements, even uniqueness, so I think a better word for this concept is "collection". The reason is that you can actually use a vector for this type, which can hardly be considered as representing a mathematical set (because it doesn't guarantee uniqueness). 5. Here's an analysis of the "standard mapping framework" picture (following the same ideas as before); 5.a.The ballow should enclose both Venn diagrams since a map contains both elements. 5.b.The words "first/second" on top of std::map are confusing IMO. I would remove them. 5.c.In a std::map there is no explicit "set type" for the collection of keys, so at this point the label to it is confusing. I would removed it. 6. After the picture you read "this is not wrong.". What isn't? 7. In the introduction of the standard mapping framework, the idea of a map seen as an overlay of two "set types" is presented, but unfortunately quite superficially. This way of looking at it great, but is also a bit novel since the "standard framework" doesn't speak of left and right sets at all. Thus, besides what I mentioned before about replacing "set" by "collection", I think you should add an entire page explicitely presenting the idea, at a conceptual level, that a map is the overlay of two collections. Much before the standard mapping framework is introduced. That's all for now.. but there's more. Best regards And as promised: !!! vamos vamos, Argentina !! ------ Fernando Cacciola SciSoft http://certuscode.wordpress.com http://fcacciola.50webs.com http://fcacciola.wordpress.com

4 5