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

Re: [Test] Current failures
by Gennadiy Rozental 27 Sep '04

27 Sep '04

"Jonathan Wakely" <cow(a)compsoc.man.ac.uk> wrote in message news:20040923120115.GA88617@compsoc.man.ac.uk... > On Thu, Sep 23, 2004 at 06:22:58AM -0500, Aleksey Gurtovoy wrote: > > > Gennadiy, > > > > Could you please take a look at/comment on the current Boost.Test > > failures as per http://tinyurl.com/5wojs? > > Attached patch fixes the failures. > > jon Thanx, Jonathan. I forgot about this one. Will fix today. Regards, Gennadiy.

2 2

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 27 Sep '04

27 Sep '04

Hi again Volodya, after thinking this over I'm not so sure the mpl::deref thing has anything to do with your problem --still, it'd be good to know whether it has some impact, if you can do the test locally. I'm afraid we're in Alexsey's hands to solve this out. BTW, boost/bind/arg.hpp is deceivingly simple I can't figure out how its inclusion can make a difference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es> Fecha: Sábado, Septiembre 25, 2004 3:56 pm Asunto: Re: [boost] [multi_index + mpl + bind] Regression? > Vladimir, I don't have my compiler handy right > now, but I think this is due to an overlook when > doing the adaptation to the new MPL. In particular, > the line 50 in boost/multi_index/detail/node_type.hpp: > > typedef typename IndexSpecifierIterator::type index_specifier; > > should be changed to > > typedef typename mpl::deref<IndexSpecifierIterator>::type > index_specifier; > > (also, the corresponginf #include <boost/mp/defer.hpp> > must be inserted) > Could you please try this locally and report the results? > If the problem is solved, I'll commit something along this > line next Monday. > > I don't know the rationale for having to use deref, since > I thought these two expressions are equivalent, but there > must be some difference, for Alexsey changed some of the > code in multi_index to do that when mergien the new MPL. > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo > > > ----- Mensaje original ----- > De: Vladimir Prus <ghost(a)cs.msu.su> > Fecha: Sábado, Septiembre 25, 2004 2:41 pm > Asunto: [boost] [multi_index + mpl + bind] Regression? > > > > > The attached code, which use the multi_index library, produces > > screens of > > errors from mpl. The STLfilted log is attached too. > > > > Commenting out #include <boost/bind/arg.hpp> makes the error go > > away, as well > > as including it after multi_index. > > > > This happens with: > > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > > > The code used to work some time ago, but I can't give the exact > date.> > > I've tried too look at the problem, but got lost in MPL internals. > > > > - Volodya > > > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 8

[Test or Build?] How to add dummy files and dirs to a test?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I'm putting the finishing touches to a Posix-conformant boost::glob function that I'd like to submit to Boost (assuming there's some interest). However, before I do so, I'd like to get the regression tests running smoothly. Currently my 'test' directory contains: $ ls .oo* foo* foo1bar foo bar foo!bar foo]bar foo*bar foocbar foo.hpp fooabar foo-bar foo?bar foo{bar foo\bar foo.cpp .oobar foo^bar foo,bar foo[bar foo}bar foobbar foo.cxx All 20 of these files have zero size; the idea is to test boost::glob's ability to find matches. However, I'd rather not have them as part of the library. How do I get the test framework to create them for me before running a test? Regards, Angus

4 7

[serialization] documentation for xml archive usage
by Christoph Ludwig 27 Sep '04

27 Sep '04

Hi, I am using the Boost Serialization library with the text archive implementation in my project and it works quite well. Robert did a very good job - thanks! For some reason I am considering switching to the xml archive implementation. However, this triggers a BOOST_STATIC_ASSERT in basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). The implementation insists that all serialized types be wrapped in a nvp<T>. I think I understand more or less why this is necessary - the xml archive implementation generates the xml name tags from the information stored in the nvp wrapper. But I couldn't find an explanation in the docs what special steps a user is supposed to take if the data shall be serialized into an xml archive. (The only hint that xml archives need special care that I found was the description of the header file nvp.hpp libs/serialization/doc/headers.html: "To associate a name tag with a serializable object. This is necessary to properly render an xml archive which includes the object name." BTW, this webpage claims nvp.hpp is in boost/archive, but in fact it is in boost/serialization.) Do I need to write ar & nvp<MyMemberType>("my_member_tag", this->my_member); in my serialization functions for every variable I want to (de-)serialize? Can I choose an arbitrary tag for each variable or is it supposed to be consistent for all variables of a specific type? Am I correct to assume that the code will still work if I serialize into a "normal" text archive and the nvp will essentially be ignored? I guess I could find my answers by some trial and error and digging through the test cases. But since I probably won't be the only user looking for this information may I suggest that a section explaining the issues with xml archives be added to the docs before the 1.32 release? Thanks Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 2

[program_options] cw9.3 failures
by Vladimir Prus 27 Sep '04

27 Sep '04

The current regression test results show two similar failures of program_options on cw9.3 http://tinyurl.com/6ay5m The situation is the following: parsers.hpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>&, const options_description&); parsers.cpp contain: template<class charT> basic_parsed_options<charT> parse_config_file(std::basic_istream<charT>& is, const options_description& desc) { ........ } template BOOST_PROGRAM_OPTIONS_DECL basic_parsed_options<char> parse_config_file(std::basic_istream<char>& is, const options_description& desc); And the linker can't find the explicitly instantinated function. This happens only in _dll tests, so I'd suspect a bug in the compiler/linker. Can anybody sched the light on this? Thanks, Volodya

2 4

Any interest in a boost::glob() function?
by Angus Leeming 27 Sep '04

27 Sep '04

Dear all, I've taken Richard Johnson's glob_iterator that he posted to the list back in January and re-written it completely, using Boost.Spirit to transform the input 'glob' into an equivalent regex. The result is a 'boost::glob' function that I believe is fully POSIX-conformant. Example usage: fs::path const starting_directory("."); std::list<fs::path> const matches = boost::glob("../te?t/foo*bar", starting_directory); The docs can be browsed online at http://www.devel.lyx.org/~leeming/globbing/index.html The library can be found at http://www.devel.lyx.org/~leeming/globbing.zip It should unzip to give: boost/glob.hpp boost/detail/glob.hpp libs/glob + ensuing sub directories and files. The code has been tested on Linux (g++ 3.3.2) and on Windows using MinGW/MinSys. There are still some "issues" that I don't know how to resolve. Any pointers would be most welcome: REGEX ===== A single test "foo[[:alpha:]]bar" is failing under Windows. It succeeds under Linux. Is there anything about Boost.Regex with MinGW/MinSys that I should be aware of? DOCS ==== * It would be nice to insert a table inside an itemized list item, but quickbook doesn't like doing that. Instead I must add the table in a separate paragraph which messes up the look a little. * boostbook/doxygen fails to document the glob_flags enum. * I generate a BOOST_LIB_NAME.html page and would like to supress it. * The bottom of the first page has this "Last revised: September 13, 2004 at 04:56:20 GMT" I don't know where it comes from, but it's just not true ;-) BUILD ===== I have a couple of targets, lib/glob/example/real_glob.cpp and lib/glob/test/test_real_glob.cpp that I'd like to build only on POSIX machines. (They're wrappers for the system glob function.) Any pointers on how to instruct bjam to do that? Regards, Angus

1 0

Re: immutable string
by Igor Kholodov 27 Sep '04

27 Sep '04

>> Any plans in the future >> to add reverse iterator support to const_string? >> I wrote some code to work around the absence >> of const_reverse_iterator, rbegin(), and rend(), >> all of which would be nice to have available. > >They are there. Sorry, I meant to say that existing versions of rbegin() and rend() inside const_string template class return reverse_iterator, not const_reverse_iterator. There is a typedef for "reverse_const_iterator", but it is not used by any member functions. At the same time, std::basic_string<> provides const_reverse_iterator, just like all other sequence containers. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/

2 1

RE: [boost] Name checking in filesystem
by Ben Hutchings 27 Sep '04

27 Sep '04

Walter Landry <wlandry(a)ucsd.edu> wrote: > I have come across an annoying problem with the filesystem library. I > have wrapped filesystem with Swig so that I can call it from python. <snip> Er... why? Aside from the name portability checking, I think everything in Boost.Filesystem is already available in the Python standard library. Ben.

2 1

[mpl] bad interaction with Boost.Bind
by Joaquín Mª López Muñoz 27 Sep '04

27 Sep '04

This is a distilled form of the problem Vladimir found in http://tinyurl.com/3zsha The attached snippet fails with the latest CVS image in GCC 3.2 (see err.out). If I comment the first line #include <boost/bind/arg.hpp> // comment to get it working the snippet works OK. Also, the code works fine for Boost 1.31, (by previously replacing reverse_iter_fold with iter_fold_backward, of course) regardless of wether I comment or not the first line. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo foo.cpp: In instantiation of `f1::apply<mpl_::_2, mpl_::_1>': /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: instantiated from `boost::mpl::apply_wrap2<f1, mpl_::_2, mpl_::_1>' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: instantiated from `boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>::apply<int, boost::mpl::v_iter<f3, 3>, mpl_::na, mpl_::na, mpl_::na>' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply_wrap2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here foo.cpp:11: no type named `type' in `struct mpl_::_2' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp: In instantiation of `boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>::apply<int, boost::mpl::v_iter<f3, 3>, mpl_::na, mpl_::na, mpl_::na>': /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply_wrap2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: instantiated from `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/bind.hpp:205: no type named `type' in `struct boost::mpl::apply_wrap2<f1, mpl_::_2, mpl_::_1> ' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp: In instantiation of `boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >': /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: instantiated from `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >' foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:140: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:141: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:142: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:143: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/aux_/preprocessed/gcc/reverse_iter_fold_impl.hpp:146: no type named `type' in `struct boost::mpl::apply2<boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, int, boost::mpl::v_iter<f3, 3> >' /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp: In instantiation of `boost::mpl::reverse_iter_fold<f3, int, f2, boost::arg<1> >': foo.cpp:23: instantiated from here /usr/local/boost_1_32_alpha/boost/mpl/reverse_iter_fold.hpp:43: no type named ` state' in `struct boost::mpl::aux::reverse_iter_fold_impl<4, boost::mpl::v_iter<f3, 0>, boost::mpl::v_iter<f3, 4>, int, boost::mpl::bind2<f1, mpl_::_2, mpl_::_1>, boost::mpl::protect<mpl_::arg<1>, 0> >' foo.cpp:23: syntax error before `;' token foo.cpp: In function `int main()': foo.cpp:27: `f4' undeclared (first use this function) foo.cpp:27: (Each undeclared identifier is reported only once for each function it appears in.) foo.cpp:27: parse error before `;' token

2 2

RE: [boost] Re: Re: Constrained genericity at last? (anyinterestinanoperator traits/concept traits library?)
by Ben Hutchings 27 Sep '04

27 Sep '04

Matt Hurd <matt.hurd(a)gmail.com> wrote: > Victor A. Wagner Jr. <vawjr(a)rudbek.com> wrote: > > I don't see the safety issue and what you showed is incorrect; > > a + (b-a) / 2 is at least correct, but b-a overflows just as readily > > as a+b > > oops, for sure, b-a rather. > > I'm missing some understanding, given that b >= a, why is b-a just as > ready to overflow as a+b? I guess you are saying b - a > 2GB > (typical ptrdiff_t) is just as likely as an overflow from a + b, if > it was legal, on a common 32 bit platform for example, or have I > misunderstood? For any two pointers a, b into the same array, b - a is well-defined, so a + (b - a) / 2 is as well. (So if ptrdiff_t has n value bits, arrays must have fewer than 2^(n-1) elements.) If a and b don't point into the same array, b - a is undefined. I don't see any basis for Victor's statement that "b-a overflows". Given the way pointers are commonly represented, adding them is likely to result in overflow very often unless one uses extra bits in the representation of pointer sums. This is not a problem if one sticks to modulo arithmetic, but it is if one wants to do division. Ben.

1 0