- Boost - lists.boost.org

Adobe Open Source Library
by Brian Braatz 03 Mar '05

03 Mar '05

I just saw this on Slashdot and thought the boosters might find it interesting: Adobe has apparently open sourced some libraries- I (very brief) quick look shows me: 1- They seem to be heavily using template techniques 2- They have a "concepts Library" -look familiar?: Assignable ConvertibleToBool ConvertibleToFunction ConvertibleToRange DefaultConstructible EqualityComparable LessThanComparable RegularType TransformFunction 3- They have a GUI Library (appears to have a similarity to the GUI discussion on this list awhile back) Anyways- I am just throwing this out there for discussion. SlashDot article: http://slashdot.org/articles/05/03/02/1449240.shtml?tid=152 Adobe Open Source Library http://opensource.adobe.com/

3 2

[Wiki] trouble restoring libraries under construction
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, I was trying to despam the Wiki, which I have done many times, but for some reason got confused (or maybe I am permanently confused). I ended up removing the spam but not restoring the previous content. It should be revision 90, I believe. Jonathan

1 0

[Boost-bugs] [ boost-Bugs-1155556 ] parse_date asserts on empty string
by SourceForge.net 03 Mar '05

03 Mar '05

Bugs item #1155556, was opened at 2005-03-02 19:27 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=1155556&group_… Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeff Garland (az_sw_dude) Summary: parse_date asserts on empty string Initial Comment: the following sample code fails with assert : (Assertion failed: valid_, file c:\dev\externallibs\boost_1_32_0\boost\token_iter ator.hpp, line 57) >>> #include <boost/date_time/posix_time/posix_time.hpp> #include <iostream> using namespace boost::gregorian; int main( int, char** ) { try { date d = from_simple_string( "" ); // never reached std::cout << to_simple_string( d ) << std::endl; } catch( std::exception & ) { // no std::exception caught ! } return 0; } >>> The error seems to be in date_time\date_parsing.hpp, line 119 : for(boost::tokenizer<>::iterator beg=tok.begin(); beg!=tok.end(), pos < spec_str.size(); ++beg, ++pos) {... the comparison "beg!=tok.end()" has no effect because the value of the expression is only determined by "pos < spec_str.size()". Therefore the string iteration goes beyond the end of the string and...assert... The function also fails if the given string is not a complete date, ie: "2004", "2004-Jan" I changed the "," to "&&" and it seems to perform better (though i didn't run the boost regression tests). I also checked the CVS repository to confirm the bug is still there. Have a nice day ! and thanks for this great library, it is really good to develop with it. Here is my email : guillaume.souchet(a)bnpparibas.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1155556&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: ANN: review of FSM library starts
by Augustus Saunders 03 Mar '05

03 Mar '05

I hesitate to call this a review; it's more my reactions looking through the fsm documentation and examples--I have not actually used it yet. I feel like these comments should have been given a long time ago, but I guess I missed all the pre-review discussion. I'm not an expert in this area, but I feel comfortable with the ideas and have fooled around with making my own state machines in the past. My main interest in a library like fsm lies in correctness and simplicity, not performance. Before I delve into answering the "official review questionare," I want to make some overall comments. First, it is obvious to me that this library has a lot of potential. The authors have thought through a lot of issues that I've never considered. My problems mainly lie with the syntax and documentation, and I think problems with the latter stem from the former. I'd like to see some discussion on the matter. Overall, I feel the syntax is too burdensome and the organization of code that I have to write is a hopeless mess (at least, looking at the examples). For simple cases, I really want to see a way of defining a fsm with less line noise and less indirection. I haven't thought through the ramifications, but it just seems to me that some mpl, lambda, and BOOST_TYPEOF loving should make something roughly akin to the following possible: { using namespace boost::fsm; using namespace boost::lambda; // I guess there's no way to avoid declaring // these ahead of time?? class Machine, State1, State2, Event1, Event2; struct S1Data { int i; S1Data() : i(0) {} }; typedef simple_state< Machine, S1Data, BOOST_TYPEOF( cout << constant("Entering State1.") ), BOOST_TYPEOF( cout << constant("Exiting State1.") ), on_event<Event1, BOOST_TYPEOF( _1->i++ ) >, transition<Event1, State2> > State1; // the "data" member of State1 has type S1Data, and is // passed into event handlers struct S2Data { int j; S2Data() : j(0) {} }; typedef simple_state< Machine, S2Data, BOOST_TYPEOF( cout << constant("Entering State2.") ), BOOST_TYPEOF( cout << constant("Exiting State2.") ) > on_event<Event2, BOOST_TYPEOF( _1->j++ )>, transition<Event2, State1> > State2; // the "data" member of State2 has type S2Data, and is // passed into event handlers // It seems that in the propsed fsm library, // state composition is specified bottom up, // and I'm not sure what the motivation is. // We're all used to writing classes top-down. typedef state_machine< State1, State2 > Machine; Machine m; m.initiate(); // process events while (whatever) m.process_event(blah); // I don't quite understand why state_cast is necessary // versus just overloading regular casting. cout << "State1 had Event1 called " << ((State1)m).data.i << " times." << endl; cout << "State2 had Event2 called " << ((State2)m).data.j << " times." << endl; } I'm sure I've messed up some details sine I don't really get why some of the fsm mechanisms are there. Also, I'm ignoring for the moment that member dereferencing is a little uglier with lambda, so _1->i++ would have to be (_1->* &S1Data::i)++. I assume there exists a way to make state-specific data available to a lambda expression in a clean way. I've also ignored sticking in lots of mpl::vector or mpl::lists, as it's my impression that with mpl one can iterate through the template arguments and figure out if they are events or transitions or whatever. So I smushed together the different elements, and presumed for < 10 arguments (or whatever, using PREPROCESSOR lib to configure that) the mpl::vector could be omitted. Finally, even though I've not really tested BOOST_TYPEOF, they use lambda expressions as an example, so I don't think it's entirely out of line of think that it might work. Now, I don't know if this example has really reduced the total number of characters required to be typed, but it is more clear to me. I realize that I've seperated the state data out into a seperate struct; personally, I like that. More importantly to me, I can look at those typedefs and reasonably guess what's being defined. If you made FSM_ENTER and FSM_EXIT macros to alias BOOST_TYPEOF you would make it clear what those entries were for. In general, you don't have to keep refering back and forth to the reference manual to figure out what each entry is. Looking at the examples in the tutorial just made my head spin, especially trying to figure out how states and machines get tied together (this is still unclear to me). This kind of "inline" code would be great for lots of cases where you just want to increment/decrement some counter or push/pop some variable. Maybe I'm hoping for too much magic, but I feel that at least little magic or secret sauce is needed here. * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? All the other reviewers have said nice things about the documentation, but I had a lot of trouble with the tutorial. As already mentioned by others, totally targetted at the wrong people. In general, I would drop all mention of UML except for some appendix somewhere (and the reference manual too). "Getting Started" and "Target Audience" should be in a differenct document, and "How to read this tutorial" should be removed. Then, before you get into the C++ code for "Hello, World!", you should work through "Hello, World!" and maybe "StopWatch" using pseudo-code. Even if you can work out some magic like I hope for, I think you need to map out the basic process with pseudo-code, like this: // Hello World example // First, we have to declare all of our states // and events ahead of time. This is because // all states can transition to each other, // so you can't necessarily define them in order. class mystate1, mystate2, event1, event2, etc; // Next, we're going to define some states // for our machine. Each state definition // indicates what other states it transitions // to on each input, buried in "bunch_of_stuff" typedef simple_state< bunch_of_stuff > mystate; typedef simple_state< bunch_of_stuff > mystate2; // etc // Then, we're going define a machine with // states. The first listed state is the default typdef state_machine<mystate, mystate2> Machine; // etc, in this style In general, all of your "remarks" and "comments" need to be in the code! I think the example state machines are basically OK, but I think that it is absolutely essential that you include a simple example that is alphabet-based. In fact, some helper functions for alphabet-based languages are probably a good idea, just to make the tutorial easier. In particular, you should be able to create letters-as-events, and dispatch them easily. The switch statement for dispatch in the Camera example is scandalous ;) The reference manual seems ok, although I didn't really use it. The rationale tended to feel unconvincing, although I'm not well informed on the issues. * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? I'm confused about why entering/exiting states causes construction / destruction. It's taken as a given, but I would tend to assume that state-local-storage is maintained throughout unless I explicitly reset it. I'm also surprised by the lack of "accept" states. Maybe it's not universal, but my theory certainly had them, and it's just disconcerting for them not to be there. * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? boost::fsm is good, IMO. Don't know about seperating libraries. * What is your evaluation of the implementation? Are there parts of code too obscure or duplicating exiting Boost functionality? Can something be factored out to standalone library or among general utilities? Didn't look. * Are there performance bottlenecks? Does the library design fit requirements of real-time systems? How is it useable for embedded systems? Is the documentation clear on performance tradeoffs? No comment. * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? Tremendous potential. I can't compare directly to other FSM libraries/tools, but just like spirit, eliminating the need for extra tools is a great benefit. * Did you try to use the library? With what compiler? Did you have any problems? Do you have tips for better support of older compilers? What are possible portability problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Looked through docs and examples, thought carefully about what I wanted, and poked around to see what might be feasible. Many hours. * Are you knowledgeable about the problem domain? Not an expert, not completely ignorant. And finally, every reviewer should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I think that boost::fsm will benefit greatly from some further consideration. The Serialization library took two tries and was much improved, to good effect. I can be accused of hoping for too much "magic" syntax, but it'll take a lot of convincing that the current way is best. I'm not unreasonable, but I haven't seen any discussion on it, and Spirit, Lambda, Serialization, and others given me high expectations for usability. And lastly, thanks to all involved in bringing us boost::fsm. Despite my critique, this is first-rate work. Thanks- Augustus __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/

4 5

Re: Re: multi_index_container
by Wusel 03 Mar '05

03 Mar '05

Hi Joaquín M López Muñoz, thank you for your quick answer! I appreciate that multi_index_container exist and I can use it. In my opinion this library is very useful and facilitate many programs. >> 44 //version B: DOES compile >> 45 typedef index<employee_set,id >::type employee_set_by_id; >> 46 typedef index<employee_set,age>::type employee_set_by_age; > > OK, fine. > >> 48 //remove the name index (lines 31, 32) for following versions >> 49 >> 50 //version C: DOES compile >> 51 typedef index<employee_set,id >::type employee_set_by_id;; > > OK, too. > >> 52 >> 53 //version D: does NOT compile >> 54 //causes >> ...\include\boost-1_32\boost\mpl\vector\aux_\preprocessed\no_ctps\vector10.hpp(398) >> : >> 55 // error C2039: 'item3' : is not a member of >> 'boost::mpl::vector2<T0,T1>' >> 56 typedef index<employee_set,age>::type employee_set_by_age; > > !! Here I'm missing somethig... Isn't version D exactly the same > as version B, which does work? Exact this I wanted point out. Version D differs from version B in removing two lines 31, 32 only (i.e. the name index). Version C is nearly the same, too. Nevertheless there is a difference when compiling. best regards Volker Vieth

2 3

[mpl]RFE: unpack_apply
by Larry Evans 02 Mar '05

02 Mar '05

Would it be possible to add: template<typename Application> struct unpack_apply { ... }; such that: is_same < unpack_apply<f<a0,a2,...,an> >::type , vector<a0,a2,...,an> > to mpl? Maybe a better name would be get_args, but since it's so closely related to unpack_args, I thought maybe unpack_apply could be considered OK.

1 1

review of FSM nears to the end - any more reviews?
by Pavel Vozenilek 02 Mar '05

02 Mar '05

Review period of FSM library (http://boost-sandbox.sf.net/fsm.zip) nears to its end in few days. Does anyone need to extend review period? Review can be surely posted even after end of official period - I'll reserve some time for such possibility. /Pavel

8 11

Re: [boost] Re: Boost.Hash + Boost.Unordered reviews
by JOAQUIN LOPEZ MU?Z 02 Mar '05

02 Mar '05

----- Mensaje original ----- De: Daniel James <daniel(a)calamity.org.uk> Fecha: Miércoles, Marzo 2, 2005 11:49 pm Asunto: [boost] Re: Boost.Hash + Boost.Unordered reviews > Joaquín Mª López Muñoz wrote: > > This issue seems to have cooled down. Has there been > > some off-list progress, should we agree what to do here? > > No, I've been taking a small break from it. There seem to be no > real > objections to the original plan (fast-tracking Boost.Hash and > placing > Boost.Unordered in the queue), so it looks like that's the way to go. > I'm happy to know you're still on this. Looking fwd to participating in both reviews. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Iostreams Compile Issue with boost/algorithm/string.hpp was[RE: Compile problem using IoStreams from CVS inside boostv1.32 (VC71)]
by Brian Braatz 02 Mar '05

02 Mar '05

Just for giggles, I pointed my unit test code to the boost I got from CVS. Interestingly enough, it compiled with the #include <boost/algorithm/string.hpp> (but it complained about the unit test code- I am guessing there is a broken form in cvs? Or maybe I don't have something setup- when I commented out my test suite definitions- I WAS able to compile the file though) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Brian Braatz > Sent: Wednesday, March 02, 2005 2:03 PM > To: boost(a)lists.boost.org > Subject: [boost] Iostreams Compile Issue with boost/algorithm/string.hpp > was[RE: Compile problem using IoStreams from CVS inside boostv1.32 (VC71)] > > I narrowed this down a bit more- > > In my code which uses filtered_stream if I have the following headers: > > #include <boost/iostreams/concepts.hpp> > #include <boost/iostreams/operations.hpp> > #include <boost/iostreams/filtering_stream.hpp> > #include <boost/iostreams/device/file.hpp> > // #include <boost/algorithm/string.hpp> > > It compiles- but when I uncomment the #include > <boost/algorithm/string.hpp> I get the error below > > > > -----Original Message----- > > From: Brian Braatz > > Sent: Wednesday, March 02, 2005 1:34 PM > > To: 'boost(a)lists.boost.org' > > Subject: Compile problem using IoStreams from CVS inside boost v1.32 > > (VC71) > > > > I am using VC7.1 (and will also be using VC70 for this code) > > > > What I did- > > > > Executed the following from a cmd prompt: > > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login > > cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost > checkout > > boost > > cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout > > > > went into boost\iostreams and boost\libs\iostreams- copied both into > temp > > area- > > > > Deleted the CVS folders > > > > Copied the files into the boost 1.32 dir in my company's internal CVS > > server (we have the boost files under revision control to control > which > > version of which file we are using to build) > > > > Initially I had to change the files to from namespace io to iostreams. > Got > > through those compile errors. And Now I have this one: > > > > > > boost\algorithm\string\iterator_range.hpp(288) : error C2874: using- > > declaration causes a multiple declaration of > > 'boost::algorithm::iterator_range' > > > > \boost\algorithm\string\iterator_range.hpp(204) : see declaration of > > 'boost::algorithm::iterator_range' > > > > I am digging into this but thought I would throw this out to see if > any > > one is aware of the issue- > > > > These errors point to the end of iterator_range.hpp (pointing at the > using > > clause) > > > > Here is a snippet from that file: > > > > template< typename SeqT, typename IteratorT, typename FuncT > > > inline SeqT transform_iterator_range( const > > iterator_range<IteratorT>& Range, FuncT Func ) > > { > > SeqT Seq; > > std::transform( Range.begin(), Range.end(), > > std::back_inserter(Seq), Func ); > > return Seq; > > } > > > > } // namespace algorithm > > > > // pull names to the namespace boost > > using algorithm::iterator_range; > > using algorithm::make_iterator_range; > > using algorithm::copy_iterator_range; > > using algorithm::transform_iterator_range; > > > > } // namespace boost > > > > > > > > > > > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost.Hash + Boost.Unordered reviews
by Joaquín Mª López Muñoz 02 Mar '05

02 Mar '05

This issue seems to have cooled down. Has there been some off-list progress, should we agree what to do here? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2