- Boost - lists.boost.org

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

Boost License Permission
by Samuel Krempp 27 Sep '04

27 Sep '04

I Samuel Krempp, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. I thus add my name to more/blanket_permission.txt. -- Samuel Krempp

2 1

[build] doxygen and predefined macros
by Angus Leeming 27 Sep '04

27 Sep '04

My header file defines two macros, BOOST_LIB_NAME and BOOST_GLOB_DECL. I don't want either to be documented, but find that I can pass only one PREDEFINED variable to doxygen through Jamfile.v2. Multiple PREDEFINED lines don't work. Is ther a way to pass more than one variable on a single line? Regards, Angus import toolset ; toolset.using doxygen ; doxygen autodoc : ../../../boost/glob.hpp : <doxygen:param>EXTRACT_ALL=YES <doxygen:param>EXTRACT_PRIVATE=NO <doxygen:param>HIDE_UNDOC_MEMBERS=YES <doxygen:param>ENABLE_PREPROCESSING=YES <doxygen:param>MACRO_EXPANSION=YES <doxygen:param>EXPAND_ONLY_PREDEF=YES <doxygen:param>PREDEFINED=BOOST_GLOB_DECL <doxygen:param>SEARCH_INCLUDES=YES ; boostbook glob : glob.qbk.xml : <xsl:param>boost.root=../../../.. <xsl:param>toc.max.depth=3 <xsl:param>toc.section.depth=3 <xsl:param>chunk.section.depth=3 ;

1 0

Where are they now? (needed license permissions)
by John Maddock 27 Sep '04

27 Sep '04

Here are the people we still need to contact, in order to move the rest of Boost over to the BSL, if anyone has a more up to date email address for these folks than the ones shown here, please let me know, as at present they're not responding :-( Cadenza New Zealand Ltd mark.rodgers(a)cadenza.co.nz David Moore dmoore(a)viefinancial.com François Faure francois(a)cg.tuwien.ac.at Gennadiy Rozental ?? Guillaume Melquiond guillaume.melquiond(a)ens-lyon.fr Jaap Suter j.suter(a)student.utwente.nl Joerg Walter jhr.walter(a)t-online.de Mathias Koch ?? Joaquín M López Muñoz joaquin(a)tid.es Paul Moore ?? Ronald Garcia garcia(a)cs.indiana.edu Samuel Krempp krempp(a)crans.ens-cachan.fr Stephen Cleary scleary(a)jerviswebb.com Stephen Silver ?? Terje Slettebø tslettebo(a)chello.no Thomas Becker tmbecker1(a)yahoo.com William E Kempf ?? iMAGIS-GRAVIR UJF co François Faure francois(a)cg.tuwien.ac.at Francois.Faure(a)imag.fr uBLAS developers ?? Thanks! John.

2 1

explicit-failures-markup.xml invalid
by Stefan Slapeta 27 Sep '04

27 Sep '04

Currently all expected failures are not considered in the summary because explicit-failures-markup.xml was invalid. I've fixed the file now (...and hope there will soon be a fixed table, too :) ). Stefan

2 1

mingw-3.4.2 release candidate and regression tests
by Bronek Kozicki 27 Sep '04

27 Sep '04

Hello I'm going to upgrade testing environment from mingw-3.4.1 to mingw-3.4.2 release candidate (I will keep running tests on mingw-3.3.1 with toolset mingw, as it is now). I'm also going to upgrade mingw-runtime to version 3.5 and w32api to version 3.1. This might of course change results of regression tests I'm running, but I believe that these results will be closer to release version of mingw 3.4.2, when it's finally released. Any objections, opinions or advices about this move? B.

2 3

lexical_cast.hpp:102: error: `wstring' is not a member of `std' ?
by Rob 27 Sep '04

27 Sep '04

Hello, I'm not a boost expert, but I'm using LyX, which has boost (version 1.31.0) included in its source code. I have FreeBSD (4.10) and use gcc 3.4.2. When I compile LyX, I get an error from boost: [...] ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std' ../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid ../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of non-template `<type error>' ../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as non-function ../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token ../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private" When I reported this to the LyX list, I was told to forward the problem to the boost list. There may be a problem here with FreeBSD, gcc 3.4.2 and boost. Any idea what is going on here? Thanks, Rob.

2 1

dynamic_bitset taking a buffer...
by Boost Rookie 27 Sep '04

27 Sep '04

Hi, I've just started playing around with Boost. I have a specific need which I hope dynamic_bitset can fulfill. I'd like to have a dynamically sized bitbuffer which is initialized with a data stream of bits (this should be quite efficient). Then I'd like to extract the bits from that bitbuffer as specified in a protocol, e.g. bit 0-3 : version bit 4-5 : whatever bit 6 : ack bit 7-9 : whatever and so on... So something like this is what I think should be possible to do: // Note: Original code simplified to examplify... // Read DATALEN bytes from socket char buffer[DATALEN]; int read_bytes = read(socket,buffer,DATALEN); // Init a bit buffer (efficiently) boost::dynamic_bitset<unsigned char> bitbuf(buffer,read_bytes); // Extract different data, as specified by the communication protocol int version = bitbuf.get(0,4); // Extract 4 bits starting at position 0 int whatever = bitbuf.get(4,2); // Extract 2 bits starting at position 4 bool ack = bitbuf.get(6,1) // Extract 1 bit at the 6th position and so on... Reading docs at http://www.boost.org/libs/dynamic_bitset/dynamic_bitset.html shows that my shot at using dynamic_bitset is totally wrong! I cannot construct the bitbuf in that way. Instead, I should specify something called Block/BlockInputIterator as a template parameter? I do not know what that is. Looking at the examples at that page doesn't help either. Only different intergers are stored in the dynamic_bitset... It seems that a string of 1's and 0's can be stored but I really do not want to convert my original data buffer into a std::string and then convert that into a bitbuffer. After construction I do not see how to extract the bits!? Is it only possible to extract one bit at a time?!?!? Is dynamic_bitset designed to handle problems like this or am I trying to do something that is not possible? If dynamic_bitset can't help, is there something else in boost or elsewhere that is designed to solve problems like this? Thanks in advance!

1 1