- Boost - lists.boost.org

program_options - required (or min/max) number of occurences declaratively?
by Jonathan Graehl 27 Sep '04

27 Sep '04

I grepped through the program_options source and couldn't find anything about declaratively specifying required options (or even more specifically, min/max # of occurrences), except for positional options. I know it's possible to do variables_map::count("option-name") or if I have an impossible default value bound to an option, I could check for that (default would = option absence), but it might be nice to have "requiredness" be a declared option trait, that could show up in the option description. value<int>(&myoption)->required() or something like that - obviously min/max wouldn't make sense for scalars (I have no use for min/max personally). -Jonathan p.s. I know there is a concept in the command line parser of "value required or not" - I'm talking about an *option* being required.

4 4

Re: immutable string
by Igor Kholodov 26 Sep '04

26 Sep '04

>Igor Kholodov <C.JUMP(a)prodigy.net> wrote: > >> I am testing immutable string outside boost, using it >> as string type with common text transformation library >> (http://cttl.sourceforge.net/) It works quite well, >> about 18% speed is gained while parsing large XML >> documents (>1MB) when using const_string. > >Could you please specify the compiler and STL implementation you use? > Tested with GCC 3.4.1 (mingw) and GCC 3.2.3 on linux. Igor Kholodov cttl(a)users.sourceforge.net http://cttl.sourceforge.net/ Igor Kholodov http://cttl.sourceforge.net/

2 1

RSI/cw-8.3 results
by Aleksey Gurtovoy 26 Sep '04

26 Sep '04

Rene, Since you are testing with a quite different configuration than ours, could you please adjust the name of your toolset somehow so that we have the ability to mark up the failures specific to your setup? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

CW 9.3 results (or lack thereof) - current state
by Stefan Slapeta 26 Sep '04

26 Sep '04

After one day and one night of investigation, I think (!) I've finally managed to make bjam report correct results for my regressions. As it seems, the solution is not calling cv_env.bat before running the test. This batch file is also called again before each test case and it seems that the environment gets somewhat confused then: during the execution of the cmd file the errorlevel is still set to 0 after the test case has been executed although the test case definitely reported something different. What I know for sure is that this problem occurs independent of the OS and the machine (see the temporary 'slapeta_experimental' results) and whether the test is started by regression.py or not. The results for CW-9.3 seem to be correct now and thus there should be some more failing test cases for this toolset now. As for my Intel 8.0 results, I hope there are no similar interferences because they don't run without calling iclvars.bat once. I must manually make a testcase fail to verify this (before I fixed the tss cleanup, Intel failed, too, but this wasn't reported, either). That's where I am at the moment. Cheers, Stefan

4 5

Re: [boost] immutable string
by Igor Kholodov 26 Sep '04

26 Sep '04

I am testing immutable string outside boost, using it as string type with common text transformation library (http://cttl.sourceforge.net/) It works quite well, about 18% speed is gained while parsing large XML documents (>1MB) when using const_string. I would like to point out a couple of issues: First, there seems to be a typo in implementation of const_string& append(char_t c, size_t n). It should use a comma instead of dot when calling corresponding constructor of const_string. See const_string.hpp, line 444. Second, a lack of length() member function. Thanks, Igor Kholodov cttl(a)users.sourceforge.net --- Original Message --- From: "Maxim Yegorushkin" <e-maxim(a)yandex.ru> To: boost(a)lists.boost.org Subject: [boost] immutable string >Hello all, > >I've been working on a small library - an immutable C++ string. Now it is >in usable state and has been put in use in a couple of real projects. >Although it needs further polishing, I would like to know is there any >interest in such a library? > >Here is the link: http://conststring.sourceforge.net/ > >-- >Maxim Yegorushkin > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Igor Kholodov http://cttl.sourceforge.net/

2 2

Re: [boost] [Pointer Containers] [Indexed Set]
by JOAQUIN LOPEZ MU?Z 26 Sep '04

26 Sep '04

Hi Bruno, ----- Mensaje original ----- De: Bruno Martínez Aguerre <br1(a)internet.com.uy> Fecha: Viernes, Septiembre 24, 2004 10:44 pm Asunto: [boost] [Pointer Containers] [Indexed Set] > Hi. > > I was wondering if these two libs work together. That is, can > Indexed > Sets take ownership of my pointers? (First of all, the lib was renamed to Boost.MultiIndex.) Indexed containers are no different to STL containers in this respect: you can control ownership issues with some smart pointer, for instance boost::shared_ptr, so that objects pointed to get deleted along with the container. Apart from this, no special provision has been made to work with pointers. Ownership management aside, I'd say one of the key features of Thorsten's pointer containers is that their interface automatically dereference the pointers held so as to create the illusion that it is the actual elements that are being stored in the container. This feature is not supported by Boost.MultiIndex, and I don't think both libs can be used together to implement this artifact. To get something close to that, you can put a "view" on top of a multi_index_container of pointers and get dereferencing access. There are some view libraries out there. > > Also, I couldn't find the docs for neither of the two libs. I > looked here > http://www.boost.org/regression-logs/cs- > win32_metacomm/doc/html/libraries.html > for Indexed Set, The lib was renamed to Boost.MultiIndex, and will ship with Boost 1.32. In the meantime you can consult the docs at www.boost-consulting.com/boost/libs/multi_index > and here > http://boost-consulting.com/boost/more/formal_review_schedule.html > for > Pointer Containers. This Thorsten already anwered. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

** releasing **
by David Abrahams 26 Sep '04

26 Sep '04

Hi Everyone, This is just a reminder that we are trying very hard to get to a release point. Aleksey has been making an incredible effort in managing this release, so please do everything in your power to be responsive to his requests. Being proactive is even better, so if you can, see if there are any regressions you can fix. Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 3

BOOST_STATIC_ASSERT and gcc 3.3
by Mark Purtill 26 Sep '04

26 Sep '04

BOOST_STATIC_ASSERT doesn't produce a useful error message with gcc 3.3. E.g.: #include <boost/static_assert.hpp> BOOST_STATIC_ASSERT(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:3: error: invalid application of `sizeof' to an incomplete type According to <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15337>, this is fixed, but some of use will still be using gcc 3.3 for a while. It turns out the version of BOOST_STATIC_ASSERT used when BOOST_INTEL_CXX_VERSION is defined works for the offending versions of gcc, too: #include <boost/static_assert.hpp> # define BOOST_STATIC_ASSERT_1( B ) \ typedef char BOOST_JOIN(boost_static_assert_typedef_, __LINE__) \ [ ::boost::STATIC_ASSERTION_FAILURE< (bool)( B ) >::value ] BOOST_STATIC_ASSERT_1(0); produces % g++ -c -o bsa.o bsa.cpp bsa.cpp:6: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' Could that version be used for gcc 3.3 and 3.4.0 in the upcoming boost 1.32? FYI: % gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions--enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib --enable-__cxa_atexit --enable-clocale=generic Thread model: posix gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) -- ^.-.^ Mark Purtill (("))

2 1

mpl::equal_to changes
by Ian McCulloch 26 Sep '04

26 Sep '04

Hi, Is the following program supposed to compile with the new MPL? It works fine with boost 1.31, but apparantly fails in CVS. But, maybe I was mis-using equal_to ? #include <boost/mpl/equal_to.hpp> #include <boost/mpl/bool.hpp> int main() { boost::mpl::equal_to<boost::mpl::bool_<true>, boost::mpl::bool_<true> > dummy; } Error message from CVS is: (thanks to Matthias Troyer for testing it) ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to_tag<mpl_::bool_< true> >': ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: instantiated from `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >' test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:60: error: no type named `tag' in `struct mpl_::bool_< true>' ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp: In instantiation of `boost::mpl::equal_to<mpl_::bool_< true>, mpl_::bool_< true> >': test.C:11: instantiated from here ../boost/boost/mpl/aux_/preprocessed/gcc/equal_to.hpp:72: error: no type named `type' in `struct boost::mpl::equal_to_tag<mpl_::bool_< true> >' Cheers, Ian

4 4

[numeric/conversion] fixes for intel-win32-7.1-vc6
by Joaquín Mª López Muñoz 26 Sep '04

26 Sep '04

These are trivial fixes taking care of BOOST_NO_STDC_NAMESPACE. With them, converter_test and udt_support_test (the latter is currently marked as known fail) work for Intel 7.1. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 33a34 > #if !defined(BOOST_NO_STDC_NAMESPACE) 35a37,38 > #endif > 52a56 > #if !defined(BOOST_NO_STDC_NAMESPACE) 55c59 < --- > #endif 81a86 > #if !defined(BOOST_NO_STDC_NAMESPACE) 82a88,89 > #endif > 97a105 > #if !defined(BOOST_NO_STDC_NAMESPACE) 98a107,108 > #endif > 496a497,498 > > #if !defined(BOOST_NO_STDC_NAMESPACE) 497a500,501 > #endif >

3 5