- Boost - lists.boost.org

More reviewers wanted: FSM review extended until Mar 6th
by Pavel Vozenilek 04 Mar '05

04 Mar '05

Review of Boost.FSM library was extended by one week, until March 6th. Reviews, even short opinions on this library are much welcomed. I'll encourage public by quoting Darryl Green: ------ quote ----------- I have seen substantial reductions in code complexity arise out of using the fsm libary in a refactoring of some existing code. The result is also much easier to modify/maintain. This last point is particularly important if the fsm is not well specified to start with and/or may need to be modified in reaction to changes in requirements. Using boost fsm an iterative/exploratory design approach works fine. In many ways this is less painful than if there were a code generator. ------- end quote ------ So now is your chance to recommend this tool into Boost (or pin-point problems or suggest alternatives). /Pavel ========================================== Original review announcement: Review of Finite State Machine library written by Andreas Huber starts today, February 21. The library can be found at: http://boost-sandbox.sf.net/fsm.zip (781 kB). FSM is feature rich library to design finite state machines without need for external generator. It is accompanied by extensive documentation. Here are some questions you might want to answer in your review: * What is your evaluation of the documentation? How easy (or hard) it is to understand library features? What can be improved? * What is your evaluation of the design? What features are supported better by alternative FSMs? What could be added (or removed) from the library? * The library documentation contains few not yet solved issues (name, separating the library into two parts, exception handling). What is you opinion here? * 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? * 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? * What is your evaluation of the potential usefulness of the library? Can you compare this FSM to other implementations? * 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? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? 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. Pavel Vozenilek FSM review manager

5 5

Singleton is documented!
by Jason Hise 04 Mar '05

04 Mar '05

The singleton library is finally documented! A complete tutorial in using the library along with an extensive reference section are provided. A tutorial on extending the library is forth-coming. The new zip is available in the <a href="http://boost-sandbox.sourceforge.net/vault/">sandbox</a> under the singleton folder, and should be extracted into the boost root directory. As always, suggestions are welcome. -Jason

6 17

Looking for some WINDOWS help
by Jody Hagins 04 Mar '05

04 Mar '05

Whenever I get a spare moment, I try to get my typeid/type_info tests working on windows (I am convinced that if I had started programming under that environment, I would have chosen a different line of work). Right now I am struggling a bit with the DLL library that is part of testing type_info. Everything works fine, except when it doesn't ;-> The documentation of LoadLibrary() says it returns NULL on failure. However, I can feed it some files (like a valid .LIB that is not a DLL) and before LoadLibrary() returns, it displays a dialog box saying "Bad Image." I guess this could be an exception that BCB is intercepting and turning into a dialog box, but the docs say nothing about an exception. Also, I look on google, and find that people have similar problems from within Java (though I could not find any solutions). How do I prevent that from happening? Thanks in advance!

2 1

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Peter Dimov <pdimov(a)mmltd.net> Fecha: Viernes, Marzo 4, 2005 0:32 am Asunto: Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Jonathan Turkanis wrote: > > Hi, > > > > <boost/shared_ptr.hpp> contains the following in the public section > > of the class definition (reformatted): > > > > // Tasteless as this may seem, making all members public > > // allows member templates to work in the absence of member > > // template friends. (Matthew Langston) > > > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > > > private: > > > > template<class Y> friend class shared_ptr; > > template<class Y> friend class weak_ptr; > > > > > > #endif > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > > > This has become a pretty common technique, I believe. I > certainly use > > it a lot, at any rate. > > > > I'd like to suggest two macros which would allow code like the above > > to be simplified as follows: > > > > BOOST_PRIVATE: > > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > > > T * px; // contained pointer > > detail::shared_count pn; // reference counter > > This doesn't look any better to me than the original, sorry. ;-) Well, I think there are situations were it'd improve readability: Example 1: previous section was not public #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #else public: #endif Example 2: derivation class Derived: #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private else public #endif Base { ... }; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[mpl-docs] portability trap
by Tobias Schwinger 04 Mar '05

04 Mar '05

Hi, This code: #include <boost/mpl/vector.hpp> #include <boost/mpl/pop_front.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> using namespace boost; // Doc says: pop_front returns a vector typedef mpl::pop_front< mpl::vector<bool,char,int> >::type v; // Doc says: vectors have a type member equal to itself BOOST_MPL_ASSERT(( mpl::equal< v, v::type > )); fails to compile with GCC ( v::type is mpl::vector3<bool,char,int> ) and compiles fine with other compilers. Examples for false conclusions that could be easily drawn from the current documentation: "Oh great - I do not need mpl::identity when using v with mpl::eval_if" "Let's inherit from 'v::type' so I can save the '::type' later" "::type always gives the numbered form of my current sequence so I can use it with partial specialization" I got trapped by this in two different places (and I still hope not to be surpassingly stupid ;-). Shouldn't this behaviour be documented in some way ? Regards, Tobias

2 2

Re: [boost] Looking for some WINDOWS help
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

----- Mensaje original ----- De: Jody Hagins <jody-boost-011304(a)atdesk.com> Fecha: Viernes, Marzo 4, 2005 0:37 am Asunto: [boost] Looking for some WINDOWS help > > Whenever I get a spare moment, I try to get my typeid/type_info tests > working on windows (I am convinced that if I had started programming > under that environment, I would have chosen a different line of > work). > Right now I am struggling a bit with the DLL library that is part of > testing type_info. Everything works fine, except when it doesn't > ;-> > > The documentation of LoadLibrary() says it returns NULL on > failure. > However, I can feed it some files (like a valid .LIB that is not a > DLL)and before LoadLibrary() returns, it displays a dialog box > saying "Bad > Image." I guess this could be an exception that BCB is > intercepting and > turning into a dialog box, but the docs say nothing about an > exception. > Also, I look on google, and find that people have similar problems > fromwithin Java (though I could not find any solutions). > > How do I prevent that from happening? > With SetErrorMode, I think. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 04 Mar '05

04 Mar '05

Hi Jonathan! ----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Viernes, Marzo 4, 2005 0:08 am Asunto: [boost] Re: [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > JOAQUIN LOPEZ MU?Z wrote: [...] > > The macros I'm using are: > > > BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS > > BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS > > These would be okay with me. But sometimes I use a macro for > specifying the type > of derivation, and > > struct derived_class > : BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS base_class > { }; > > seems a bit long. Yep it is long, but BOOST_PRIVATE covers too much semantic scape: what if in the future a similar workaround is needed to make up for another, unrelated defficiency? This is not hypothetical, in fact I'm already using BOOST_MULTI_INDEX_PRIVATE_IF_USING_DECL_FOR_TEMPL_FUNCTIONS that does the same thing (turning private into public) in some compilers that do not support in-class using declarations for template functions. Admittedly, it'd be nicer if we can come up with a shorter, yet descriptive name. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: OT: Jonathan, weren't you going to promote a scopeguard impl to boost/detail? I'm waiting for that so that I can reduce my own codebase :)

2 1

[congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

[I'm reposting this because I misspelled 'config' in the subject line] Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 1

[config] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE [repost][repost]
by Jonathan Turkanis 03 Mar '05

03 Mar '05

Hi, <boost/shared_ptr.hpp> contains the following in the public section of the class definition (reformatted): // Tasteless as this may seem, making all members public // allows member templates to work in the absence of member // template friends. (Matthew Langston) #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS private: template<class Y> friend class shared_ptr; template<class Y> friend class weak_ptr; #endif T * px; // contained pointer detail::shared_count pn; // reference counter This has become a pretty common technique, I believe. I certainly use it a lot, at any rate. I'd like to suggest two macros which would allow code like the above to be simplified as follows: BOOST_PRIVATE: BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) T * px; // contained pointer detail::shared_count pn; // reference counter Here BOOST_PRIVATE would expand to "private" for compilers that support template friends and to "public" otherwise; BOOST_BEFRIEND_TEMPLATE would expand to a template friend declaration where supported, and to nothing otherwise. It might be desirable to have two macros BOOST_BEFRIEND_TEMPLATE_CLASS and BOOST_BEFRIEND_TEMPLATE_STRUCT to avoid compiler warnings. Jonathan

1 0

Re: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE
by JOAQUIN LOPEZ MU?Z 03 Mar '05

03 Mar '05

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Marzo 3, 2005 9:49 pm Asunto: [boost] [congif] BOOST_BEFRIEND_TEMPLATE, BOOST_PRIVATE > Hi, > > <boost/shared_ptr.hpp> contains the following in the public > section of the class > definition (reformatted): > > // Tasteless as this may seem, making all members public > // allows member templates to work in the absence of member > // template friends. (Matthew Langston) > > #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS > > private: > > template<class Y> friend class shared_ptr; > template<class Y> friend class weak_ptr; > > > #endif > > T * px; // contained pointer > detail::shared_count pn; // reference counter > > This has become a pretty common technique, I believe. I certainly > use it a lot, > at any rate. FWIW, I've also been forced to use a similar workaround. > > I'd like to suggest two macros which would allow code like the > above to be > simplified as follows: > > BOOST_PRIVATE: > BOOST_BEFRIEND_TEMPLATE(shared_ptr, Y, 1) > BOOST_BEFRIEND_TEMPLATE(weak_ptr, Y, 1) > > T * px; // contained pointer > detail::shared_count pn; // reference counter > BOOST_PRIVATE seems a little to uninformative a name to me. The macros I'm using are: BOOST_PRIVATE_IF_MEMBER_TEMPLATE_FRIENDS BOOST_PROTECTED_IF_MEMBER_TEMPLATE_FRIENDS (well, I'm using lib-specific variations of these names, but you get the idea.) As for your proposal, I like it: there are at least three libraries that would benefit from it. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1