- Boost - lists.boost.org

Re: [boost] Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 21 Mar '04

21 Mar '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Marzo 21, 2004 9:02 pm Asunto: Re: [boost] Formal Review: Indexed Set [...] > > I was unable to unzip this file on Linux -- > > $ unzip indexed_set.zip > Archive: indexed_set.zip > End-of-central-directory signature not found. Either this file > is not > a zipfile, or it constitutes one disk of a multi-part archive. > In the > latter case the central directory and zipfile comment will be > found on > the last disk(s) of this archive. > ?? So weird, I've just downloaded it (in a Windows platform) and the file opens OK. I'll try to upload a tar.gz version tomorrow (I can't right now.) > Is the sandbox also up to date? It looks like there have been > recent changes > there. > Yes, it is up to date, though I prefer to refer people to the files section instead. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Little patch for static_assert.hpp
by Gennaro Prota 21 Mar '04

21 Mar '04

Hi John, apropos gcc's -Wundef :) The attached patch allows to compile static_assert.hpp with that option turned on. While I was at it I've also changed the license reference text and removed a spurious space at the end of the line that begins with 'agurt 15/sep/02:'. Maybe BOOST_BUGGY_INTEGRAL_CONSTANT_EXPRESSIONS could be removed too (replacing it with __BORLANDC__) PS: What's 'agurt'? -- Genny. begin 644 static_assert.hpp.diff M1FEL92!D:69F97)E;F-E(')E<&]R="!G96YE<F%T960@8GD@0U-$:69F(&)Y M($-O;7!O;F5N=%-O9G1W87)E(&]N(#(P+S`S+S(P,#0@,3DN,C`-"@T*0F%S M92!F:6QE.B!#.EQ$3T-5345^,5Q!1$U)3DE^,5Q)35!/4U1^,5Q496UP7'-T M871I8U]A<W-E<G1?;W)I9U\S+FAP<`T*0V]M<&%R960@9FEL93H@1#I<0U93 M(%)E<'-<8F]O<W1<8F]O<W1<8F]O<W1<8F]O<W1<8F]O<W1<<W1A=&EC7V%S M<V5R="YH<'`-"@T*,2PU8S$L-0T*/"`O+R`@*$,I($-O<'ER:6=H="!*;VAN M($UA9&1O8VL@,C`P,"X-"CP@+R\@(%5S92P@;6]D:69I8V%T:6]N(&%N9"!D M:7-T<FEB=71I;VX@87)E('-U8FIE8W0@=&\@=&AE(`T*/"`O+R`@0F]O<W0@ M4V]F='=A<F4@3&EC96YS92P@5F5R<VEO;B`Q+C`N("A3964@86-C;VUP86YY M:6YG(&9I;&4@#0H\("\O("!,24-%3E-%7S%?,"YT>'0@;W(@8V]P>2!A="!H M='1P.B\O=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT>'0I#0H\(`T*+2TM M#0H^("\O("`@("`@("`@("`@*$,I($-O<'ER:6=H="!*;VAN($UA9&1O8VL@ M,C`P,"X-"CX@+R\@1&ES=')I8G5T960@=6YD97(@=&AE($)O;W-T(%-O9G1W M87)E($QI8V5N<V4L(%9E<G-I;VX@,2XP+@T*/B`O+R`@("`H4V5E(&%C8V]M M<&%N>6EN9R!F:6QE($Q)0T5.4T5?,5\P+G1X="!O<B!C;W!Y(&%T#0H^("\O M("`@("`@("`@(&AT='`Z+R]W=W<N8F]O<W0N;W)G+TQ)0T5.4T5?,5\P+G1X M="D-"CX@+R\-"C8Q8S8Q#0H\("`@("`A0D]/4U1?5T]22T%23U5.1"A?7TU7 M15)+4U]?+"`\(#!X,S`P,RD-"BTM+0T*/B`@("`@(2AD969I;F5D(%]?35=% M4DM37U\@)B8@0D]/4U1?5T]22T%23U5.1"A?7TU715)+4U]?+"`\(#!X,S`P M,RDI#0HW-F,W-@T*/"`O+R!A9W5R="`Q-2]S97`O,#(Z(&$@<W!E8VEA;"!C M87)E(&ES(&YE961E9"!T;R!F;W)C92!);G1E;"!#*RL@:7-S=64@86X@97)R M;W(@#0HM+2T-"CX@+R\@86=U<G0@,34O<V5P+S`R.B!A('-P96-I86P@8V%R M92!I<R!N965D960@=&\@9F]R8V4@26YT96P@0RLK(&ES<W5E(&%N(&5R<F]R M#0H-"@T*/"TM+2TM+2TM+2TM+2TM+2TM+2TM+2`@16YD(&]F(')E<&]R="`@ :+2TM+2TM+2TM+2TM+2TM+2TM+2TM/@T*#0HM ` end

2 3

[utility] enable_if request
by Jonathan Turkanis 21 Mar '04

21 Mar '04

Hi, Often I use enable_if and its cousins to add functionality to code which works okay on compilers without SFINAE. So I have a lot of code which looks like this: template<typename T> #ifndef BOOST_NO_SFINAE typename enable_if<is_xxx<T>, int>::type #else int #endif f(T t); or template<typename T> void f( T t #ifndef BOOST_NO_SFINAE , typename enable_if<is_xxx<T>, int>::type* = 0 #endif ); It would be nice to have macros BOOST_ENABLE_IF_RETURN(condition, result) and BOOST_ENABLE_IF_PARAM(condition) so that the above could be written template<typename T> BOOST_ENABLE_IF_RETURN(is_xxx<T>, void) f(T); template<typename T> void f(T BOOST_ENABLE_IF_PARAM(is_xxx<T>)); (And similarly for enable_if_c, etc.) It's straightforward to write macros which work for conditions which don't need to be enclosed in parentheses; e.g.: #ifndef BOOST_NO_SFINAE # define BOOST_ENABLE_IF_RETURN(condition, result) \ typename boost::enable_if<condition, result>::type #else # define BOOST_ENABLE_IF_RETURN(condition, result) result #endif With a little more work, you can allow use such as template<typename T, typename U> BOOST_ENABLE_IF_RETURN((is_base_and_derived<T, U>), void) f(T, U); e.g. #define BOOST_ENABLE_IF_RETURN(condition, result) \ typename boost::enable_if< \ typename boost::function_traits< \ void condition \ >::arg1_type, result \ >::type Here the parentheses in the macro invocation are required. (I've found I can make the parentheses in the macro invocation optional by surrounding 'condition' in the above #define with parentheses -- 'void(condition)' -- but I'm not sure this is standard conforming. It does work on a lot of good compilers, though.) Any thoughts? Jonathan

1 0

RE: [boost] Boost.Spirit comments and stuff
by Reece Dunn 21 Mar '04

21 Mar '04

Hartmut Kaiser wrote: >Reece Dunn wrote: > > [4] I am now making use of boost::spirit::sub_grammar from > > libs/spirit/doc/techniques.html. One thing I get from this is > > that the typedef for the grammar type can be very difficult > > to read, especially for non-trivial grammars! I have started > > writing a set of type helpers to simplify the process: > >[snip] > > > If there is interest, I shall create a proper submission for them. > >Nice idea. Do you want to submit a patch for the >libs/spirit/doc/techniques.html file? I am not sure about a patch to the techniques.html file, maybe you or Joel want to add a comment. The idea was to have the type constructors as a helper file to be used in conjunction with sub_grammar, or when building any non-rule<> (explicitly typed) rule. It contains some of the more common combinations, and can be used (using the skip_parser example) like: typedef boost::spirit::alternative_t < boost::spirit::space_parser, boost::spirit::line_comment, boost::spirit::range_comment >::type start_t; Including the entire set into the HTML file would be too distracting. A link would probably be best with a few of the classes as an example. NOTE: I have made a revision to alternative3_t so it is now a 2-4 -ary construct (it is easy to extend this to support more if there is a need) using mpl :). I have also added some more constructs that might be useful. Here is a more complex example using my helpers: struct number_parser: public boost::spirit::sub_grammar< number_parser > { public: typedef boost::spirit::contiguous_sequence_t < boost::spirit::alternative_t < boost::spirit::sequence < boost::spirit::strlit_nocase_t<>::type, boost::spirit::hex_t >, boost::spirit::sequence < boost::spirit::chlit<>, boost::spirit::oct_t >, boost::spirit::real_t<>::type >::type, boost::spirit::kleene_star< boost::spirit::chset_nocase_t<>::type > >::type start_t; public: start_t start; public: inline number_parser(): start ( boost::spirit::lexeme_d [ ( boost::spirit::as_lower_d[ "0x" ] >> boost::spirit::hex_p | '0' >> boost::spirit::oct_p | boost::spirit::real_p ) >> *boost::spirit::as_lower_d[ boost::spirit::chset_p( "ldfu" )] ] ) { } } number; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Boost.Spirit comments and stuff
by Reece Dunn 20 Mar '04

20 Mar '04

I have been learning Boost.Spirit over the past few days and here are a few queries: [1] Is it possible to process a token stream rather than a character stream? If so, are there any examples? The reason I am asking is... [2] Is it possible to cascade spirit grammars, e.g. wave.parse() >> cpp.parse(); // hypothetical where the output of the wave grammar feeds the token stream of the cpp grammar. I am not propsing that the above is how this would be expressed. [3] Is it possible to combine the file_iterator with the position_iterator to provide error reporting on that? [4] I am now making use of boost::spirit::sub_grammar from libs/spirit/doc/techniques.html. One thing I get from this is that the typedef for the grammar type can be very difficult to read, especially for non-trivial grammars! I have started writing a set of type helpers to simplify the process: namespace boost { namespace spirit { template< typename T1, typename T2, typename T3 > struct alternative3_t { typedef alternative< alternative< T1, T2 >, T3 > type; }; template< typename T1, typename T2, typename T3 > struct sequence3_t { typedef sequence< sequence< T1, T2 >, T3 > type; }; // confix_type = T1 >> *( CompositeT - T2 ) >> T2 template< typename CompositeT, typename T1 = strlit< const char * >, typename T2 = T1 > struct confix_t { typedef typename sequence3_t < T1, kleene_star< difference< CompositeT, T2 > >, T2 >::type type; }; template< typename T2 = strlit< const char * >, typename T1 = strlit< const char * > > struct comment_t { typedef typename confix_t< anychar_parser, T1, T2 >::type type; }; typedef comment_t< chlit< char > >::type line_comment; typedef comment_t<>::type range_comment; }} using these, the typedef for the skip_grammar example becomes: typedef typename boost::spirit::alternative3_t < boost::spirit::space_parser, boost::spirit::line_comment, boost::spirit::range_comment >::type start_t; If there is interest, I shall create a proper submission for them. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 2

RE: [boost] Re: [config] Patch for Intel 8.0 + Dinkum lib
by Reece Dunn 20 Mar '04

20 Mar '04

Gennaro Prota wrote: >My goal was to choose short names, as otherwise preprocessing lines >easily become enormous (if nothing else, it's a boost guideline to not >exceed 80 characters). Note that even things like: > > #if BOOST_MSVC >= 1200 > >are usually rewritten as > > #if defined(BOOST_MSVC) && BOOST_MSVC >= 1200 > >just because gcc warns about the first form when using -Wundef. And >something like > >#if defined(BOOST_GCC_CXX_VERSION) && BOOST_GCC_CXX_VERSION >= 295 > >is already 66 characters. Isn't there a BOOST_WORKAROUND macro for this? e.g. #if BOOST_WORKAROUND( BOOST_MSVC, >= 1200 ) #if BOOST_WORKAROUND( BOOST_GCC_CXX_VERSION, >= 295 ) Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

sregex_token_iterator bug?
by Stephan T. Lavavej 20 Mar '04

20 Mar '04

gcc 3.3.3 with boost 1.31.0 on GNU/Linux: [3/19/2004 Fri 8:16.41 PM stl@nuwen ~/boost] [14 33 47] > cat moo.cc #include <iostream> #include <string> #include <boost/regex.hpp> using namespace std; using namespace boost; int main() { string s; getline(cin, s); sregex_token_iterator i(s.begin(), s.end(), regex("\\s+"), -1); cout << "x" << *i << "x" << endl; ++i; cout << "x" << *i << "x" << endl; ++i; cout << "x" << *i << "x" << endl; } [3/19/2004 Fri 8:16.46 PM stl@nuwen ~/boost] [14 33 47] > g++ -Wall -W moo.cc -o moo -lboost_regex [3/19/2004 Fri 8:16.57 PM stl@nuwen ~/boost] [14 33 47] > moo 1 2 3 x1x Segmentation fault [3/19/2004 Fri 8:17.01 PM stl@nuwen ~/boost] [14 33 47] > However, the first example given in http://boost.org/libs/regex/doc/regex_token_iterator.html works fine, so I don't know what's going on. Stephan T. Lavavej http://nuwen.net

2 1

[Boost-bugs] [ boost-Bugs-920003 ] Filesystem bug with rename
by SourceForge.net 20 Mar '04

20 Mar '04

Bugs item #920003, was opened at 2004-03-20 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=920003&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Adrian (wpcmame) Assigned to: Nobody/Anonymous (nobody) Summary: Filesystem bug with rename Initial Comment: There is a bug in the windows version of filesystem::rename. In the documentation it says: ----- Source: !is_directory() Target: is_directory() The source file is moved to the target directory. ---- The problem is that the function used "::MoveFileA" will either rename a file or a directory but it will not move a file to a directory. (Error "target already exists") To move a file, the filname must also be in the target path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=920003&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[filesystem] minor problem with docs
by Jonathan Turkanis 19 Mar '04

19 Mar '04

The acknowledgements for filesystem/exception.hpp say "Peter Dimov patently identified requirements for portability and internationalization of error messages." I have a feeling this should say 'patiently.' I suppose 'patently' also makes sense here, but it seems a strange choice of words. Jonathan

2 1

[filesystem] windows bug
by John Torjo 19 Mar '04

19 Mar '04

On a windows system, doing this: path::default_name_check( &windows_name); path p( "c:/temp/test"); Throws an exception. However, having: path::default_name_check( &native); path p( "c:/temp/test"); works. I think there is a bug in path_posix_windows.cpp, line 241: if ( (checker == no_check || checker == native) && src.size() >= 2 ) I guess it should be something like: if ( (checker == no_check || checker == native || check == windows_name) && src.size() >= 2 ) Best, John

2 1