- Boost - lists.boost.org

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

RE: [boost] [program_options] post-review version
by Hanson, Iain 19 Mar '04

19 Mar '04

Hi, > The library and documentation can be obtained at > > http://zigzag.cs.msu.su:7813/program_options > [ snip ... ] Is there any chance that you can put these on a url that does not use a port number. I sit behind a firewall that will not allow me to view these. Alternatively, would it be possible for you to put it in the sandbox? Thanks & regards /ikh ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================

2 1