- Boost-users - lists.boost.org

problem compiling with Dinkumware
by Jean-Pierre Gygax 26 Jun '04

26 Jun '04

Hi, I'm having trouble properly compiling Boost with the Dinkumware STL implementation (working with Visual C++ 7.1). The problem is that bjam always calls CL with a /I that pulls in Microsoft's include files first, so that they take precedence over the Dinkumware ones. This behavior seems to be rooted far down in the file Jambase located in jam_src. I don't really feel like fooling with that. What can I do? -- Jean-Pierre

3 5

Tweaking the Skip Parser, was RE: [Boost-users] Spirit 1.6 with VC6
by Mark Storer 26 Jun '04

26 Jun '04

> No chance of switching to 7.1? :-) Things are looking up. We just did a project-wide upgrade to... VC7.1. Problem solved. I'm now merrily writing rules for my JavaScript parser. It doesn't have to support the whole language (not for a while, maybe never), I just need to be able to parse out the names and locations of all the functions in a file. It's for a JavaScript editor built into one of our products, and later we'll be adding auto-completion. That'll require a more thorough parser, but for now, I'm just after funciton locations. So far so good... though I'll undoubtedly be quite familiar with the BOOST_SPIRIT_DEBUG* macros before I'm done. I've got another Spirit question: I've been adding "*comment" throughout the rules and it's getting tiresome: rule<phrase_scanner_t> blockComment = comment_p( "/*", "*/" ); rule<phrase_scanner_t> lineComment = comment_p( "//" ); rule<phrase_scanner_t> comment = blockComment | lineComment; Spraying the "comment" rule liberally through my rules is an option... rule<phrase_scanner_t> codeBlock = ch_p('{') >> *(comment | codeBlock | ~ch_p('}')) >> ch_p('}'); ... but not an appealing one. This becomes particularly true once I start working on the auto-completion parser. It just occured to me that if the skip parser ate comments for me, it would greatly simplify my rules. I'd like to tweak the skip parser so it skips over my "comment" rule as well as white space. I just took a stab at this, but didn't get very far. I tried: parse(str, rules, space_p | comment) but that resulted in a compiler error. 7.1's errors are MUCH easier to read that 6's. I'm going to like this new compiler. C:\SDKs\boost_1_31_0\boost\spirit\core\non_terminal\impl\rule.ipp(190): error C2664: 'boost::spirit::impl::abstract_parser<ScannerT,AttrT>::do_parse_virtual' : cannot convert parameter 1 from 'const scanner_t' to 'const boost::spirit::rule<T0>::scanner_t &' with [ ScannerT=boost::spirit::rule<boost::spirit::phrase_scanner_t>::scanner_t, AttrT=boost::spirit::rule<boost::spirit::phrase_scanner_t>::attr_t ] and [ T0=boost::spirit::phrase_scanner_t ] Pointing me to the relevant section of the docs is an acceptable answer, though I wouldn't mind a little more info than that. ;) I'll keep plugging away. If I come up with an answer, I'll post it to the list. I'd expect this to be useful to other beginners at the very least. --Mark Storer Senior Software Engineer Verity, Inc.

3 3

RE: [Boost-users] Re: Tweaking the Skip Parser, was RE: Spirit 1.6 with VC6
by Mark Storer 25 Jun '04

25 Jun '04

Okay. Problem solved. The answer was indeed inside #scanner_business. Rules make for picky parsers. So I used a grammar<> and it compiled just fine. Now if I can just get it to WORK. ;) Whoops. Infinite recursion. Back to the drawing board... but at least now I don't need "*comment" sprinkled liberally throughout my rules. --Mark Storer Senior Software Engineer Verity, Inc. > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Jeff Flinn > Sent: Friday, June 25, 2004 10:46 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: Tweaking the Skip Parser,was RE: Spirit 1.6 > with VC6 > > > Take a look at: > > http://www.boost.org/libs/spirit/doc/faq.html#scanner_business > > You don't want the skip parser to be a phrase level scanner. > > parse(str, rules, space_p | comment_p( "/*", "*/" ) | > comment_p( "//" ) ) > > may work for you? > > Jeff F > > "Mark Storer" <MStorer(a)verity.com> wrote in message > news:076D1E704127414E9FEAFFC31F66C9472739CD@vrsdex1.verity.com... > > > No chance of switching to 7.1? :-) > > > > Things are looking up. We just did a project-wide upgrade > to... VC7.1. > Problem solved. I'm now merrily writing rules for my > JavaScript parser. It > doesn't have to support the whole language (not for a while, > maybe never), I > just need to be able to parse out the names and locations of all the > functions in a file. It's for a JavaScript editor built into > one of our > products, and later we'll be adding auto-completion. That'll > require a more > thorough parser, but for now, I'm just after funciton locations. > > > > So far so good... though I'll undoubtedly be quite familiar with the > BOOST_SPIRIT_DEBUG* macros before I'm done. > > > > I've got another Spirit question: I've been adding > "*comment" throughout > the rules and it's getting tiresome: > > > > rule<phrase_scanner_t> blockComment = comment_p( "/*", "*/" ); > > rule<phrase_scanner_t> lineComment = comment_p( "//" ); > > rule<phrase_scanner_t> comment = blockComment | lineComment; > > > > Spraying the "comment" rule liberally through my rules is > an option... > > > > rule<phrase_scanner_t> codeBlock = ch_p('{') >> > *(comment | codeBlock > | ~ch_p('}')) >> ch_p('}'); > > > > ... but not an appealing one. This becomes particularly > true once I start > working on the auto-completion parser. > > > > It just occured to me that if the skip parser ate > comments for me, it > would greatly simplify my rules. I'd like to tweak the skip > parser so it > skips over my "comment" rule as well as white space. I just > took a stab at > this, but didn't get very far. I tried: > > > > parse(str, rules, space_p | comment) > > > > but that resulted in a compiler error. 7.1's errors are > MUCH easier to > read that 6's. I'm going to like this new compiler. > > > > > C:\SDKs\boost_1_31_0\boost\spirit\core\non_terminal\impl\rule. > ipp(190): > error C2664: > 'boost::spirit::impl::abstract_parser<ScannerT,AttrT>::do_pars > e_virtual' : > cannot convert parameter 1 from 'const scanner_t' to 'const > boost::spirit::rule<T0>::scanner_t &' > > with > > [ > > > ScannerT=boost::spirit::rule<boost::spirit::phrase_scanner_t>: > :scanner_t, > > > AttrT=boost::spirit::rule<boost::spirit::phrase_scanner_t>::attr_t > > ] > > and > > [ > > T0=boost::spirit::phrase_scanner_t > > ] > > > > Pointing me to the relevant section of the docs is an > acceptable answer, > though I wouldn't mind a little more info than that. ;) > > > > I'll keep plugging away. If I come up with an answer, I'll > post it to the > list. I'd expect this to be useful to other beginners at the > very least. > > > > --Mark Storer > > Senior Software Engineer > > Verity, Inc. > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

RE: [Boost-users] Re: Tweaking the Skip Parser, was RE: Spirit 1.6 with VC6
by Mark Storer 25 Jun '04

25 Jun '04

Neither of your suggestions worked for me. Both gave me the same basic "do_parse_virtual: can't convert from 'const scanner_t' to 'const boost::spirit::rule<T0>::scanner_t &'". I had a suspision about the phrase vs char thing... good to know. So should I be looking for a compiler fix or an alternate path? Still plugging away... no joy yet. --Mark Storer Senior Software Engineer Verity, Inc. > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Jeff Flinn > Sent: Friday, June 25, 2004 10:52 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: Tweaking the Skip Parser,was RE: Spirit 1.6 > with VC6 > > > Mark, > > I didn't mean to imply this was the only way to accomplish > what you want to > do. You can create a full fledged grammar and use it as your > skip parser. > Or, create a functor_parser, which works for me. > > struct SkipperDct > { > typedef int result_t; > > template< typename ScannerT > > int operator()( ScannerT const& scan, result_t& )const > { > match<> m = ( +space_p > | lexeme_d[ comment_p("//") > | comment_nest_p("/*","*/") > ] > ).parse( scan ); > > return m? m.length() : -1; > } > }; > > functor_parser<SkipperDct> SkipperDct_p; > > }; > > Also note the use of 'comment_nest_p'. > > Jeff F > > > > "Mark Storer" <MStorer(a)verity.com> wrote in message > news:076D1E704127414E9FEAFFC31F66C9472739CD@vrsdex1.verity.com... > > > No chance of switching to 7.1? :-) > > > > Things are looking up. We just did a project-wide upgrade > to... VC7.1. > Problem solved. I'm now merrily writing rules for my > JavaScript parser. It > doesn't have to support the whole language (not for a while, > maybe never), I > just need to be able to parse out the names and locations of all the > functions in a file. It's for a JavaScript editor built into > one of our > products, and later we'll be adding auto-completion. That'll > require a more > thorough parser, but for now, I'm just after funciton locations. > > > > So far so good... though I'll undoubtedly be quite familiar with the > BOOST_SPIRIT_DEBUG* macros before I'm done. > > > > I've got another Spirit question: I've been adding > "*comment" throughout > the rules and it's getting tiresome: > > > > rule<phrase_scanner_t> blockComment = comment_p( "/*", "*/" ); > > rule<phrase_scanner_t> lineComment = comment_p( "//" ); > > rule<phrase_scanner_t> comment = blockComment | lineComment; > > > > Spraying the "comment" rule liberally through my rules is > an option... > > > > rule<phrase_scanner_t> codeBlock = ch_p('{') >> > *(comment | codeBlock > | ~ch_p('}')) >> ch_p('}'); > > > > ... but not an appealing one. This becomes particularly > true once I start > working on the auto-completion parser. > > > > It just occured to me that if the skip parser ate > comments for me, it > would greatly simplify my rules. I'd like to tweak the skip > parser so it > skips over my "comment" rule as well as white space. I just > took a stab at > this, but didn't get very far. I tried: > > > > parse(str, rules, space_p | comment) > > > > but that resulted in a compiler error. 7.1's errors are > MUCH easier to > read that 6's. I'm going to like this new compiler. > > > > > C:\SDKs\boost_1_31_0\boost\spirit\core\non_terminal\impl\rule. > ipp(190): > error C2664: > 'boost::spirit::impl::abstract_parser<ScannerT,AttrT>::do_pars > e_virtual' : > cannot convert parameter 1 from 'const scanner_t' to 'const > boost::spirit::rule<T0>::scanner_t &' > > with > > [ > > > ScannerT=boost::spirit::rule<boost::spirit::phrase_scanner_t>: > :scanner_t, > > > AttrT=boost::spirit::rule<boost::spirit::phrase_scanner_t>::attr_t > > ] > > and > > [ > > T0=boost::spirit::phrase_scanner_t > > ] > > > > Pointing me to the relevant section of the docs is an > acceptable answer, > though I wouldn't mind a little more info than that. ;) > > > > I'll keep plugging away. If I come up with an answer, I'll > post it to the > list. I'd expect this to be useful to other beginners at the > very least. > > > > --Mark Storer > > Senior Software Engineer > > Verity, Inc. > > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

a template to extend types to support something like SQL NULL
by Erik Thiele 25 Jun '04

25 Jun '04

hi i have an int. but it should also support a "undefined" state like SQL NULL. most times i can use -1 for this. but there are also data types without a reasonable undefined value. maybe float or double. or maybe -1 is perfectly legal. so i used my own smartptr class (which i will replace by boost::shared_ptr since it is better and compatible to libs from strangers) to fix the problem as follows: shared_ptr<int> a(new int(10)); shared_ptr<int> b; // has the value "undefined" like SQL NULL. now i can do checks like if ( ! b ) printf("%d", *b); now my problem was that several places in my program access the same int instance. they can assign values, and then other parts of the program can read these values. that's good behaviour.but i cannot set the object to "undefined". see why: void foo (shared_ptr<int> a) { *a = 10; // <-- ok! this works! everybody now has the 10! } void errorfoo (shared_ptr<int> a) { a.reset(); // <-- this does of course not work, since only my local // copy of a is now SQL NULL. } so i restructured my shared_ptr to make it able to hold this special SQL NULL state also. this way i got really awkward semantics though. i don't go in details here, but in my shared_ptr the errorfoo function works as expected. (the function is not called "reset" then). but i got severe problems in typecast semantics of my modified shared_ptr, so i decided to dump this beast before anyone else has to see it :-))) i thought that maybe it's not a good idea to unite smartpointer with SQL NULL facility. maybe it is better to write: shared_ptr<nullabletype<int> > x(new nullabletype<int>(55)); x->setnull(); if (x->isnull()) fooooo(); printf("the int is %d\n", x->obj()); // throw exception if x is null in this example the shared_ptr is just sugar. it is not needed. the nullable subsystem is now independent from shared_ptr. is there such a nullable type extender beast in boost somewhere? or do i have to invent it? by the way, the following is not a good solution i think: int thevalue; bool thevalue_is_defined; now programmers can do errors like access "thevalue" even though "thevalue_is_defined" is false. i want some mechanism to prevent programmers from doing this kind of errors. if and only if the value is defined it should be possible to read it. also this nullable type extender is handy for a database layer to interact with SQL. cya! erik -- Erik Thiele

3 2

OT: detect unneded includes
by Erik Thiele 25 Jun '04

25 Jun '04

hi. this is OFFTOPIC. i am searching for a way to detect unused #include directives. i'd appreciate some GPL tool. in the transition from more and more of my own small helper classes to boost stuff i find difficult to remove unneeded #includes. i am sure my code is full of useless dependencies. cya erik -- Erik Thiele

2 1

Spirit 1.6 with VC6
by Mark Storer 25 Jun '04

25 Jun '04

I'm getting several compiler errors when trying to use the Spirit library. When compiling one of the samples from the v1.6 documentation, I get a linker error: SpiritTest.obj : fatal error LNK1179: invalid or corrupt file: duplicate comdat "?do_parse@?$parse_subrule@V?$match@Unil_t@spirit@boost@@@spirit@boost@@U?$subrules_scanner@V?$scanner@PBDU?$scanner_policies@U?$skipper_iteration_policy@Uiteration_policy@spirit@boost@@@spirit@boost@@Umatch_policy@23@Uaction_policy@23@@spirit@boos67ac75e0" LNK1179 suggested that the /H _compiler_ option might be involved. It (supposedly) controls how long a symbol is allowed to be when the compiler is generating symbol names. I've tried several different variations on the /H option, /H512, /H1024, etc. They all give the same error message, and the symbol "?do_parse@..." doesn't get any longer (or shorter for that matter). I also get a number compiler errors when I #include <boost/spirit.hpp>: c:\sdks\boost-1.30.2\boost\spirit\utility\impl\chset\basic_chset.ipp(32) : error C2955: 'arg' : use of class template requires template argument list c:\sdks\boost-1.30.2\boost\bind\arg.hpp(26) : see declaration of 'arg' ----------basic_chset.ipp, lines 31-33 template <typename CharT> inline basic_chset<CharT>::basic_chset(basic_chset const& arg) : rr(arg.rr) {} ----------arg.hpp lines 24-26 template<int I> class arg { }; The boost/bind include is in the core/composite/actions. Trying to mess with the order of inclusion seems Fraught With Peril. The basic_chset template is in "utility", and everything in "utility" depends on various bits and pieces of "core". basic_chset is derived from unary, which is defined in core/composite. A Gordian knot... and me without a sword. --Mark Storer Senior Software Engineer Verity, Inc.

2 1

RE: [Boost-users] protassign
by Nat Goodspeed 24 Jun '04

24 Jun '04

> -----Original Message----- > From: Nat Goodspeed > Sent: Wednesday, June 23, 2004 12:17 PM > To: boost-users(a)lists.boost.org > Subject: RE: [Boost-users] protassign > > In the forthcoming Boost serialization library: > > http://www.rrsd.com/boost/ > > there's a state_saver template class that does what you're talking > about: > > http://www.rrsd.com/boost/libs/serialization/doc/state_saver.html > > This seems useful enough to promote to a library more general than the > serialization library. Hmm! I was suggesting that the state_saver template from the serialization library be elevated. If the protassign template makes it into Boost sooner, may I suggest that the serialization library be revised to use protassign instead of state_saver? We certainly wouldn't want two redundant Boost templates.

1 0

RE: [Boost-users] protassign
by Nat Goodspeed 24 Jun '04

24 Jun '04

> -----Original Message----- > From: Erik Thiele [mailto:erik@thiele-hydraulik.de] > Sent: Wednesday, June 23, 2004 11:28 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] protassign > > now i can do: > > void foo() > { > protassign<bool> foorunning_assigner(foorunning, true); > dojobs(); > dofoooo(); > } > > and that's all. is there one such thing in boost already??? [Nat] In the forthcoming Boost serialization library: http://www.rrsd.com/boost/ there's a state_saver template class that does what you're talking about: http://www.rrsd.com/boost/libs/serialization/doc/state_saver.html This seems useful enough to promote to a library more general than the serialization library.

3 3

failures and featurerequest in/for numeric_cast
by Peter Piehler 24 Jun '04

24 Jun '04

failures and featurerequest in/for numeric_cast I use boost in a little project for my study. In some cases the software must convert numeric datatypes. So I tried to convert with boost-library numeric_cast and found the following problems (gcc version 3.2.3 20030422): -the maximum could not be handled correctly, for example: +numeric_cast<int>(numeric_limits<unsigned int>::max()); doesn't throw a exception -no precession handling, example: +numeric_cast<float>(numric_limits<double>::epsilon()+1); doesn't throw a exception -no NaN, bounded/unbounded and exact handling. -no specialization. I need numeric_cast specializiation for: +numeric_limits-interface can't use for datatypes with caracteristics only known at runtime. +datatyps without static_cast support (example: gmp-library) So I have extended the boost::numeric_cast for my special requirements. You can download it under the following link: http://www.pienet.de/source/numeric_cast.tar.gz . Compile and run numeric_cast_tescases.cpp with USE_BOOST_CAST to test ::boost::numeric_cast. The output is: Running 2 test cases... numeric_cast_testcases.cpp(72): error in "standard_cast_test": exception bad_numeric_cast is expected numeric_cast_testcases.cpp(91): error in "standard_cast_test": exception bad_numeric_cast is expected numeric_cast_testcases.cpp(93): error in "standard_cast_test": exception bad_numeric_cast is expected numeric_cast_testcases.cpp(135): error in "standard_cast_test": exception bad_numeric_cast is expected *** 4 failures detected in test suite "numeric_cast Test" I think the line static_cast<X>(static_cast<Y>(x)) != x; is a tricky code. For X/Y==char/unsigned char,short/unsigned short etc. is always false. The compiler convert it only if the datatypes have not the same size/bytes or are between integers and floating points. sorry for my bad english and code, it's the first time that i ever have published. Peter Bestellen Sie Y! DSL und erhalten Sie die AVM "FritzBox SL" für 0. Sie sparen 119 und bekommen 2 Monate Grundgebührbefreiung. http://de.adsl.yahoo.com

2 1