June 2004 - Boost - lists.preview.boost.org

Re: Some remarks on PP docs
by Vesa Karvonen 11 Jun '04

11 Jun '04

Dave Abrahams: >I am not even trying to cover the whole PP library in this appendix, >much less the topic of PP metaprogramming in general. [...] [...] >... but, thanks for the suggestions. I don't mean to sound >ungrateful, but I'm really trying to limit this to a small-scale >practical overview of the things you need to know in order to get >started with the PP library. I see your point, but... >"Understanding the preprocessor and PP metaprogramming" is beyond the >scope of the book. ...while understanding all the consequences of the PP design is obviously not necessary for basic PP metaprogramming, I think that it is almost impossible to be able to use the PP (and the Boost.PP library) profitably (beoyond trivial use of macros like ENUM_PARAMS and REPEAT) without having a fairly good understanding of the capabilities and limitations of the PP. -Vesa Karvonen _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

RE: [boost] Geometric Algebra Library
by Johannes Brunen 11 Jun '04

11 Jun '04

Hi Jaap, fine to hear that you are still working on your GA library. I'm eager to see such a library in the boost pool. So I'm very interested in the library. One point however, Paul Leopardi is still working on GluCat and I have the impression that he is also targeting boost. It would be fine if you could bundle together your efforts in oder to get the best of each GA libraries. With best regards, Johannes

1 0

[serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Allen Yao 11 Jun '04

11 Jun '04

The file is_abstract.hpp in serialization18 and is_abstract.hpp in type traits library (in cvs) have conflict definitions of "boost::is_abstract". May Ramey fix this. For now, I just comment out the latter in order to use serialization18. In addition, I am confused with the ".ipp" files in libs/serialization/src/ in serialization18. It is strange to write #include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 in user code instead of #include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 I wonder why these files can not be just named ".hpp" Ramey, when will we see the serialization library in boost cvs, please? Thank you:)

1 0

[thread] Thread specific pointer cleanup handlers
by Malcolm Noyes 11 Jun '04

11 Jun '04

During my 'research' into different ways to implement thread specfic storage (tss) on Win32, I needed to implement custom cleanup handlers. The thread_dev branch allows for a custom cleanup handler on the basis of 'one cleanup handler per global object instance'. This is *not* the same as 'one cleanup handler per tss object instance' since with tss there is of course one object instance per thread. Consider: void no_cleanup(int*) { // do nothing } thread_specific_ptr p(no_cleanup); int main(int, char*[]) { int some_number = 42; // leaving aside why someone might want to do this, it's // the mechanincs that we're interested in! p.reset(&some_number); // fine p.reset(new int(0)); // leak - 'p' has no cleanup! return 0; } The theoretical alternative would be to allow (enforce?) a different cleanup handler per thread object, e.g.: void no_cleanup(int*) { // do nothing } void delete_cleanup(int* pd) { delete pd; } thread_specific_ptr p; int main(int, char*[]) { int some_number = 42; // this time call reset with a specfic handler for this thread //object instance p.reset(&some_number, no_cleanup); // fine p.reset(new int(0), delete_cleanup); // ok now, will call delete return 0; } My feeling is that boost::thread should only allow the first form and document that the use above leads to unspecified behaviour (it may not be a memory leak, we don't know what the cleanup handler may do). My only reason for this however is that allowing the latter case is probably not a frequent use and makes the implementation much complicated. Does anyone think the latter is required ? Malcolm Malcolm Noyes

1 0

[Test] Linking
by David B. Held 11 Jun '04

11 Jun '04

What is the canonical way to link the Boost.Test library? Is it better to just include the sources in the project, or to try to link to a built library? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 1

boost::transform_iterator and boost::lambda functors
by Maxim Yegorushkin 10 Jun '04

10 Jun '04

Is there a way to make a boost::lambda functor adaptable, that is to make it define result_type? There is a ret<> function template that lets one specify the result type, but the returned functor still does not have result_type typedef. I've encountered the problem trying to use boost::transform_iterator with a boost::lambda functor: std::vector<int> intVect; boost::make_transform_iterator(intVect.begin(), boost::lambda::_1 / 2); transform_iterator<> does not compile comlaining the functor does not have result_type. As a workaround I had to write something like: template<class R, class T> struct result_type_wrapper : T { typedef R result_type; result_type_wrapper(T const& t) : T(t) {} }; template<class R, class T> inline result_type_wrapper<R, T> result_type(T const& t) { return t; } boost::make_transform_iterator(intVect.begin(), result_type<int>(boost::lambda::_1 / 2)); Am I missing something? Is there a way to avoid using result_type_wrapper<>? -- Maxim Yegorushkin

4 6

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

David B. Held: >It's hard enough getting one's head around the PP lib without having to >be an expert in it already. [...] >It's a shame, because there's a lot of code that would benefit from the >PP lib that almost certainly isn't because of the difficult learning >curve. Learning Boost.Preprocessor is like learning a rather verbose and intricate programming language. It is not really surprising that it can be difficult to learn, although the documentation, at least the parts that I wrote, could certainly be improved. It is possible to implement a language using the C99 (or even the less capable C++97) preprocessor that would be much less verbose and intricate and would be significantly easier to use (see http://groups.yahoo.com/group/boost/files/Order/ for details), but it would come at some cost in efficiency (on some compilers the cost would probably be prohibitive and on some compilers the cost is insignificant). -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 2

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

>techniques.html: Since I initially wrote the document, I might as well comment. >I was really confused by the use of the word "standard". This would >be clearer: > > It is usually okay to reuse a single generic macro name like > BOOST_PP_DEF throughout your code because the macro is both defined > and undefined very close to its point of use. Yeah, there is probably a better way to convey the idea. >Although I don't know why you'd want to advocate that over using a >descriptive name. Because those macros are essentially [used like] lambda expressions: ad hoc, short, local functions that you usually do not even want to name. There is also an additional benefit of using a single generic name. If you forget to write the #undef, you will more likely get a warning (or an error) from the preprocessor. #undefining local macros helps to avoid macro replacement related problems. >A clearer divider between examples would be a *huge* help visually. >An <hr> would be enough, for example. Looking at an old revision in CVS, this used to be the case. >?? Where is BOOST_PP_EMPTY used in this example? I think I know what >you mean, but really, you need to show it! Looking at old revisions in CVS, it used to be there (use of BOOST_PP_EMPTY). > Note: BOOST_PP_EMPTY with the () never gets expanded. > >This sounds self-contradictory. Just above you said it expands (to >nothing)! Again, looking old revisions in CVS, it used to read "without". > The () is necessary to invoke a function-like macro. > >No duh; I think stating the obvious that way only adds confusion. Perhaps. The point is to point out the reason why the macro does not get expanded. The idea of passing the "name" of a function like macro as a parameter may not be obvious to all. > Caveat: You cannot safely use concatenation while using >BOOST_PP_EMPTY(). > >That's way too vague and general. I certainly can use concatenation >and BOOST_PP_EMPTY "together", for many reasonable definitions of that >word! I think you need to be more specific, or strike it. Agreed. >The BOOST_PP_ENUM_PARAMS example could benefit greatly from a >side-by-side format in a table showing the expansion on the right. There used to be a page that contained all the examples of the tutorial after preprocessing (and formatting). You could then simply click the title of the example to see the preprocessed code. >Showing not-even-correct details of BOOST_PP_REPEAT's implementation >doesn't help here. I'd strike it. You are probably right. I suppose when I wrote that, I wanted to give an idea to the reader how such macros might be actually be implementable (so that it doesn't seem as magical as it otherwise might). Looking back, I think that it was a mistake, because I have seen several people inventing their own REPEAT-style macros rather than using the generic macros in the library. Although, it might be the case even if the tutorial were different (nothing would have prevented those same people from looking at the actual implementation and learning the same information). >Furthermore, > > BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. > BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) > essentially expands to "I+1," and BOOST_PP_DEC(I) essentially > expands to "I-1.". > >I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC >yet, so the reader is left wondering why you're giving their >implementation details. I agree that the comment should be removed. I think that the comment has probably been more relevant at some stage (CVS would probably reveal it if this was the case), but the context was lost during editing. That ''BOOST_PP_DEC(I) essentially expands to "I-1"'' is hardly an implementation detail. >Is this really better than iterating over a SEQ of categories in any >way other than efficiency? At the time when the example was written, SEQ had not yet been invented and even lists were not as efficient and convenient as they are today. Unfortunately, the example was never updated. Today, I would generally advocate using a sequence (or some other data structure). > Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. > >It's unclear to me how that example avoids O(n*n) repetition. The point is to avoid manual, source code time, repetition and replace it with automated, preprocessing time, repetition. The code that you will edit after using REPEAT will be only O(1) (and not O(n*n)). It is the same as using a high level language to avoid programming in machine language. Sure, the compiler translates the high level code to machine language (well, not exactly, but close enough), but this doesn't mean that (because of the translation) you would not be avoiding programming in machine language as you seem to suggest. > Example - Use BOOST_PP_REPEAT for O(n*n) repetition. > >Or something? That might be a better way to convey the idea. > BOOST_PP_IF enables convenient generation of lists using > BOOST_PP_REPEAT. > >This statement, without an example, is too vague to be helpful. I agree. >Implementation details of BOOST_PP_IF don't help: > > How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): > #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) > > #define BOOST_PP_IF0(THEN, ELSE) ELSE > #define BOOST_PP_IF1(THEN, ELSE) THEN > #define BOOST_PP_IF1(THEN, ELSE) THEN > ^ >especially since they appear to be wrong. Again, looking at an old version in CVS, this used to be correct. >I think the point is that BOOST_PP_IF works on first arguments other >than 0 or 1. If so, you should just say that it works on numeric >arguments up to N (whatever N is). That is probably a better way to put it. Again, the idea was to show how IF might actually be implemented (to dispell the magic), but it was probably a mistake. > Example: Use arithmetic, logical, and comparison operations when > necessary. > >With no commentary, and no generated code, this example is really >useless. I mean, of course you'd use arithmetic, logical, and >comparison operations "when neccessary". Looking at an old [...], there used to be a comment: "<P>The PREPROCESSOR library supports saturated arithmetic, logical and comparison operations on decimal integer literals in the range [0,BOOST_PP_LIMIT_MAG].</p> <p>Suppose that you want to generate a numbered lists with a special element inserted at a desired position. For example: E0, E1, S, E2. Consider the following example:</p>" The point of the example was really just to let the reader know that the library does contain macros for arithmetic, logic, etc... The example is admittedly weak and only designed to use some of the mentioned classes of macros. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re:[boost] Some remarks on PP docs
by Robert Ramey 10 Jun '04

10 Jun '04

David Abrahams wrote ..... While your at it, it would be really helpful to have a section for each compiler indicating which BOOST_PP... macros they don't support. I would hope this just be started and as users (like me) could just send in notes according to their experience. Here's the first line: BOOST_PP_CAT doesn't work with VC 6. Robert Ramey

1 0

Re: [boost] Geometric Algebra Library
by Tim Stevenson 10 Jun '04

10 Jun '04

Hi Jaap, I'm very interested in something like your library. I've only just started to wrap my head around geometric algebra and I've been confining myself so far to just playing with simple problems on paper to see how it removes special boundary case handling for some simple algorithms. The computational complexity of the higher dimensions has always concerned me but it sounds like you are doing a lot of compile-time optimisation to save wasted calculations at run-time. In a few months I'm planning to devote a considerable amount of time to investigating Geometric Algebra in a lot more detail and your library sounds like a good tool to "play" with. I use both VC++ and GCC and I would be willing to devote some time to investigate porting your library to the latest version of GCC. Tim.

1 0

Re: [boost] Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Toon Knapen 10 Jun '04

10 Jun '04

Joaquín Mª López Muñoz wrote: > Hi Toon, maybe we have advanced a little, since, if I'm ont wrong, the > error triggers at the second argument of the ctor. I've applied a > similar patch to this as well. Could you please try the attached file? This seems to solve the problem in the multi_index library ;-) but now compilation is aborted due to errors encountered while including the tuple library in the multi_index library ;-( See the compiler-messages in attachment: ...found 1065 targets... ...updating 72 targets... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o" "../../../libs/multi_index/test/test_basic.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o... ...skipped <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic for lack of <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o" "../../../libs/multi_index/test/test_capacity.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o... ...skipped <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity for lack of <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_comparison.test/vacpp/debug/test_comparison.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters.

3 2

uBLAS regression tests
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, currently uBLAS regression tests are defined in status/Jamfile directly. Will it be OK if I move them to libs/numeric/ublas? The reason I'd need that is that Boost.Build V2 version of uBLAS tests that was contributed by Michael Stevens lives in libs/numeric/ublas, and with the current setup its hard for me to automatically verify that V1 and V2 test results are the same. - Volodya

2 1

[bind] vc6 problem
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, when I try to compiler the following code snippet on vc6 I get a lot of errors: #include <locale> #include <boost/bind.hpp> void aux(const std::codecvt<wchar_t, char, mbstate_t>& cvt) { boost::bind(boost::mem_fn(&std::codecvt<wchar_t, char, mbstate_t>::in), &cvt, _1, _2, _3, _4, _5, _6, _7); } The errors are: vc-C++ ..\..\..\bin\boost\libs\program_options\build\libboost_program_options.lib\msvc\debug\convert.obj convert.cpp H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::?$bind_t@ABVtemplate-parameter-BAB@V?$dm@$DBAB@$DBAC@@_mfi@boost@@V?$list1@V?$value@$DBAB@@_bi@boost@@@_bi@3@ __cdecl boost::bind(R T::*,A1)' : expects 2 arguments - 9 provided H:\Work\boost-rc\boost/bind.hpp(1487) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8) const,A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(223) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8),A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(212) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7) const,A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7),A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6) const,A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(175) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6),A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(164) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf5<R,T,B1,B2,B3,B4,B5>,class boost::_bi::list6<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5) const,A1,A2,A3,A4,A5,A6)' : expects 7 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(151) : see declaration of 'bind' And so on. Any ideas what I can do to workaround this? The code itself works fine on every other compiler. - Volodya

2 2

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of scott > Assume use of a technique like the following (think this has been > presented as "object shim"?); > > T & > anastasia() > { > static T *p = new T; > return *p; > } > > as a means of dealing with global construction issue, i.e. instead > of expressions like "anastasia.data_member" the usage is > "anastasia().data_member". Also assume that some of these global > objects (i.e. shims) deploy mutexes for MT reasons. What happens > when there is more that one thread running around making calls > to shims? Instantiation of the global itself becomes an MT issue. That's what the double-checked locking pattern for singletons is for. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 3

regression test tools ported to vacpp
by Toon Knapen 09 Jun '04

09 Jun '04

The regression test tools are finally ported to vacpp version 6 and the regression test status will again be updated every day at 6am CET (unless new changes break the compilation again). Please don't hesitate to contact me when you want some help porting your boost library to the IBM/VisualAge platform. toon

3 5

CVS temporarily disabled
by David Abrahams 09 Jun '04

09 Jun '04

http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#1086711… ( 2004-06-08 09:17:17 - Project CVS Service ) As of 2004-06-08 at 09:16 Pacific, developer CVS services have been disabled for some unplanned maintenance. We do not currently have an ETA for the duration of this outage but we do hope to minimize it as much as possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of Eric Niebler > Sent: Wednesday, 9 June 2004 9:15 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Thread lib (good reason for static) > > Hurd, Matthew wrote: > >>Behalf Of scott > >>Assume use of a technique like the following (think this has been > >>presented as "object shim"?); > >> > >>T & > >>anastasia() > >>{ > >> static T *p = new T; > >> return *p; > >>} > >> > >>as a means of dealing with global construction issue, i.e. instead > >>of expressions like "anastasia.data_member" the usage is > >>"anastasia().data_member". Also assume that some of these global > >>objects (i.e. shims) deploy mutexes for MT reasons. What happens > >>when there is more that one thread running around making calls > >>to shims? Instantiation of the global itself becomes an MT issue. > > > > > > That's what the double-checked locking pattern for singletons is for. > > > > Regards, > > > > Matt Hurd. > > > No, the double-checked locking pattern is only good as the subject of > talks describing why it's not good for anything. > > http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf Thanks. They are good notes. I'm aware of the portability issues. Doesn't mean you can't have valid platform specific singleton implementations that use the double checked locking pattern. The performance of the approach is too important to give up. Locking is slow. There are a lot of things you can't do portability in C++ which is one rationale for having libraries :-) Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

boost::any question
by Trey Jackson 08 Jun '04

08 Jun '04

All, I just started looking at boost::any, pretty nice. I looked at the implementation, and it uses (as you know) a pointer to an object (w/virtual methods) on the heap, and typeid to determine if conversion is possible. I understand the memory implications (a new object copied on heap). But I'd like to get a better handle on performance, namely: I'm unfamiliar with typeid - and how it's implemented. Does anyone have good pointers to how typeid is generally implemented? Or even specifically: I'm using gcc3.x on RH Linux. I'd just like to avoid/guarantee I'm not going to be hit by some O(N) look-up for using typeid a lot. thanks, TJ -- Trey Jackson tjackson(a)ichips.intel.com "Her hair glistened in the rain like nose hair after a sneeze." -- Chuck Smith, Woodbridge

3 3

Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Joaquín Mª López Muñoz 08 Jun '04

08 Jun '04

Regression tests show the following at different locations: "/home/tk/boost_regression/boost/boost/mpl/iter_fold_if.hpp", line 104.11: 1540-0038 (S) The name "typename result_::state" is not a type. I don't know how easy to fix this can be (for those who know the internals of MPL). Currently, the problem breaks uBLAS and multi_index. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

Problem building bjam executable
by Bart Garst 08 Jun '04

08 Jun '04

I'm trying to build the bjam executable by running build.bat from the boost/tools/build/jam_src directory. Here's what I get: C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 ### ### "Unknown toolset: vc7" ### ### You can specify the toolset as the argument, i.e.: ### .\build.bat msvc ### ### Toolsets supported by this script are: borland, como, gcc, gcc-nocygwin, intel-win32, metrowerks, mingw, msvc, vc7 ### I also tried running vcvars32 prior to build.bat and got this: C:\BOOST\TOOLS\BUILD\JAM_SRC>"e:\program files\microsoft visual studio .net\vc7\bin\vcvars32" C:\BOOST\TOOLS\BUILD\JAM_SRC>"E:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\"vsvars32.bat Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) The system is Windows NT 4.0 SP6. I'm using a fresh cvs checkout of the entire boost source tree. I'd appreciate any help I can get with this. Thx, Bart

3 4

[assignment library post review]
by Thorsten Ottosen 08 Jun '04

08 Jun '04

Dear All, The post review version can be downloaded from http://tinyurl.com/38c7d Since the review this has changed: 1. insert()/assign() functions has been renamed to reflect which function that is called. So now push_back() is used for vector etc. 2. One header for each standard container. 3. New functions to allow for direct initialization: vector<int> v = list_of(1)(2)(3)(4)(5); map<string,int> m = map_list_of( "Foo", 1 )( "Bar", 2 ); 4. New heavily improved documentation 5. Support for arbitrary functions s.t. new types can benefit from the syntax easily. 6. removal of all half-backed stuff that nobody wanted 7. arguments are forwarded by value instead of const-reference. Reference is a pain to deal with when it comes to string literals. 8. A real test-suite has been added 9. portability has suffered a bit, but that can be solved later. Any comments about docs/implementation are welcome. There is one major isssue we must resolve: What should we call this library. Here are some choices: 1. Initialization library 2. Assignment library 3. Populate library 4. List library I personally would like Boost.List because the library is all about making list for use in various context. best regards Thorsten

3 3

[prereview request][fsm]
by Andreas Huber 07 Jun '04

07 Jun '04

Dear Boosters I think boost::fsm has finally reached a state that is worthy of a formal review. The .zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm As always: Feedback is highly welcome. Regards, Andreas

20 187

[spirit] rule<> and copying
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Hi, I've been using spirit for some config-file parsing. I have some questions: 1. why can we not copy a rule<> ? 2. if we shouldn't copy a rule, why is copying not disabled? It has been a source of errors in my code that I forgot & on my return value. br Thorsten

8 23

token_iterator comments, suggestions
by Gennadiy Rozental 07 Jun '04

07 Jun '04

Hi, For long time in my daytime projects I was using my class token_iterator designed based on old iterator_adaptor design (adopted for old compilers). Now when need arose for such functionality in Boost.Test. I looked in direction of boost::token_iterator. After some struggle I end up adopting my version to new design. Here some of comments and issues that made me opt so. 1. token_iterator follows in a sense a Policy-based design (PBD). Where TokenizerFunc is a Policy that implements most of the functionality. The problem here IMO (unfortunately you see it now quite frequently), that I do not see a reason to use such a design. PBD makes sense it your generic component do a lot of work, provide common interface, combine several independent policies. In this case most what token_iterator does is just a forwarding (it become especially clear if you switch to use input_iterator_adaptor). It wouldn't be that bad, but PBD in this case causes significant usability inconvenience. Instead of plain and simple: token_iterator it( "a:b", ":" ); I have to write something like: token_iterator<char_delimiters_separator<char> > it( char_delimiters_separator<char>( ":" ), "a:b" ). All of that just because we have separate notion of Tokenizer function. IMO it too big price to pay. My suggestion is to get rid of the TokenizerFunction notion. Just implement many different iterators with the same scope of interest: tokenization. We will need to find proper names for iterators and instead of TokenizerFunc model description we may have page explaining how to write custom token iterators (if necessary, which I doubt). 2. token_iterator deals with begin/end iterators. I understand that in some rare cases there is need to iterate over range of iterators (BTW, std::input_iterator gonna be bad example - did you ever tried to use token_iterator over it?). But in most case we want to tokenize a string. And in most cases it either std::string or [char|wchar_t] const*. The fact that Iterator is a template parameter makes token_iterator usage quite inconvenient. In most cases the only template parameter that is required is IMO character type. My suggestion: lets have 2 different types if token iterators: one to iterate over string and separate to iterate over range of iterators. 3. I found it confusing in many cases how delimiters gets specified in token_iterator: token_iterator( "...", ":", " " ) Which string represent dropped delimiters, which kept? And what if I just want empty tokens? I need to write token_iterator( "...", "", "", keep_empty_tokens ) What are these two empty strings doing here?My suggestion is to use named parameters scheme. Like this: token_iterator( "...", dropped_delimiters = ":", kept_delimiters = " " ); 4. 2 Tokenizer functions use Traits as *policy* parameter. What actually is required in Compare predicate, that may or may not be implemented using char_traits. While std::basic_string references inside tokenizer function implementation should refer to traits by name std::char_traits 5. What if I want to use isspace as kept delimiters policy? There is no way to specify that. IMO delimiter policy should be separated (as runtime policy). 6. You use iterator_category as a selector of assigner. It's better to use traversal instead 7. In many places you use #if !defined(BOOST_MSVC) || BOOST_MSVC > 1300 typename #endif use BOOST_DEDUCED_TYPENAME instead 8. What is the purpose of token_iterator_generator. I do not see a need for one with new iterator facade design. 9. Why would we need all the access methods? Iterator base()const{return begin_;} Iterator end()const{return end_;}; TokenizerFunc tokenizer_function()const{return f_;} Type current_token()const{return tok_;} bool at_end()const{return valid_;} I couldn't imagine why do we need them. 10 Token iterator asserts in attempts to dereference or iterate end iterator. I don't believe it's correct. In many cases (mostly in design that assumes some optional tokens in the end) it's much more convenient this does not happened. My suggestion is to return empty token on dereference and stay quite on iteration. 11. In simpler design there won't be need in template copy constructor for token_iterator 12. Documentation need to be updated IMO, cause even as things stands now it dies not represent the best practice moved from type generators usage. 13. Files under libs/tokenizer lacks any structure required by boost standards. 14. There is no real test suite only some small examples supplied. 15. Why escaped_list_separator was named this way. It seems strange to emphasize in a name the fact that it use escape symbols, while major separations is that it is CSV list iterator - and this is how I would name it I implemented string_token_iterator and range_token_iterator for use in Boost.Test. See here (in a couple hours) http://tinyurl.com/28db9 for implementation and here http://tinyurl.com/287uk for test suite. Regards, Gennadiy.

5 16

Serializer and when to stop
by Darren Cook 07 Jun '04

07 Jun '04

I'm using boost::serializer between two programs: the first creates the data then serializes it, the second loads that data in and analyzes it. When I had just 420 data samples it all worked fine: I create a vector<Sample> in memory, serialized it and loaded it in the other side. When I moved to 7000 data samples the first program, the creator, sucked all the memory from the machine and then some. So I moved to serializing each data sample as it was created. To read it back in I changed my code from this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; archive>>samples; input_file.close(); Into this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; samples.reserve(8000); while(!input_file.eof()){ Sample s; archive>>s; samples.push_back(s); } input_file.close(); But every time it fails with an assert [1]. This seems to be when it has reached end of file. I cannot know in advance how many data samples I'll write to disk, so it seems I have three options: A: Make a special "zero" version of Sample to mark end of file B: At end of program 1 write the number of samples to a special file, and read that in before starting the above loop, so I know when to stop. C: Alter the serializer class to throw exception instead of an assert; I can then catch it and carry on. What is the best way? Is adding a terminator byte to boost::serializer an option (i.e. so I don't have to make a terminator version of each data structure I want to serialize). Incidentally my above loop does a copy of each sample as it adds it to the vector. Is the above code going to be common enough to make it worth including into boost::serializer as a helper function, which could then be optimized with in-place construction or something clever like that? (And then it could handle the termination handling itself as well.) Darren [1]: /usr/local/src/boost_1_31_0/boost/archive/basic_binary_iprimitive.hpp:119: void boost::archive::basic_binary_iprimitive<Archive, IStream>::load_binary(void*, unsigned int) [with Archive = boost::archive::binary_iarchive, IStream = std::basic_istream<char, std::char_traits<char> >]: Assertion `count == static_cast<size_t>(is.gcount())' failed.

2 1