December 2009 - Boost - lists.preview.boost.org

Interprocess message queue implementation
by Alex Miller 22 Dec '09

22 Dec '09

Hello, I have been looking over the implementation of Boost.Interprocess's message queues, and have become slightly confused as to the reasoning for how it was designed. Assuming my understanding is correct, it allocates a piece of shared memory, and then constructs a message queue within that piece of memory. Is there a reason that this was done in favor over implementing it by using SystemV's message queues ( the one located in <sys/msg.h> )? Thanks, Alex Miller

1 0

Re: [boost] [date_time] quarters as new durations?
by pete＠pcbartlett.com 22 Dec '09

22 Dec '09

On Tue 22/12/09 13:27 , "Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: > Jeff Garland wrote: > > Stewart, Robert wrote: > > > Thomas Lemm wrote: > > >> I am happily using the boost date_time library and I plan to > > >> extend it towards including quarters as new (gregorian) date > > >> durations, just the way months are included already > > >> (excluding parsing of quarters) > > > > > > Why excluding parsing? That would imply only partial > > > support relative to other durations, right? > > > > > Well, so quarters turns out to be like months as far as > > durations go -- that is, it's mathematical like days and > > weeks. So the big drawback you face is dealing with the > > associated "fuzzy math". For example, what's the result > > of > > > > date("2008-Feb-28") + quarters(1) = ? > > date("2008-Feb-27") + quarters(1) = ? > > > > Month durations play some games to handle this problem (see > > docs for details) which quarters could adopt. But if you > > adopt the month rules then I don't thing you buy much more > > than simply writing > > > > const months quarters = months(3); > That's an excellent point. I don't think the fuzzy math approach is > appropriate for quarters because they have a precise definition: 1/4 > of a year. Months are less precise, though 365 / 4 is not a whole > number, of course. Possibly opening a can of worms here, but a quarter in my line of work is invariably three months. If your mileage varies, then there could be a problem in providing a fully meaningful quarter duration type if people think it means different things. > There is probably still a need to use some fuzzy math in order to > determine the calendar date for quarter boundaries. Quarters are > usually associated with a fiscal year and there are different > definitions of those, so you probably need to add fiscal year support > and make quarters a derived concept. > > There's also an argument against adding quarters as a > > duration. I have an app somewhere in which I have quarter > > defined as a date_period so I could write: > > > > date_period q = quarter(2009, 1); > > > > To me at least this seems like the more likely application. > I agree. I didn't consider the ramifications of duration versus > period. The issue routinely occurs with months already though. Month durations and date_periods spanning a specific month already have to work closely with each other: date_period month_containing(date d) { return date_period(date(d.year(),d.month(),1) , months(1) ); } so it may not be a big issue.

2 1

[date_time] quarters as new durations?
by Thomas Lemm 22 Dec '09

22 Dec '09

Hi, I am happily using the boost date_time library and I plan to extend it towards including quarters as new (gregorian) date durations, just the way months are included already (excluding parsing of quarters) Now my question: What are the chances that his change might make it into the boost date_time library? Is there some interest in this feature, if so I would provide a patch to update source and documentation to include the quarters as a new duration. Please let me know, Kind regards Thomas Lemm

3 3

[ANN] CLI 1.1.0 released
by Boris Kolpackov 21 Dec '09

21 Dec '09

Hi, Seeing that I've got a lot of useful feedback for the initial release, I am pleased to announce the availability of CLI 1.1.0. CLI is an open-source (MIT license), cross-platform command line interface compiler for C++. It allows you to specify the options that your program supports, their types, default values, and documentation. This specification can then be automatically translated to C++ classes that implement parsing of the command line arguments and provide a convenient and type-safe interface for accessing the extracted data. The automatic usage and documentation generation is by far the biggest new feature in this release. The usage information is formatted during compilation and the documentation can be generated in the HTML and man page formats. For an example of the HTML output, see the documentation for the CLI compiler itself (you may also want to check the cli.1 man page and the usage information printed by the compiler): http://www.codesynthesis.com/projects/cli/doc/cli.xhtml Other new features in this release: * Optional generation of modifiers in addition to accessors. * Support for erasing the parsed elements from the argv array. * Support for custom argument sources via an abstract scanner interface. * Support for reading command line arguments from the argv array as well as files specified with command line options. For a more detailed list of new features in this release see: http://www.codesynthesis.com/pipermail/cli-users/2009-December/000001.html More information, documentation, and source code distributions are available from the project's web page: http://www.codesynthesis.com/projects/cli/ Enjoy, Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli

5 7

[serialization] optional serialization and non-default-constructables
by Felipe Magno de Almeida 21 Dec '09

21 Dec '09

Hello, serialization for boost.optional calls load_construct_data but doesn't call save_construct_data. Which causes serialization for non-default-constructables to break. Regards, -- Felipe Magno de Almeida

1 1

Re: [boost] [msm] Review
by Christophe Henry 21 Dec '09

21 Dec '09

>> You brought 2 reasons for this impossibility: >> 1. Automatic entry/exit. You answer that "With separate FSMs you'd >> have to manage this yourself". >> 2. Automatic event dispatch. You answer that "Again, with separate >> FSMs you'd have to do that yourself (dispatch to first FSM and if that >> didn't consume the event, dispatch to second FSM and so on)." > > It appears that you should read the 2005 post a lot more carefully, > especially the quoted context. The remarks you quote above have *nothing* to > do with the impossibility I claimed. No, I won't spend "a lot more" time trying to decipher the supposedly hidden meaning of your post and invest the time more wisely by making MSM more useful. The link I added seems quite clear to me and anyone interested can make himself his own opinion by opening it. You did not bother bringing an argumentation disproving my claim, so I will simply keep it. As you also didn't address the more important technical part (multiple TU) of my answer, I will consider it accepted.

3 2

What about "Maybe" ?
by Arnaud Masserann 21 Dec '09

21 Dec '09

Hi, Is there any interest for a "Maybe" utility class, like the one in Haskell ? For those who don't know about Maybe, here is the Haskell ref : http://www.haskell.org/ghc/docs/6.10.4/html/libraries/base/Prelude.html#t%3… And a code snippet showing its use : http://pastebin.com/m3a590d6e Arnaud

5 7

How to detect if f() returns void or not?
by Frédéric Bron 21 Dec '09

21 Dec '09

I would like to detect if the return type of a function is void or not within C++03 standard? I need that to implement new type traits to detect if types can be compared and to detect for example operator< returning void. The following code compiles only with c++0x standard and keyword decltype but not with c++03 standard and BOOST_TYPEOF. Frédéric #include <iostream> #include <boost/type_traits/is_void.hpp> #include <boost/typeof/typeof.hpp> void returns_void(); int returns_int(); int main() { std::cout<<std::boolalpha; // std::cout<<boost::is_void< BOOST_TYPEOF(returns_void()) >::value<<'\n'; // std::cout<<boost::is_void< BOOST_TYPEOF(returns_int()) >::value<<'\n'; std::cout<<boost::is_void< decltype(returns_void()) >::value<<'\n'; std::cout<<boost::is_void< decltype(returns_int()) >::value<<'\n'; return 0; }

17 36

[bind] Function call operator is a template?!
by Andy Venikov 20 Dec '09

20 Dec '09

All this time I've been using bind quite happily without really going into the details of its implementation. Recently, however, I had to discover the hard way that the function call operator that is produced as part of the bind() return is a template! I guess most of the time one would not care if it's a template or not as long as you can call the resulting functor with the right signature. It does, however, make a difference. The difference can be seen when calling the resulting functor with wrong arguments. The error detection happens earlier in the case when functor's operator() is a concrete function as opposed to a template. And that plays bad tricks with SFINAE. You see, recently I was faced with a challenge where I had to check at compile time whether calling a template argument with a specific signature is a well-formed expression. Something similar to Eric Niebler's "can_be_called<>": http://www.boost.org/doc/libs/1_41_0/doc/html/proto/appendices.html#boost_p… Well, this technique won't work with bind(), because the template member operator() will happily accept ANY argument during SFINAE and the error detection will happen much later, when you actually try to call the functor. I'm not going to debate whether it's right or wrong, but I'm still curious - why did it have to be a template? When bind() is called it already has all the information about the function's signature so it could construct a concrete member operator() without resorting to templates. For example bind(main) could easily determine that the signature is <int (int, char * [])> and could create a functor with a single "int operator()(int, char *[])", instead of a template. It's not like it's lambdas, where when you say _1 + _2 you literally mean parameters of any type. Thanks, Andy.

4 5

getting errors whti boost.
by ch.asad＠gmail.com 19 Dec '09

19 Dec '09

Hi I am getting errors when i ininclude boost header file in my project. my progrm is running fine. I want ot use boost asio in my program. But when just write "include<boost/asio>" or any other header fie of boost in my program i am getting below errors. It just started all of a suddden before that it was working fine. I am tring it with Eclpse and MinGW.Please also guide me how t setup boost for Visual C++.net 9.0. I have tried boost_1_38_0 and boost_1_41_0 but same problem. i am getting the following errors on eclipse. Thanks in advance, -Asad Description Resource Path Location Type (Errors 5) D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 206 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 211 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_generic_category()' test project 212 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_system_category()' test project 205 C/C++ Problem D:/boost/boost_1_38_0/boost/system/error_code.hpp undefined reference to `boost::system::get_system_category()' test project 213 C/C++ Problem (Warnings 9) Description Resource Path Location Type D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). test project 39 C/C++ Problem D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. test project 38 C/C++ Problem D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp #warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. test project 37 C/C++ Problem D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp left shift count >= width of type test project 101 C/C++ Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2\backward). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\include\c++\4.3.2-dw2\i686-pc-mingw32). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\lib\gcc\i686-pc-mingw32\4.3.2-dw2\include-fixed). test project pathentry Path Entry Problem Invalid project path: Include path not found (C:\MinGW\lib\gcc\i686-pc-mingw32\4.3.2-dw2\include). test project pathentry Path Entry Problem And on the console it shows like : **** Internal Builder is used for build **** g++ -ID:\boost\boost_1_38_0 -O0 -g3 -Wall -c -fmessage-length=0 -osrc\test project.o ..\src\test project.cpp In file included from D:/boost/boost_1_38_0/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from D:/boost/boost_1_38_0/boost/asio/io_service.hpp:37, from D:/boost/boost_1_38_0/boost/asio/basic_io_object.hpp:20, from D:/boost/boost_1_38_0/boost/asio/basic_socket.hpp:24, from D:/boost/boost_1_38_0/boost/asio/basic_datagram_socket.hpp:25, from D:/boost/boost_1_38_0/boost/asio.hpp:20, from ..\src\test project.cpp:12: D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:37:5: warning: #warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:38:5: warning: #warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line. D:/boost/boost_1_38_0/boost/asio/detail/socket_types.hpp:39:5: warning: #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). In file included from D:/boost/boost_1_38_0/boost/date_time/microsec_time_clock.hpp:23, from D:/boost/boost_1_38_0/boost/date_time/posix_time/posix_time_types.hpp:11, from D:/boost/boost_1_38_0/boost/asio/detail/select_reactor.hpp:25, from D:/boost/boost_1_38_0/boost/asio/impl/io_service.ipp:27, from D:/boost/boost_1_38_0/boost/asio/io_service.hpp:550, from D:/boost/boost_1_38_0/boost/asio/basic_io_object.hpp:20, from D:/boost/boost_1_38_0/boost/asio/basic_socket.hpp:24, from D:/boost/boost_1_38_0/boost/asio/basic_datagram_socket.hpp:25, from D:/boost/boost_1_38_0/boost/asio.hpp:20, from ..\src\test project.cpp:12: D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp: In function `uint64_t boost::date_time::winapi::file_time_to_microseconds(const FileTimeT&)': D:/boost/boost_1_38_0/boost/date_time/filetime_functions.hpp:101: warning: left shift count >= width of type g++ -LC:\boost_1_38_0\libs -LC:\STLport-5.2.0\build\lib -otestproject.exe src\test project.o src\test project.o: In function `Z41__static_initialization_and_destruction_0ii': D:/boost/boost_1_38_0/boost/system/error_code.hpp:205: undefined reference to `boost::system::get_system_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:206: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:211: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:212: undefined reference to `boost::system::get_generic_category()' D:/boost/boost_1_38_0/boost/system/error_code.hpp:213: undefined reference to `boost::system::get_system_category()' src\test project.o: In function `ZN5boost6detail17sp_counted_impl_pINS_4asio6detail12winsock_initILi2ELi0EE7do_initEE11get_deleterERKSt9type_info': D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio6detail12winsock_initILi2ELi0EE7do_initD1Ev[boost::asio::detail::winsock_init<2, 0>::do_init::~do_init()]+0x7): undefined reference to `WSACleanup@0' D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio6detail12winsock_initILi2ELi0EE7do_initC1Ev[boost::asio::detail::winsock_init<2, 0>::do_init::do_init()]+0x1f): undefined reference to `WSAStartup@8' D:/boost/boost_1_38_0/boost/detail/sp_counted_impl.hpp:(.text$_ZN5boost4asio5error19get_system_categoryEv[boost::asio::error::get_system_category()]+0x7): undefined reference to `boost::system::get_system_category()' collect2: ld returned 1 exit status Build error occurred, build is stopped Time consumed: 4886 ms. -- View this message in context: http://old.nabble.com/getting-errors-whti-boost.-tp26856283p26856283.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Re: [boost] [msm] Review
by Christophe Henry 18 Dec '09

18 Dec '09

>> Now it's proven that the concepts of the MPL book were right, that it >> was indeed possible to implement at least as much as statechart with >> metaprogramming techniques. >> That this wasn't evident, as shown here >> (http://lists.boost.org/Archives/boost/2005/03/81853.php) > >For the record, back in 2005 I only expressed the opinion that it's not >possible to implement a purely meta-programming-based FSM framework that >supports both multi-TU machines and orthogonal regions. This should be >obvious from the context quoted in the linked message. I'm happy that you offer to clarify your thoughts because I'm afraid it isn't that obvious to me. You brought 2 reasons for this impossibility: 1. Automatic entry/exit. You answer that "With separate FSMs you'd have to manage this yourself". 2. Automatic event dispatch. You answer that "Again, with separate FSMs you'd have to do that yourself (dispatch to first FSM and if that didn't consume the event, dispatch to second FSM and so on)." Your point was that these 2 cases would have to be managed manually by the user and I fail to see what this has to do with multiple-TUs. Could you please explain this as it still seems unclear to me? Your answer was not about compile-time or recompiling if the structure of a region or separate FSM was changed, which would have been another issue and I would perfectly understand and accept this argument. What I understood from your post is that a full-metaprogramming fsm would not manage these 2 points because of some statechart-specific multiple-TU considerations, and I'd be grateful if you could explain them to me. >IIUC then MSM does not support multi-TU FSMs and you have so far not >expressed any plans to support them, right? I fail to see the difference with Statechart except on the amount of metaprogramming done. Please help me on that one, if I changed in Statechart the reactions typedef in the submachine and thus the submachine header, it would be, from a recompiling perspective, the same result as a full-metaprogramming fsm, right? If this really only is a difference in compile-time, I think this has already been discussed. To multiple TUs with MSM: An application is made of a fsm structure and lots more of user code. This user code can well be in another TU. The metaprogramming in the top-level fsm needs the header of a sub-fsm in order to let the compiler do its job, which is probably also what Statechart does or am I missing something? Reading again the explanation in Statechart's doc (http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tutorial.html#Spre…) I found in Camera.cpp: #include "Shooting.hpp" Which increases my confusion. It seems that Statechart's top-level fsm also needs the submachine header, which seems to make the multiple-TU point moot. Recompiling is another issue, which you didn't mention at that time (though it would have been a valid one), so please allow me to discuss it already now as it's likely that you'll bring this one next. By moving your submachines' application code into different TUs, you'll gain some compile-time if the submachine actions or application code also would cause long compile-times. You'll also gain that a change in a sub-fsm will not cause all to recompile but only the TUs of this fsm and the top-level one. The fact that I put all my submachines into one header doesn't force you to do the same. So yes, you probably can't spread the library metaprogramming work around different TUs, but you can full well spread the application work. Depending of how much this is, it can reduce your compile-time or be not visible. Again, what is concretely the difference with Statechart? Christophe

2 1

boost_1_40_0/boost/lambda/if.hpp && merging different return types
by Peter Foelsche 18 Dec '09

18 Dec '09

Am I doing something wrong, or is this patch really necessary? I'm using if_then_else_return() and the return types are different. I'm overloading return_type_2<other_action<ifthenelsereturn_action>, A, B> to let the compiler deduce the correct return type. Peter diff -w -c ./if.hpp /users/pfoelsch/boost_1_40_0/boost/lambda/if.hpp *** ./if.hpp Sat Jun 28 06:57:20 2008 --- /users/pfoelsch/boost_1_40_0/boost/lambda/if.hpp Tue Dec 15 15:19:50 2009 *************** *** 310,318 **** template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return (detail::select(boost::tuples::get<0>(args), CALL_ACTUAL_ARGS)) ? ! detail::select(boost::tuples::get<1>(args), CALL_ACTUAL_ARGS) : ! detail::select(boost::tuples::get<2>(args), CALL_ACTUAL_ARGS); } }; --- 310,318 ---- template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return (detail::select(boost::tuples::get<0>(args), CALL_ACTUAL_ARGS)) ? ! RET(detail::select(boost::tuples::get<1>(args), CALL_ACTUAL_ARGS)) : ! RET(detail::select(boost::tuples::get<2>(args), CALL_ACTUAL_ARGS)); } };

1 1

[fiber] version 03.1 docu update (incl. html)
by Oliver Kowalke 18 Dec '09

18 Dec '09

version 0.3.1 has an updated documentation - html pages are added to the archive regards, Oliver

1 0

iPhone mangled symbol size explosion in release
by Michael Marcin 18 Dec '09

18 Dec '09

We're currently working to ship an iPhone application that makes heavy use of Boost. The compiled executable is absurdly large, partly to third party libraries, partly to our own insufficent coding practices, but strikingly it seems that (from looking at the executable in a hex editor) around 4MB of the 9.5MB app size is mangled boost function names. We are statically linking against the libraries in Boost we are using. Here are some examples: __ZN5boost13serialization9singletonIN S_7archive6detail11oserializerINS2_12 xml_oarchiveEN6newton18Vector3InitializerEEEE12get_instanceEv __ZNK5boost6spirit8sequenceINS1_INS1_ INS0_6strlitIPKwEENS0_4ruleINS0_7scan nerIN9__gnu_cxx17__normal_iteratorIPc SsEENS0_16scanner_policiesINS0_16iter ation_policyENS0_12match_policyENS0_1 3action_policyEEEEENS0_5nil_tESI_EEEE NS0_5chlitIwEEEENS0_6actionISJ_NS_7ar chive3xml11assign_implISsEEEEE5parseI SH_EENS0_13parser_resultISU_T_E4typeERKSX_ AFAIK All application functions should have been hard-linked since we're statically linking and thus not require any type of named reference. Am I perhaps missing or misusing a Boost configuration setting or compiler flag? Thanks, Michael Marcin

2 2

Failed to upgrade to Boost 1.39.0 (from 1.34.0)
by gaofg 17 Dec '09

17 Dec '09

Hi, In past years, we have been used boost 1.34.0 in our projects, and it works fine. Now days, we want to update the boost to 1.39.0, but when we change the include directories and lib path to use boost 1.39.0, the following compile error occured: 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2061: syntax error : identifier 'BOOST_PP_LIST_FOLD_RIGHT_BOOST_PP_IIF_BOOST_PP_BITAND_1BOOST_PP_LIST_FOLD_LEFT_CHECK_BOOST_PP_IIF_BOOST_PP_CHECK' 1> d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(143) : see reference to class template instantiation 'boost::detail::lower_alignment<target>' being compiled 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2059: syntax error : ')' 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2143: syntax error : missing ')' before '(' 1>d:\reference\boost\v1_39_0\boost\type_traits\type_with_alignment.hpp(138) : error C2061: syntax error : identifier 'BOOST_PP_LIST_FOR_EACH_I_M' ... I have tried several ways to resovlve it, but all failed. Does anyone know how to fix this issue or any advice? I really appreciate your help. Best Regards, wind.

2 1

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

[property] interest in C# like properties for C++?
by Peder Holt 17 Dec '09

17 Dec '09

I have implemented a prototype support for properties in C++. It has no space overhead as it manages to deduce the this pointer of the class owning it. Code sample: #include <boost/static_assert.hpp> #include <boost/property.hpp> #include <iostream> class class_with_property { public: //Implement property template template<typename Base> class property_with_a_sensible_name : public Base { public: void set(const double& a) { //Implement setting of the variable here. m_var=a; //You can access the owner of the property's this value by calling self(), e.g. self()->refresh(); } const double& get() const { return m_var; } private: double m_var; }; void refresh() { std::cout << "Refreshed"; } //Instantiate property template. These can be reused. BOOST_PROPERTY(class_with_property,property_with_a_sensible_name,property_name); }; //And usage: void test() { class_with_property cls; cls.property_name=54.3; BOOST_STATIC_ASSERT(sizeof(class_with_property)==sizeof(double)); } The trick used is the following: class my_class { public: class property_x { public: my_class* self() { //Find offset of member relative to my_class size_t offset=size_t(&((my_class*)0)->x); //Use this to deduce the address of my_class return reinterpret_cast<my_class*>(size_t(this)-offset); } }; property_x x; }; It currently support: Read/Write properties Read properties Write properties Not supported yet: indexed properties operator overloads for properties, e.g. my_class.property*my_class.property will currently fail. Regards Peder

17 64

[ptr_container] ptr_map insert with non-const vs. const reference
by Martin B. 17 Dec '09

17 Dec '09

Hi there, After thinking a while about the issue with the two insert functions of ptr_map and why the one with the raw pointer takes a non-const reference ... See: http://www.boost.org/doc/libs/1_41_0/libs/ptr_container/doc/faq.html#why-do… or http://lists.boost.org/boost-users/2007/09/31014.php I would like to add the following thoughts: ptr_map provides two functions (a) std::pair<iterator,bool> insert( key_type& k, value_type x ); (b) template< class U > std::pair<iterator,bool> insert( const key_type& k, std::auto_ptr<U> x ); Now, I understand the rationale behind having (a) take a non-const reference since this means less potential ctor calls means less potential for a leak. I think the rationale makes sense but it's still easily possible for users to shoot themselves in the foot. Maybe the documentation of these two functions should be expanded upon as I've just spent about 1 1/2 hours to make sense of it all :-) Consider these examples: using namespace std; using namespace typedef boost::ptr_map<string, Foo> foomap_t; foomap_t the_foo_map; // 1 (a) - correct usage string key("key-string"); // need key object to take reference Foo* p = new Foo(); the_foo_map.insert(key, p); // compiles OK // 2 (a) - incorrect usage Foo* p = new Foo(); string key("key-string"); // need key object to take reference - leaks p if throws the_foo_map.insert(key, p); // compiles OK // 3 (b) - correct usage std::auto_ptr<Foo> p(new Foo()); the_foo_map.insert("key-string", p); // 4 (b) - incorrect usage Foo* p = new Foo(); the_foo_map.insert("key-string", std::auto_ptr<Foo>(p)); // compiles OK, but may leak if the implicit Key constructor throws (which only happens for string for bad_alloc, but this is just an example) So my point is, that the non-const reference insert() fails to protect the user from shooting himself in the foot, but it succeeds at highlighting the problem, so the problem should be expanded upon in the docs, shouldn't it? If we have a raw-pointer then no matter of fiddling on ptr_maps part can make it completely exception safe, the user code has to provide that. The raw pointer should already be wrapped in a smart-pointer. So (a) is unsuited for the case where the raw-pointer exists prior to the key object. There is only one case where having the (a) version around makes sense and that is when we have another smart-ptr type: // 5 (a) correct usage string key("key-string"); the_foo_map.insert(key, p.Detach()); // makes a lot more sense than std::auto_ptr<Foo> ap(p.Detach()); the_foo_map.insert("key-string", ap); cheers, Martin

2 1

Any interest in static plugins?
by Dave van Soest 16 Dec '09

16 Dec '09

Hi all, I created a template-based header-only library for creating static plugin systems. I'm wondering whether there would be any interest to include such a library in Boost. About static plugins: Static plugins are not as common as dynamic plugins, but they have some useful applications. Static plugins are a way to extend the functionality of a program or library without having to change the existing source files, just by adding a source file or object file, which is then linked statically against the already existing object files. Some reasons you might be doing this: - You don't have permission to change the existing source files. - You don't have the source files, only the object and header files. - You don't want to have to change existing sources every time you extend functionality. - Simply including or excluding the object file from the linking process adds or removes functionality from the program or library, leaving no traces inside. - Different configurations can be build easily this way. - Testing only the required functionality without having to build the full application. - And some other advantages it shares with dynamic plugins. If there appears to be any interest I will post more information and some code and code examples. Best regards, Dave van Soest

9 30

[endian] ARM support
by Phil Endecott 16 Dec '09

16 Dec '09

Dear All, Can ARM support be added to detail/endian.hpp ? It's complicated by the fact that ARM systems may have either endianness. I believe that the symbols __ARMEL__ and __ARMEB__ are defined by gcc for the little- and big-endian cases respectively. However, it also seems that gcc defines __LITTLE_ENDIAN__; can we just test for that? There is possibly some confusion with __LITTLE_ENDIAN and __BIG_ENDIAN (no trailing __s) which I believe glibc defines both of as 4321 and 1234, but it should be OK to write: #elif defined(__LITTLE_ENDIAN__) && !defined(__BIG_ENDIAN__) ... I suspect someone has looked at this before. It can't do any harm to add all of the potential tests, can it? Thanks, Phil.

1 0

Re: [boost] [explore] Extending namespace std
by Jeffrey Faust 16 Dec '09

16 Dec '09

Hello again. I previously presented an argument of why our best option for container streaming is to extend namespace std. I was surprised by the dearth of responses, but I understand that we're all busy and I admit was a bit wordy. Here is my argument again with, heavily snipped. I think this is the most important issue in making this a boost library. Thanks for reading. Jeffrey Faust wrote: > In my opinion the ideal interface is the most natural, > simplest, and the most familiar to C++ developers: 'cout << c;' where > c is a container of type C. > > The only way I know how to make 'cout << c;' work for all cases is to > put operator<<(C) in the same namespace as C. For example, > variant<C, ...> will not stream if C is in std and operator<<(C) is > not. > > In regards to extending namespace std, I understand what the standard > says and I think I understand the reasons behind it. One could add > something to namespace std that conflicts with an existing item, > changing the behavior. This is undefined behavior, and the > standard is right in restricting it. I don't believe this problem > exists for this library in how we plan to extend std. > > If we know that on all supported compilers that extending namespace > std in this way behaves correctly, what is the concrete problem of > doing so? -- Jeff Faust

3 2

[thread] 1.41.0 regression
by Dmitry Goncharov 16 Dec '09

16 Dec '09

Hi, The thread_data_base constructor is defined in a header file. Function make_external_thread_data() is defined in a .cpp file. This can lead to a situation when different libraries contain the definitions of these functions. The example below explains how this can happen and why this causes problems. The new version of struct thread_data_base contains an std::map member. The size of an std::map object depends on if libboost_thread.so was build with or w/o _GLIBCXX_DEBUG. libboost_thread.so contains make_external_thread_data(). This function allocates an instance of thread_data_base. Due to an std::map member the size of the allocated object depends on _GLIBCXX_DEBUG. There is a library (e.g. libuser.so) which uses the Boost.Thread library. Since the thread_data_base constructor is defined in a header file libuser.so can contain its definition. Again, the size of thread_data_base object, that the thread_data_base constructor from libuser.so expects, depends on if libuser.so was built with _GLIBCXX_DEBUG defined or not. An application cannot link agains both libboost_thread.so and libuser.so if these libraries were built with different _GLIBCXX_DEBUG definitions (or different alignment, etc). While loading the application the dynamic linker will use the definition of thread_data_base constructor either from libuser.so be or from libboost_thread.so. Whichever it finds first. Can both the thread_data_base constructor and make_external_thread_data() reside either in a .cpp file or in a header? BR, Dmitry

2 3

[Build] Boost 1.41(?) and OpenSuSE 11.2: i386 no more?
by Christoph Duelli 16 Dec '09

16 Dec '09

Building Boost 1.41 against OpenSuSE 11.2 works fine... until you try to link a lib against a program: You get the following linker error: <path to boost_1_41_0>/lib/libboost_program_options-mt-Melos.so: undefined reference to `__sync_fetch_and_add_4' Googling around indicated that libc or something no longer supports i386 which is Boost's default -march setting for gcc. (see tools/build/v2/tools/gcc.jam) When I changed the default to i686 and rebuilt Boost, the program linked ok. [See: http://sourceware.org/ml/libc-alpha/2007-02/msg00009.html] I am not sure if this is not rather a bug in OpenSuSE 11.2, but it is annoying nevertheless. * Is there an easy way (I modified gcc.jam for my test) to configure -march? (Pleae see my post (yesterday) "Build boost for i686 (instead of i386)" in boost.user.) * Or maybe i386 is no longer a safe default to assume? Best regards, and thank you Christoph

1 0

[function] Using boost::function when rtti is not available
by David Genest 15 Dec '09

15 Dec '09

Hi, Reposting this from the user mailing list, as it generated no comments. I am in a gaming build environment that has traditionally turned off rtti because of space and portability issues. But, I would like to use the very useful boost::function. On MSVC boost::function works, but fails on g++ for the ps3. I have read on the lists that it is possible to implement a rtti-less version, and that this is even wanted in the future. See: http://article.gmane.org/gmane.comp.lib.boost.devel/192378 And http://article.gmane.org/gmane.comp.lib.boost.devel/191945 I know of a lot of people that would like this dependency on rtti removed. My question to the list is: did anyone have a try at an implementation and could share it ? I have toyed with boost::function and sp_typeinfo.hpp and tried to replace occurrences of type_info in function_base.hpp, but I don't have enough understanding to finish the work and my early attempts have failed. As my current understanding goes, the function type could be generated with the sp_typeinfo trick. Is the sp_typeinfo.hpp route a viable one ? Thank you, David.

4 13

Re: [boost] [msm] Review
by Christophe Henry 15 Dec '09

15 Dec '09

Hi Darryl, >Anyway, I hope that clarifies my concern is not primarily with the >failure to compile on older gcc versions. Yes it does and it's a good point. >I can accept eUML as an experimental library.... Does that help? Yes, I think it's a good term and I'll put it like this in the doc with a word of explanation about compilers and fsm size. >Oh - I also neglected to suggest that a better name for euml is badly needed I like the name eUML. "Embedded UML" is really what it wants to be, UML syntax in the code. Besides you know by now my taste for names which sound cool ;-) Of course, if you find some really cool name... Christophe

1 0

Re: [boost] [msm] Review
by Christophe Henry 15 Dec '09

15 Dec '09

Hi Michael, >I personally find this library both useful and well >implemented for many of my needs. The documentation is >lacking and must be extended to include a library >reference. Additionally, I would like to see SimpleStates >implemented to support internal transitions as called >out in the standard. Other issues are detailed; however, >do not affect my qualified vote of "acceptance". My >conditional recommendation for acceptance (yes vote) >is based on resolving the documentation issues and lack of >SimpleState internal transitions. Thank you for the detailed review. Your UML experience is very valuable and appreciated. I'd like to discuss a few points. I've been thinking about internal transitions. I see 2 ways to implement them: - an UML-conform way where states have their own stt with reduced rows (no target) - a row in the state machine stt (also without target) which I wanted to implement anyway. The first has the advantage of being UML-conform and thus respecting the UML priority in case of conflicts (internal transitions having the highest). It also makes the state more valuable and maybe reusable. The second is more general than the UML-conform way as it allows you to define yourself your priority according to the position of the transition in the stt. It will also compile faster and be slightly faster. You also see the conflict better in the stt. But you lose a reuse possibility. I understand why internal transitions have a higher priority in submachines (for exit points to work I suppose) but for simple states? That's why I personally tend to prefer solution 2 but I'm interested in your take about it. >I haven't thought too much about this, but it seems that the functor (Row) >mechanism might be extended further to replace the various >"arow" syntax completely. It can do all what the "row" does, all in one. I would still prefer to keep the "row"s because they are so simple that they attract unexperienced users who are sometimes scared of seeing templated functors (I tried ;-) ). They are a good entry point into MSM. >I find myself missing choice points. Using "anonymous >transitions" nearly allows the same semantic... but not quite. For interest, what don't anonymous transitions allow? I scratched my head for a long time and all I found was for the case where you have multiple choice points. In this case, the path goes further only if at least one full path to another state is found (if I got it right). Is there another reason to have choice points? >I also miss not having a "any" or "*" trigger >definition. In essence, if no transition match is found for >the active trigger ... take this transition. This one was left out because I found no easy way to do it. It'd probably involve adding behind the hood a row for every event of a machine. It's harder to know how many rows are needed then. Besides, I never found a use case for this, so if you have one, I'm quite interested. >Additionally, an example of converting a runtime int to >a type is in order. Most people doing statemachine work are >acting on some trigger that now needs to be translated to >a data type. There are many ways to slice this but none are listed. I unfortunately found not many ways and almost all are pretty bad. One would be an ugly switch/case, the other guards (forcing a O(n) dispatch). Probably the best is letting the action generate internally another event. I will look for a way to solve this better. >As an aside, I would be happy to review and offer feedback >with documentation modifications. I may be able to offer some >assistance with modifications also. With pleasure! As you see, I already started ;-) >Inconsistent use of eUML. Sometimes it is EUML (particularly at the >start of a sentence.) I believe it should always be eUML. Being not a native speaker, I followed what Word told me and it was probably a bad idea so I'll trust you on this. >While the implementation of deferred events is correct according >to UML I have found that the ROOM concept is extremely useful >and have implemented it in my own libraries. You may want >want to consider it as a feature to MSM I admit I don't completely get it but it surely sounds interesting. Would you have some written document or spec about it? >Without a deep history concept in MSM I am required >to specify a history policy for each contained sub-state machine >(composite state). I do find this rather annoying though >it is workable. I find rather annoying the UML way. At least there should be a workable solution for orthogonal regions and deep history. Yes, MSM forces a policy but in exchange gives you much more power. >My initial reaction to flags is "composite states already >supply this information". I can see that flags can provide >multiple slices of meta state information and *might* be >useful. I am in general leery of abstractions that obfuscate >additional state information. From a diagram POV, that >state information is missing. In my world this typically >means that the granularity of machines is wrong Flags are a generalization of IS_IN for some UML tools. Consider the following example: State1 fulfills some property (called P1). State3 fulfills a property P2. And State 2 fulfills P1+P2. Now, composite won't help you because there is no way to put State2 in 2 composites. So when checking in a guard for, say P1, you'll be left with if (IS_IN(State1) || IS_IN(State2)). I personally prefer is_flag_active<P1>(). In this case, there is probably nothing wrong with your hierarchy, it's simply the IS_IN concept which is not enough general. >I personally like this format for describing a row. I hate >to suggest yet one more mechanism... but having "row" utilize >a "none" would be nice. Yes, that there is no "none" is a limitation of having function pointers in "row". Even having default value was making compilers unhappy. It was one of the reasons for having the "Row". OTOH function pointers really can be understood by everybody (I work a lot with ex-C developers). >I find my fence riding odd because I have always thought a DSEL >like this would be the cat's meow. I think it might be the >copious use of BOOST_TYPEOF is just hard on my eyes and getting used >to the ordering of build_state. All of those instantiations of objects >with the ().... it just looks messy to me. I'm open to any suggestion. The only other way I see is to create an instance for each type used in the stt, but it's also not great. We could pack it in a macro, but it hardly qualifies as more beautiful. Could you try the new row grammar which I posted in the vault and tell me if it looks slightly better? (note: sorry, I still use == instead of =. This will be changed too). >eUML seems to be a non-starter for me and these platforms. I've been wondering about this too. VC makes a much better job at eUML executable size (no size overhead), so it is possible and I hope g++ will catch back. Thanks for the very useful comments. Christophe

1 0

[function_types][fusion]
by Felipe Magno de Almeida 15 Dec '09

15 Dec '09

Hi, This simple call results in errors. boost::fusion::fused<boost::factory<int*> >() (boost::fusion::vector0 ()); Errors in gcc 4.3.2: /opt/i686-cross-gcc-boost_1_38_0/gcc-4.1.2-glibc-2.3.6/i686-unknown-linux-gnu/i686-unknown-linux-gnu/usr/include/boost/fusion/functional/invocation/invoke.hpp: In instantiation of 'boost::fusion::detail::invoke_impl<boost::factory<int*, int boost::detail::none_helper::*, factory_alloc_for_pointee_and_deleter>, boost::fusion::vector0, 0, true, true>': /opt/i686-cross-gcc-boost_1_38_0/gcc-4.1.2-glibc-2.3.6/i686-unknown-linux-gnu/i686-unknown-linux-gnu/usr/include/boost/fusion/functional/invocation/invoke.hpp:80: error: invalid use of undefined type 'struct boost::fusion::detail::invoke_mem_fn<boost::factory<int*, int boost::detail::none_helper::*, factory_alloc_for_pointee_and_deleter>, boost::fusion::vector0, 0, true>' /opt/i686-cross-gcc-boost_1_38_0/gcc-4.1.2-glibc-2.3.6/i686-unknown-linux-gnu/i686-unknown-linux-gnu/usr/include/boost/fusion/functional/invocation/invoke.hpp:89: error: declaration of 'struct boost::fusion::detail::invoke_mem_fn<boost::factory<int*, int boost::detail::none_helper::*, factory_alloc_for_pointee_and_deleter>, boost::fusion::vector0, 0, true>' This seems because CBI in invoke_impl is being defined as true. And ft::is_callable_builtin<Function>::value is being true. But Function is boost::factory<int*> and doesn't look like a callable-builtin. If I force CBI to false, then it works. Any help would be appreciated, -- Felipe Magno de Almeida

1 0

Re: [boost] [msm] Review
by Christophe Henry 15 Dec '09

15 Dec '09

>I'm out of time (not just the review period but other time constraints) >for doing a proper review, something I regret. However I would like to >vote for the acceptance of the msm backend conditional on: > >Improvements to documentation to formally and fully describe the msm >interface. As already said, I agree to add a reference. >Inclusion of straight-forward out of the box configurability to support >large FSMs. Unfortunately, there is nothing I can do to improve the compilers :( >Yes, with gcc 4.2.4 > > - Did you have any problems? > >I couldn't get the euml examples to compile. I'm not sure whether this >is an environment problem (I was using boost 1.40 on Debian testing) or >something else. I didn't spend much time investigating. As stated in the documentation, g++ supports eUML only from 4.3. It is therefore normal that you didn't manage it. eUML support is repeated several times in the documentation. >My comments have been almost entirely around the back end and the more >direct front-ends to it. I personally think euml should be a separate >submission/review, once it is more "review ready". There seem to be >boost version and compiler version issues in getting even the examples >to compile. These are quite possibly outside of msm/euml itselfs >control, but if nothing else, they prevent easy review of euml. > >I'm actually struggling with the above, because I think having euml in >trunk, with tests being run, could facilitate resolving some of these >issues. Maybe euml could be included as some experimental/example part >of msm initially? I'm afraid you're extrapolating a little from your own experience using the wrong compiler. There were just 2 issues so far. One with VC8, which has a (documented) weak support for eUML. This issue has been fixed immediately. The second is a reported warning on g++, which I was not able to reproduce and needs more concrete input from Michael. It doesn't seem sufficient for calling eUML not "review ready". True, eUML has more limited compiler support and this is documented too. It doesn't make it less ready. >I don't generally bombard innocent bystanders with my vague ideas. I >took asking for a review to be asking for it :-) The review involves many questions from different people and vague ideas are hard to address. Fortunately, you clarified afterwards, so that I can take valuable data from it. Sorry about the wrong start. It's quite sad because I find a few points quite interesting and they will flow in the design of the future back-ends or improvements in the current one. >In putting together the LAPD implementation I'm using the functor front >end, but end up creating functors via a few macros that dispatch to the >objects that do the work. I find they don't need access to anything >other than the fsm (to post events back to) and the event (to >access/process anything it contains). I'm fairly happy with that aspect >of the interface. If it's bothering you to have the source/target states as argument, it's trivial for me to add a new row type. I wouldn't want to force macros on you. >I haven't tried to do it yet, but it struck me that I could potentially >use the state types alone (not the object ref parameters) as tags to >determine which object to dispatch to. If I chose to have objects that >were 1:1 with states I could - but it wouldn't be part of the fsm >kernel. Is that concrete enough to make sense? It is ;-) I'm just unsure if I follow you. With "object to dispatch to", do you mean objects in your application? Why not use the state for this? I'm interested in your use case for future developments. >No, I don't agree at all. I can't see how you can argue that having >transitions specified in states as statechart does is less clear than a >separate transition table, then claim that having enty/exit actions >specified in states is more clear than having them similarly separated. Good point, which I need to explain. The problem with Statechart's approach is that states do the job which should be the state machine's. This increases the importance of states in Statechart, at the cost of the state machine, which becomes little more than a wrapper. It also mixes entry/exit with the rest of the transition. It's not my reading of the philosophy behind the UML specification. I think the states have a role, state machines another. State machines implement the structure of the diagram. States implement state-specific job, which is much less than the state machines'. Their jobs are: - entry/exit - holding state-specific data (not in the UML standard but still sounds logical to me) - (possibly) internal transitions When you look at a transition table, you see the structure of the machine and only the structure. (EUML shows you more, but this is not a classical state machine front-end :) ) AFAIK you didn't complain about not seeing the actions/guards code in the transition table. To illustrate the difference of roles, could you please have a look at the examples iPodSearch or iPodSearchEuml? This is a good example. Take the state StringFind. Its description would be: - looks if the string contained in an event is found in the string contained in the state. - if found, the state sends the event Found on the current state machine. - else it sends NotFound. Note that StringFind has no idea of which fsm it is used in. It only gets a generic fsm as argument of on_entry. The same documentation is possible for the other states (Foreach and Insert). So what do we have? 3 states, perfectly reusable and implementing some valuable job. And they have no idea of the transition table. Now imagine that MSM comes in with more states, transform, remove, push_back, etc. Using a supporting CASE tool, one could easily build complex algorithms. >I personally find this response vague Is this already less vague? About the CASE tool, I showed an early prototype in the last BoostCon and plan to start working on it again after the review. I only ask for some patience (for the tool, the state library concept and the back-ends) because I'm doing all this at night, so I'm not so fast ;-) For the moment, the tool only allows defining a complete state machine and generates MSM1 code from it. >But why do they need to be part of the transition table based "kernel"? >Don't pay for what you don't need/use? True, it is an extra cost. Not a big one though, and with little influence on the performance. >Yes. Rather. Sorry for the combination of complex grammar and outright >incorrect grammar that would seem to have lead to this. Sorry for my lack of patience due to my several parallel discussions. >I'm not outright against state instantiation. I can't be. I do really >like statechart's state instantiation model. However, in the review of >that library I did ask if there was any way that the costs associated >with it could be avoided when not strictly needed (when the state >contains no state-local storage). I'm asking a very similar question >here, but somewhat more emphatically because this is the Msm (first M is >important!) and it should surely be able to do this There are limits to what the first M can do though (besides, you know what that means to your compiler). But I now understand the point and find the idea interesting. It'd probably be possible to instantiate only states with local-storage. It would require a tag (as I won't be able to rely on sizeof) but it could be possible. Thanks for the good point! >> - make a 3rd one, more dynamic, which I want to do since a while. >> - make no review until all possible back-ends are done and make >> everybody wait at least one more year. >> >> Do we agree that solution 1 seems the more logical? > >Logical from what perspective? Buying votes or producing a good library? >Politics... ;-) It's not politics and even less buying votes, but a simple recognition that each developer will use different features and if he doesn't find his, he'll simply not use the library. I'm pretty sure, if I had only proposed a mini-backend, many would have complained about the lack of features, and they'd be right. The say 20-40% of UML features which you use won't be the same as what another developer will use. So, a library needs to support as much as possible. I think MSM is a good library as it offers almost all of UML features at very low runtime cost. The only high cost is the compile-time. Now it's proven that the concepts of the MPL book were right, that it was indeed possible to implement at least as much as statechart with metaprogramming techniques. That this wasn't evident, as shown here (http://lists.boost.org/Archives/boost/2005/03/81853.php) I hope you'll trust me that if I can also implement less ;-) If I get you right, the only major problem you have with the back-end is the automatic, unavoidable instantiation of states? Doesn't sound like an impossible problem to me :) Christophe

5 4

boost libraries and libCstd
by Sascha Ochsenknecht 15 Dec '09

15 Dec '09

Hi, the SUN compiler comes with two C++ standard libraries: libCstd and libstlport. libCstd is the 'old' version of the C++ libraries which has not all features of the standard implemented. The differences are described here: http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html The linked page also describes workarounds. My question now is, does BOOST officially support libCstd? And if yes, are there macros (#define's) defined to choose the appropriate code (standard or workaround) within the boost library code? The backround: the program_options library and probably some others do not compile/link with libCstd. This is described e.g. in Ticket #3190). Thanks in advance, Sascha

3 2

Re: [boost] library proposal: odeint
by Karsten Ahnert 15 Dec '09

15 Dec '09

Hi, solving ODEs is pretty standard, but it is also a starting point for elaborate numerical analysis and tools, especially if you solve large systems with conserved quantities. Nevertheless, I think some simple ODE solvers would fit into Boost, libs for numerical root finding and optimization are also part of it, at least experimentally. Many libraries for solving ODEs exist in the C/C++ world, but many of them lack the use of the standard interfaces and containers. This is really a drawback to languages like Fortran or Python and odeint is one attempt for easy to use and container-independent ode solver. Best regards, Karsten

3 3

Re: [boost] [Regex] Why doesn't this pattern match?
by Vitalij Gotovskij 15 Dec '09

15 Dec '09

Yes, Robert, You are right. I am trying to change \\n (wchar_t '\' and wchar_t 'n') with a real new line symbols and it doesn't work. Allthought, then I am trying to find only wchar_t 'n' (or any other letter) everything is working good. The problem is that I have XML configuration file (Unicode), where all new lines are L"\\n" (!!! not '\n' !!!). I can't change that file format. Of course I can program that replace without boost::regex, but I am afraid that I'll loose my sleep afterwards... >> You're replacing each occurrence of \\n with \\n, so the >> string at the end should be exactly the same! :-) > The replacement is "\n" not "\\n" so the '\' followed by 'n' in str should be replaced with a newline, right?

4 3

Re: [boost] [msm] Review
by Christophe Henry 15 Dec '09

15 Dec '09

>It seems to me that waiting to add a great library until some particular >compiler supports it isn't a great strategy. Msm works on our >production compiler, and it seems to me that the compiler support is >documented. I agree. Besides, if not used, eUML will wait long for compiler support. Compiler writers do need some users complaints as I just saw a few weeks ago. >If we fear rejection due to incorrect usage by potential >users who haven't read the documentation, perhaps the library could have >some built-in support for detecting compilers that are known not to work >and issue a coherent compiler-time error message. I think it's a good idea! EUML could simply refuse to compile if provided the wrong compiler. >So long as MSM works on multiple, highly-regarded compilers, and its failure on others >can be demonstrated reasonably to be due to failure to comply with the standard, then its portability >will have been demonstrated. If it only works on one compiler, then its portability case is diminished. EUML compiles well on g++4.3, and reasonably well on VC9/10 and g++4.4. Darryl, I understand your point and appreciate that you want to protect eUML but I think that propagating it is the best solution to make compilers improve. More warnings in the doc would also help.

2 1

library proposal: odeint
by Karsten Ahnert 14 Dec '09

14 Dec '09

Hi, I am new on this list and want to start a discussion if a library for solving ordinary differential equations (ODEs) would fit into boost. We are developing a lib - odeint - for such problems. odeint can be found in the sandbox: https://boost.org/svn/boost/sandbox/odeint, but the current stage is far away from being ready for release or submission. ODEs are usually solved iteratively. Therefore, we have introduced two stepper concepts, one for steppers with- and one for steppers without error estimation. At the moment some explicit solvers are implemented: Euler, RK4, Cash Karp, RK78,midpoint and Burlisch-Stoer. Here are some examples: typedef std::tr1::array< double , 3 > state_type; // define the ODE void lorenz( state_type &x , state_type &dxdt , double t ) { const double sigma = 10.0 , R = 28.0 , b = 8.0 / 3.0 dxdt[0] = sigma * ( x[1] - x[0] ); dxdt[1] = R * x[0] - x[1] - x[0] * x[2]; dxdt[2] = x[0]*x[1] - b * x[2]; } state_type x = {{ 1.0 , 0.0 , 0.0 }}; ode_step_euler< state_type > stepper; double t = 0.0; // iterate the ODE by hand with constant stepsize for( size_t oi=0 ; oi<10000 ; ++oi,t+=dt ) stepper.next_step( lorenz , x , t , 0.01 ); // integrate the ODE with constant stepsize // from t = 0.0 to t = 100.0 with dt = 0.01 // and write t and x[0] to cout integrate_const( rk4 , lorenz , 0.0 , 0.01 , x , 100.0 , cout << _1 << tab << _2[0] << "\n" ); // stepsize controller for rk5 cash-karp controlled_stepper_standard< stepper_rk5_ck< state_type > > rk5_controlled( rk5 , eps_abs, eps_rel, 1.0, 1.0); // solve the ODE with an adaptive stepsize controller size_t steps = integrate_adaptive( controlled_rk5, lorenz, x, 0.0, 10.0 , 0.01, cout << _1 << tab << _2[0] << "\n" ); Best regards, Karsten

7 6

Re: [boost] [msm] Review
by Christophe Henry 14 Dec '09

14 Dec '09

Hi Darryl, >Your responses come across as though you feel you are under attack. >Please accept that is not my intent I'm sorry if I gave this impression. While I was unsure what were your concerns at the beginning, I now appreciate a lot your contribution! You'll probably recognize your suggestions in the next versions :) >I see these as incredibly closely related in a C++ FSM model. This is >because, in my experience, the actions done in entry and exit actions >are resource management-like, very similar to the role of constructors >and destructors (or more generally scope entry/exit). I had intuited >that the rational for including entry/exit actions in fsm notations was >to model that scope concept. Actually, my take on the use of entry and exit was not scope entry/exit but rather a way to factorize behaviour out of the transition. So, to sum up our discussion: - I agree that using entry/exit for RAII sounds interesting. - paying 1 byte/state even if you don't need them is almost not visible on the performance level but I agree that it's still feeling not right. - on_entry and on_exit have in my opinion, compared to constructor and destructor, the advantage of flexibility (such as getting the event or fsm or the ability to throw). - while you would prefer to have no states, using them for tag dispatching still looks interesting to you. - I'm positive persisting data in states favors reuse in another fsm context. I hope to bring later some reusable state concept to prove this point. This pretty much sums up our discussion, right? We had a rocky start (due to my misunderstanding) but I understand this is the where we now are. I think that it's possible to have all this at the same time, constructor/destructor and entry/exit, persistent states and non-persistent, maybe in the same state machine. I can imagine a few possible solutions but need to think more about them. I'm pretty sure that it's possible to have at least non-persistent states (using no memory) while being still compatible with the front-ends (who require a source/target state). So, I thank you for the interesting discussion which delivered valuable points. I'll be happy to continue the discussion as soon as I can offer a solution. Christophe

1 0

[msm] Review
by Michael Caisse 14 Dec '09

14 Dec '09

Let me start with a thank you. Thank you Christophe for taking the time to "boostify" and submit this library. Thank you also for your quick responses to questions and discussions through out the review. I apologize that this is "late". I was unable to complete the review over the weekend. I am afraid that this review is somewhat disjointed. There are two parts. The top section answers the standard questions and provides some overview. The bottom section provides some specific details about the documentation and also discussions about specific features covered in each document section. I found that reviewing in order of the tutorial provided some structure to the review. Some of the points I make have been brought out in other emails/reviews ... but this is my review so I felt compelled to write down what I found important. Best regards - Michael Caisse ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Executive Summary: I personally find this library both useful and well implemented for many of my needs. The documentation is lacking and must be extended to include a library reference. Additionally, I would like to see SimpleStates implemented to support internal transitions as called out in the standard. Other issues are detailed; however, do not affect my qualified vote of "acceptance". My conditional recommendation for acceptance (yes vote) is based on resolving the documentation issues and lack of SimpleState internal transitions. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------ What is your evaluation of the design? ------------------------------------------------------ The design seems sound; however, it has a feel of being in flux when reading the documentation. There are perhaps too many methods to create row entries. I haven't thought too much about this, but it seems that the functor (Row) mechanism might be extended further to replace the various "arow" syntax completely. ------------------------------------------------------ What is your evaluation of the implementation? ------------------------------------------------------ From the point-of-view of a UML implementation, I think this library does a good job of implementing the most used features of the language. I would like to see the addition of internal transitions for SimpleStates before the acceptance of the library. Lack of this feature makes it awkward at best to implement constructs that are the UML state machine equivalent of RAII. Entry and exit code for a state are often used to do things like start/stop timers and other such resource management. Not being able to handle internal transitions (transitions that don't leave the state and therefore do not cause an exit/entry cycle) make modeling this concept impossible. Hacks can be applied to work around the shortcoming ... but implementing the feature is the right solution. I find myself missing choice points. Using "anonymous transitions" nearly allows the same semantic... but not quite. I am used to being able to define multiple triggers for a transition. This is not a deal-killer but it would be nice to be able to somehow do this. Perhaps I could by having event 'a' and event 'b' derive from a common base and then using the 'base' as the event. I'm not sure. I also miss not having a "any" or "*" trigger definition. In essence, if no transition match is found for the active trigger ... take this transition. I have not spent enough time with the source code to provide an evaluation of the source. ------------------------------------------------------ What is your evaluation of the documentation? ------------------------------------------------------ The provided documentation is basically a tutorial. I found that a library reference guide was lacking. Though the tutorial was excellent, not having a library reference made using/reviewing the library difficult. I'm sure that there are many features and exploits that I didn't discover because the only route left to the reviewer was hope an example was in the tutorial, used in the example source code or by rummaging through the library source. Please make sure to add a section describing the run-to-completion semantics as well as the ordering of evaluation/execution when a trigger if fired. Additionally, an example of converting a runtime int to a type is in order. Most people doing statemachine work are acting on some trigger that now needs to be translated to a data type. There are many ways to slice this but none are listed. When showing this to another programmer the response I got was, "but I have ints or chars that I'm acting on. How do I make that into a type?" External stimulus is not a type so some hint on ways to do this will be nice for those getting introduced the concept for the first time. As an aside, I would be happy to review and offer feedback with documentation modifications. I may be able to offer some assistance with modifications also. Additional documentation edits can be found at the end of this review. ------------------------------------------------------ What is your evaluation of the potential usefulness of the library? ------------------------------------------------------ I find this library very useful. I have already begun modifying my code generators that take ArgoUML and Poseidon diagrams and generate code based on distributed machines to use MSM as a backend. This will allow me to fully understand the usefulness of the library to medium/large projects. At this time I have started using MSM for a smaller state machine project. I am finding the library useful. ------------------------------------------------------ Did you try to use the library? ------------------------------------------------------ - With what compiler? gcc-4.3.3 and VC 8 My experience with gcc has been fine. My experience with VC8 ran into problems with the eUML. I just switched to linux/gcc since my target almost always involves a gcc compiler. I don't have enough concrete experience with VC8 and MSM to provide a solid viewpoint ... but my soft view is that it might need some more help. - Did you have any problems? eUML (as expected) didn't work with VC 8 ------------------------------------------------------ How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------------------------------ I spent about 25 hours reviewing this library. I did not spend very much time with the source code but instead reviewing the documentation and testing the concepts/implementation as they stack up to the UML 2.0 standard. I also spent time implementing several of my own machines with the MSM library to determine how applicable and conforming the library might be. ------------------------------------------------------ Are you knowledgeable about the problem domain? ------------------------------------------------------ Yes. I have been dealing with UML based statemachine notation before it was part of UML. I have my own product that implements ROOM/UML distributed hierarchical FSMs that are generated from diagrams. I have implemented several UML compliant state machine libraries in a variety of languages. ------------------------------------------------------ Additional Documentation Comments Other MSM comments in order of the docs... ------------------------------------------------------ General: Inconsistent use of eUML. Sometimes it is EUML (particularly at the start of a sentence.) I believe it should always be eUML. Sub-state machines and composite states are not *exactly* the same in UML. It seems that it is implied or stated in a few places that it is. I would just state up front that Msm does not support composite states; however, it does support the more general solution of sub-state machines. ---------------------------- Section "Why Msm v2?" "UML designers are also used to write..." should be "UML designers are also used to writing..." ---------------------------- "Msm v1.x Features / Design Goals" If you are taking votes about multithreading ... please make it some non-required layer or policy or let the user's discretion play out. I will be using Msm on targets without an OS. "Msm v1.x Features / Founding Example" It might make sense to utilize UML terminology when discussing the parts of a transition: current state -> source state next state -> target state action method -> effect or behavior event -> trigger So... maybe not the event to trigger change. This is an interesting concept in Msm. Often an event is considered as having a trigger and optional data payload. The Msm event is a struct with possible data members. Event is fine I guess. "The event being passed the" -> "The event being passed to the" --------------------------- "A more advanced example" "The UML specification isn't too clear about the difference between composite states and sub-state machines..." That statement isn't exactly true. The specification is clear; however, Msm has implemented the more feature rich concept which is a superset of composite state. If there isn't a runtime (resource) penalty for this, then I don't see a problem. -------------------------- "Orthogonal States..." While the implementation of deferred events is correct according to UML I have found that the ROOM concept is extremely useful and have implemented it in my own libraries. You may want want to consider it as a feature to MSM. The defer mechanism is the same (you can defer any event in any state); however, you can later "recall" from the defer queue. This has the benefit of allowing a "simple" construct for handling deferred events. You can defer the events at a parent composite state. Once you enter the sub state handling certain (potentially deferred) events you can then do a recall from the queue. This is often done in the state's entry code. This pattern reduces the work involved by taking advantage of the hierarchical aspect of UML states. -------------------------- "Adding an history" should be "Adding a history" I personally am happy with the UML definition of histories and use them often in error handling patterns for example. Part of the power of UML states is the fact that they are hierarchical. Without a deep history concept in MSM I am required to specify a history policy for each contained sub-state machine (composite state). I do find this rather annoying though it is workable. I do like the AlwaysHistory policy since that is my normal use case when using histories. -------------------------- "Using 'flags'" My initial reaction to flags is "composite states already supply this information". I can see that flags can provide multiple slices of meta state information and *might* be useful. I am in general leery of abstractions that obfuscate additional state information. From a diagram POV, that state information is missing. In my world this typically means that the granularity of machines is wrong (I use distributed state machines) or the state hierarchy is not quite right. I have the same negative feeling about storing a lot of *state* information in variables that are acted upon in guards and such. It hides important information from the diagram and makes the machine harder to review and understand. This is not an argument to remove flags. It is just my first impression of the feature. I will need to play some more with it. I can see potential uses. -------------------------- "Anonymous transitions" In the UML standard the term "Completion Transition" is used for this concept. I like this term because it is descriptive of what is happening. I also like it it because this is a UML compliant library and using the UML terminology helps understanding the concepts more quickly. -------------------------- "The many ways to enter a composite state" Explicit exit is often a problem. I found that in two of my machines I tried converting that I use this mechanism. I used an exit point to work around the missing feature. This works ... but wasn't my intent. That said... I think what you have is proper for a submachine state. If MSM actually implemented composite states, then the lack of this notation would concern me. This might just be me, but the purpose of a submachine is to wrap a composite state into a reusable object. Entry and exit points therefore represent the public interface. Explicit entry and exit would be like accessing private data. "Important note 3" - I think this is important behavior for the proper use of submachine states. -------------------------- "Advanced" -------------------------- "Conflicting Transitions" This information is important. I think expanding the section to discuss the run-to-completion semantics and the order/execution rules followed when a trigger is received is vitally important. Example, trigger A is received. The following steps are performed in this order: .... -------------------------- "Contaning state machine (deprecated)" This type of thing just confuses the situation. You have a recommended practice and the library is just now in review. I would leave this out or if you feel it is important... add an appendix for those using pre-boost versions of the library. -------------------------- "New Msm V2.0 Features" -------------------------- "Functor rows" I personally like this format for describing a row. I hate to suggest yet one more mechanism... but having "row" utilize a "none" would be nice. Then there would be two mechanisms in the table -- 'Row' for functors and 'row' for other types. Better yet would be figuring out how to combine those into one. -------------------------- "eUML" I played with eUML some and I find myself on the fence. First off as I had related earlier, I think the ordering is not natural. I do like Rob Stewart's suggestion of: DestState() = CurrentState() + cool_event()[guard()]/(action()) I find my fence riding odd because I have always thought a DSEL like this would be the cat's meow. I think it might be the copious use of BOOST_TYPEOF is just hard on my eyes and getting used to the ordering of build_state. All of those instantiations of objects with the ().... it just looks messy to me. I love the idea and I think it is nearly there. It just 'looks' complicated when I quickly view the source. In the end I didn't have enough time to finish reviewing this portion of the library. My gut says that it might be almost ready for prime time. It might just need some more help with the sugar coating. -------------------------- "Executable size" A lot of my state machine targets have 256k flash (or less) and minimal RAM. Size is a big concern to me. I'm also unsure about these claims. Not that the claims are wrong ... but my own testing has yet to convince me that I will be able to use MSM for those targets yet. I always use -Os but I am still experimenting with the impact of size with the various front-ends and row options. eUML seems to be a non-starter for me and these platforms. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Review Request: boost.lockfree
by Tim Blechmann 14 Dec '09

14 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all, since my first review request for boost.lockfree [1] was completely ignored, here a second version for review. the main differences are bug fixes provided by various people, trying to run boost.lockfree on different compilers/platforms. the original review request was: i would like to submit a small library of lock-free data structures for review. boost.lockfree provides implementations of lock-free data structures. lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. boost.lockfree provides: * boost::lockfree::fifo, a lock-free fifo queue * boost::lockfree::stack, a lock-free stack updated links: the code is available from the boost vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… and from my personal git repository: git://tim.klingt.org/boost_lockfree.git http://tim.klingt.org/git?p=boost_lockfree.git the documentation is available at: http://tim.klingt.org/boost_lockfree/ would be nice if someone could add this library to the review schedule or even would be willing to manage a review ... best, tim [1] http://article.gmane.org/gmane.comp.lib.boost.devel/192779 - -- tim(a)klingt.org http://tim.klingt.org Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksLtukACgkQdL+4qsZfVssO7wCfel+ro8wr9TXA5fCHdq3+Dv0z 47sAniqHVyaQ4m4vOwr1SyRp9liUr9Dh =FZao -----END PGP SIGNATURE-----

12 18

Performance problem with boost thread
by ellan 14 Dec '09

14 Dec '09

My code is in C++; I am using thread_group directly. The thread group call a function member of the same class. In side this function member I called another class's function member to finish the task. The task is completely "embarrassingly parallel", thus I expect it scale very well. But it didn't, the performance of my code I describe above is even worse than when I use boost thread to call a executable instead of the function member of the same class. I don't understand what's going on. Any suggestions are really appreciated!!! -- View this message in context: http://old.nabble.com/Performance-problem-with-boost-thread-tp26779904p2677… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
by Christophe Henry 14 Dec '09

14 Dec '09

>One interesting feature is that there are several buttons that have >different actions associated with short and long presses. So I can >imagine per-button state machines that do something like: > > UP --pressed--> DOWN --timeout--> LONG_DOWN > <--released---- | > <---------------------released--------+ > >These could feed events like left_button_short_press, >right_button_long_release etc into a main state machine. > >Can you outline how you would implement this in MSM? I implemented it exactly as you described. >I can see how you >could store the button identifier as event state and send e.g. >short_press(left_button) to the main state machine, but this would then >need transition rules using guards to test the button id. (I don't >think this is an application for a sub state machine because each >button's machine runs concurrently, right?) To make the follwowing answer clear, I just added in the sandbox (msm/libs/msm/doc) a BoostCon09 subdirectory. You will find the diagrams (top fsm, menu and playing submachines) and an implementation using a standard front-end and for the fun, another one using eUML (tested with VC9 and g++-4.3). I didn't generalize like you suggested. Though I like your solution and it is probably going to work, I didn't want to make the example more complicated (it is already complicated enough). To solve the concurrency problems, I simply added more regions and each button is handled in one of them. It is not such a big repetition because the south button has its own handling anyway. The interesting and complex part is not so much the button handling, which could be done with an ad-hoc solution too, but the separation of tasks between the regions. One handles the hold button and stops all processing using an interrupt state, some handle the buttons, and others are simply here to give to an hardware event (like using the middle button) a different meaning according to the state where the state machine is. For example, CheckMiddleButton is doing just this. Only one state. All regions are small, and each handles a very specific part of the problem. See it as a sort of "divide and conquer" ;-) The whole point of the example was to show how, using UML techniques supported by MSM, writing a mock-up for an iPod was easier than using an ad-hoc solution. We spent 90mn purely on diagram and used a tool to generate the code instantly. And this was the second point, to show how MSM was supporting a model-based approach and that such a tool was feasible. Christophe

2 1

[svn] merge to release HOWTO?
by Eric Niebler 14 Dec '09

14 Dec '09

I clearly am doing something wrong when it comes to merging changes from trunk to release. I feel that as one of the release managers, this is something I should know. :-P Long ago, the agreed procedure was to use svnmerge.py to merge individual revisions (or revision ranges) from trunk to release, running it from the root of the release branch. I have been faithfully doing it this way. But look at the result of my most recent merge: https://svn.boost.org/trac/boost/changeset/58336 The revisions I merged had only changes to proto and xpressive, but what actually got merged includes property changes to files and directories all over the map. What's going on? Am I not doing it the right way? -- Eric Niebler BoostPro Computing http://www.boostpro.com

6 7

Re: [boost] [msm] Review
by Christophe Henry 14 Dec '09

14 Dec '09

Hi David, Hi Darryl, >It is simply great EXCEPT for lack of instructions on how to actually leverage the design decision >to separate front and back end fully, i.e., helping me to define my OWN front end or back end for MSM. >So, I must take the design claim of separability with a tiny grain of salt. I didn't dream that someone would really ask me this :) Ok then I'll document this part. The interface between front- and back-end is pretty simple. Should you need any extension of it, please let me know, I'm very interested in your idea. > Yes, yes, yes! thanks :) >The name Meta State Machine is misleading. An FSM acting on other FSMs? >Or, to add the C++ modern (and in my view quite improper...) semantics of 'meta': an FSM being executed in compile-time? Nah. Short before the 1.0, there was only one class, state_machine (now the backend). So, like a metalanguage, which is a language used to build other languages, MSM was a state_machine to build state machines. Granted, afterwards, the pun looks less funny ;-) >I agree - how about ffsm - fast finite state machine - or should that be >frightfully fast state machine :-) Sounds cool :)

1 0

Re: [boost] [msm] eUML guard/action location
by Christophe Henry 14 Dec '09

14 Dec '09

>Yes it is an interesting "hack".How "pretend" have you been able to make >this? > >I was actually thinking about exactly this today (long drive - actually >- correction - I was thinking about it yesterday - it's now early >morning here) and wondering what the consequences were. Does it result >in actually default constructing all these (temporary) objects? Won't >that be expensive and/or have undesirable side effects? This is actually what I find so cool with the typeof feature (is it too late to donate a kidney for it? ;-) ). We are calling constructors and lots of operators and it costs nothing run-time because typeof only evaluate the return value of build_stt(...). So no call actually happens. All what you have really is a typedef. The only side effect (besides compiler support) is that you need an empty constructor or would be forced to pass some dummy value.

1 0

[rdb] 0.2.02
by Jean-Louis Leroy 14 Dec '09

14 Dec '09

I have uploaded a new release to the vault. It contains : * support for the float type. Internals have been cleaned up to make it easier to add new types * SQLGetData is not used anymore, result_set uses bound variables to read results I am a bit concerned about compilation time. Guess I'll have to take a look at the template profiler as well. I use float_ (note: underscore) for the variable type for receiving float values (and the length/null indicator). I am a bit tempted to switch to a convention that would prevent clashes with C++ names, e.g. Float or FLOAT. This would solve the problem of `select` clashing with the socket function from the C lib, e.g. : SELECT(p.id, p.name).FROM(p) ... Opinions on this ? Jean-Louis

6 9

[msm] Review
by David Bergman 14 Dec '09

14 Dec '09

Ugh, I have not had time to deal with MSM the last week, which is why I now have to quite hastily report my take on this library. An upside of this haste is that it will reduce my blabbering, which has already irritated a few people in this thread :-) First of all, and probably not a big surprise to anyone having followed this thread: there is already an FSM library in Boost, which has covered my needs in two projects, and quite possibly my needs in most applications. And, in order for me to want to include MSM, it needs to be significantly better, in terms of use (interface) or performance. Alright, let me get straight to the recommended bullet points for a review: - What is your evaluation of the design? It is very good. It actually gives me the same vibes that Boost.Graph does. And those are great vibes. They share part of the meta-programming style (using Boost.MPL) of Statechart, but does so in a better way. There are two important great design decisions: 1. Not coupling FSM logic to the individual states but to the machine itself. This is manifested by the separated transition table or eUML equations. This is conceptually aligned with the mathematical notions of FSM's. 2. The separation between front and back end, enabling multiple API's (of how to define the transitions); this latter point is also used by the eUML interface, which differs widely from the old one (in previous versions of FSM) and that of Statechart. In fact, eUML definitely warrants MSM the label "Xpressive for FSMs" - What is your evaluation of the implementation? Well, two things: 1. It has not crashed ;-) 2. It is very fast. In fact, with most of my examples, using non-nested but guarded machines, with less than 80 transitions, it is around six times faster than Statechart. - What is your evaluation of the documentation? It is simply great EXCEPT for lack of instructions on how to actually leverage the design decision to separate front and back end fully, i.e., helping me to define my OWN front end or back end for MSM. So, I must take the design claim of separability with a tiny grain of salt. - What is your evaluation of the potential usefulness of the library? Great - Did you try to use the library? Yes - With what compiler? Unfortunately only with (Apple's) GCC 4.2.3 on OS X Snow Leopard. - Did you have any problems? None, well, except for my divergence in creating my own meta interface for MSM (and Statechart) and the quirks of Boost.PP :-) - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study. - Are you knowledgeable about the problem domain? I have studied all kinds of graphs theoretically, at a deep level, including DFA's, regular graph theory (and category theory), as well as various computational theories. I have used DFA's in most non-trivial projects knowingly for 23 years but a bit longer unknowingly. This latter point is important: I am quite aware and knowledgeable about the necessity (or benefit) of actually making the state machine of a solution explicit. I am not a big fan of extensions of DFA's, though, such as the state charts found in UML specifications. I.e., I think those just diffuse the beauty (if life is not that clean cut, make it so ;-)) SUM: I demanded much better usability or performance out of the second girl to the party, and MSM covers both those aspects, especially with their eUML interface, so I must vote YES to the acceptance of MSM into Boost. Yes, yes, yes! /David

2 2

Re: [boost] [msm] scalability
by Christophe Henry 14 Dec '09

14 Dec '09

Hi Andy, >Christophe, I'm sorry if my 2 cents won't be relevant since I'm not very >familiar with neither MSM I'm thankful for any help. >The most common reason for compiler slowliness/crashiness that I've seen >came from too deep of a template recursion. Agreed ;-) >I'm not totally sure, but I >think that you're using mpl::vector, which, I think, is a form of a type list. AFAIK, this would be mpl::list. mpl::vector is defined as (for example for vector4): template< typename T0, typename T1, typename T2, typename T3 > struct vector4 { typedef aux::vector_tag<4> tag; typedef vector4 type; typedef T0 item0; typedef T1 item1; typedef T2 item2; typedef T3 item3; ... }; So there is no recursion depth, at least not here. I think the culprit would more likely be the many mpl::fold. Thanks, Christophe

2 1

[msm] eUML guard/action location
by Christophe Henry 14 Dec '09

14 Dec '09

Hi Michael, I just remembered the last reason for the current eUML syntax: CurrentState() + cool_event() = DestState() [Guard()]/(action()) It is that eUML row actions/guards can become quite long (something like adjacent_find_(...) ) and I was having difficulties keeping the rows readable. Concretely, I often had to keep the target state on a line by itself, which was costing a line of my screen. With the current syntax, you can get it easier: CurrentState() + cool_event() = DestState() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) instead of: CurrentState() + cool_event() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) = DestState() For the tranquility of my conscience, are you still sure you prefer the more logical syntax? Christophe

7 7

[chrono] Boost.Chrono version 0.2.1 Bug fixes + updated documentation
by vicente.botet 13 Dec '09

13 Dec '09

Hi, I have updated Boost.Chrono version 0.2.1 with a lot of fixes. Bug Fixes * Replace INTMAX_C by BOOST_INTMAX_C until boost/cstdint;hpp ensures INTMAX_C is always defined. * Define BOOST_CHRONO_HAS_CLOCK_MONOTONIC when BOOST_CHRONO_WINDOWS_API * Commenting invalid operator declarations * Take care of Boost min/max recommendations * complete qualification when defining nested typedef duration on clocks to avoid the following compile error: ./boost/chrono/chrono.hpp:945: error: declaration of 'typedef class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> > boost::chrono::system_clock::duration' ./boost/chrono/chrono.hpp:458: error: changes meaning of 'duration' from 'class boost::chrono::duration<long long int, boost::ratio<1ll, 10000000ll> >' * cleanup of simulated... * warning removal on posix/process_clock.cpp * disable VC++ foolishness * Update Jamfiles to manage with dll * removal of conversion warning in test_duration * manage with MSVC reporting a warning instead of an error when there is an integral constant overflow * Use STATIC_ASSERT specific macro to solve the compile failing issue * Qualify with boost::detail boost::chrono::detail to avoid ambiguities with MSVC Documentation: * Updated documentation. The implementation will eventually work with most C++03 conforming compilers. Tests have been run on Windows with * VC++ 9.0 SP1 Cygwin with * GCC 3.4.4 * GCC 4.3.2 MinGW with * GCC 4.4.0 Getting Boost.Chrono You can get the last stable release of Boost.Chrono by downloading chrono.zip from the Boost Vault You can also access the latest (unstable?) state from the Boost Sandbox. Where to install Boost.Chrono? The simple way is to decompress (or checkout from SVN) the file in your BOOST_ROOT directory. Othesewise, if you decompress in a different directory, you will need to comment some lines, and uncomment and change others in the build/Jamfile and test/Jamfile. Sorry for this, but I have not reached yet to write a Jamfile that is able to work in both environements and use the BOOST_ROOT variable. Any help is welcome. Building Boost.Chrono Boost.Chrono is not a header only library. You need to compile it before use. bjam libs/chrono/build Building an executable that uses Boost.Chrono In addition to link with the Boost Chrono library you need also to link with the Boost System library. Testing In order to test you need to do. bjam libs/chrono/test It will be very kind if someone tested this release with other compilers (Intel) and platforms (Mac) as I'm unable to test them. I expect to been able to test on Linux/gcc-4.1.2 soon. Of course any comments and suggestions are welcome. Best regards, _____________________ Vicente Juan Botet Escribá

1 0

[Spirit/Qi] Sequential-or attribute access in semantic action
by Adam Butcher 13 Dec '09

13 Dec '09

Hi, I am having a bit trouble with the semantic action of a sequential-or parser. Specifically my problem is with accessing the attribute of the sequential-or parser. My first observation is that the documentation at http://www.boost.org/doc/libs/1_41_0/libs/spirit/doc/html/spirit/qi/quick_r… defines the attribute type of (a || b) as tuple<A, B>. Unless I've misunderstood, this must be a typo as they should both be optional (it is never valid for both to be omitted but I would expect that client code be able to determine which out of (a), (b) or (a >> b) were provided.) My real problem is that applying a semantic action to [what I think is] an expression returning a sequential-or parser, results in the _1 referring to the attribute of the last parser on the right-hand-side of the sequential-or rather than the attribute of the sequential-or parser itself. In the following snippet (assume 'start' has an attribute of type S), idxspec = '[' >> (start || (':' >> -start)) [ _val = access_index (_r1,lvalue,_1) ] >> ']'; the function 'access_index' is called with an arg3 of type 'optional<S>' rather than the expected 'tuple<optional<S>, optional<optional<S>>>'. Wrapping the sequential-or expression in a 'repeat' directive as repeat(1)[start || (':' >> -start)] solved the problem but obviously gave me an unwanted sequence (albeit with only one element). The attribute type of the above came out to be vector<tuple<optional<S>, optional<optional<S>>>> as expected. To remove the sequence I created a parser directive called 'identity' following the form of 'repeat' which I have attached. My final rule is now idxspec = '[' >> identity[start || (':' >> -start)] [ _val = access_index (_r1,lvalue,_1) ] >> ']'; which is working fine; the _1 delivers an argument of type tuple<optional<S>, optional<optional<S>>> as required. However, I would have expected this behaviour from the first expression. Is this a a proto issue, a spirit issue or have I completely misunderstood something somewhere? It may or may not be relevant but I am using both spirit.classic and spirit 2.1 in the same file. This is historical and will be fixed in time but I guess it could be important. So far I have had no problems with the combination however. Additional info: I am using gcc 4.4.2, stlport 5.1.3 and boost 1.41.0. Regards, Adam

2 6

[chrono] New Features + Bug fixes + Updated documentation
by vicente.botet 13 Dec '09

13 Dec '09

Hi, I'm pleased to annonce the new version of the Boost.Chrono library. Even if the library is not yet ready for review I wanted to share it with you. The library can be downloaded from the vault http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html. For the moment I'm not able to test it on Windows and Mac platforms. Could you check if there are some regressions on Windows or on Mac platforms? Of course, any comments or suggestions are welcome. If there is a volontary review manager that can start inspecting the library s/he is also welcome :). This library is based on the Beman's boostified version of the probe of concept of Howard. Many thanks to Howard the originator of the library and to Beman to start the boostification. Next follows the contents of the library and the updates of the new version Version 0.1.0, April 29, 2009 Beman's boostified version Features: * The C++0x Standard Library's class common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * Class template timer, with typedefs: * system_timer * monotonic_timer * high_resolution_timer * Process clocks and timers: * process_clock, capturing real, user-CPU, and system-CPU times. * process_timer, capturing elapsed real, user-CPU, and system-CPU times. * run_timer, convenient reporting of process_timer results. Version 0.2.0, December 8, 2009 + New Features + Bug fixes + Updated documentation Features: * Added ratio construction and assignment from an equivalent ratio (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added nested ratio typedef type (LWG 1281. CopyConstruction and Assignment between ratios having the same normalized form) * Added BOOST_CHRONO_HAS_CLOCK_MONOTONIC macro to state if monotonic_clock is provided on a platform. * Added duration operator% (LWG 934. duration is missing operator%) * Complete duration operator* and operator/ Implementation: * Use INTMAC_C to name intmax_t constants instead of LL. * Separate chrono.cpp on # files win/chrono.cpp, mac/chrono.cpp and posix/chrono.cpp to make easier the maintenance on different platforms. * Separate process_clock.cpp on # files win/process_clock.cpp, mac/process_clock.cpp and posix/process_clock.cpp to make easir the maintenace on different platforms. * Added the error_code prototype for monotonic_clock::now for mac/chono.cpp * Fully implement mac/chrono.cpp with error handling. * Take care on POSIX systems when CLOCK_MONOTONIC is not defined. Documentation: * The documentation is written now using quick-book using as base "N2661 - A Foundation to Sleep On". Fixed Bugs * operator/ was ambiguous: Disambiguate duration operator/ * CLOCK_MONOTONIC is not defined with cygwin/gcc 3.4: Disable code when BOOST_CHRONO_HAS_CLOCK_MONOTONIC is not defined. * result of metafunctions ratio_multiply and ratio_divide were not normalized ratios: Use of the nested ratio typedef type on ratio arithmetic operations. * Copy constructor from similar duration masked the defaulted operations: Added duration defaulted implementations Note that the comon_type class should be integrated by Boost.TypeTraits, class ratio will be proposed as a standalone library Boost.Ratio, and the Timer and Process clock part could be proposed as an update of Boost.Timer. Best regards, _____________________ Vicente Juan Botet Escribá

4 11

Re: [boost] [msm] Review
by Christophe Henry 13 Dec '09

13 Dec '09

Hi Darryl, If you don't mind, I'll start by answering the last question, it'll make the rest of the discussion easier. >Now I'm confused. Are you: > >a) Convinced the suggestion is without merit? No. After reading your last mail, I see a bit better, though I'm not sure I can follow all of it. >b) Waiting for a concrete example? Yes! Exactly. >c) Convinced I'm an idiot that can't figure out how to use msm effectively >(in which case, consider this a request for better docs)? No. Sorry if I gave you the feeling the correct answer was a) or b). I don't mind criticism, any of it, justified or not, as long as it doesn't stay vague and instead goes to concrete, argumented points. Vague negative comments bring little to the review and contribute to giving an incomfortable feeling to all participants. Constructive remarks are, on the other side, highly welcome! That's reason #1 for a review. I sometimes, like yesterday, take part in several parallel discussions, so I have little time left for remarks I cannot start anything with. Sorry about it, it's the negative side of the review. I'd be thankful if potentially useful but vague ideas were kept for a more quiet time. So now, to the concrete parts of your remarks. >I genuinely don't see why msm needs to instantiate state objects it owns at all. If this is the point, then it is a solvable problem. Clearly, it doesn't strictly need. It's just a feature, which is in some contexts very useful. The main one is to be able to save some data in the states. This data can then be generically accessed by the generic functors, thus increasing reuse and encouraging clean code. The functor front-end will be your friend in this case. The same with eUML, but it doesn't have to be eUML. The second reason would be entry/exit: >I suggest spelling them enter<state>(machine) and exit<state>(machine) > or machine.enter<state>() and machine.exit<state>(). Of course, this would be a solution. It's actually an interesting one, and if you don't mind, we'll keep for later (see below). Do we agree that it makes the machine slightly less readable? The 3rd reason is state reuse. This brings us to: >What does reuse of a state in msm mean? Interesting question, which is sadly ignored by many fsm frameworks. A case would be when you want to avoid doing the same case again and again. You could then define a state hierarchy, even (gulps) OO-like for this (or better some template policy magic). For example, I personally often add some logging in debug mode, so that I know what happened in my system. The visitor is another good example of it. I hope that after having a look at it, you'll see the interest you can gain from it. You might have easily missed another case in the doc. If you have a look at iPodSearch and iPodSearchEuml, you'll see where I want to go next. To states which implement STL algorithms. You will then be able to write complex algorithms by simply moving some predefined states on a diagram. I plan to call it the STL (State Template Library ;-) ). While this is for the future, I'll need independent, reusable states for it. >No. For the record, in my opinion, the single the worst feature of >statechart is the necessity to use custom reactions to implement some fsm <constructs. This was a subject of much discussion during the Statechart >(FSM) review iirc. I see. Then I probably misunderstood your point. > Can you perhaps explain why flags are needed? Sure. If you look at the statechart doc, you'll see some state_cast. I personally find it not beautiful in my code. It's also hard to maintain when your fsm structure changes. Flags are faster, require no rtti, are more model-oriented as states define themselves their "property" and makes user code easier/smaller to read. It's even supported by eUML for better model-orientation. I wanted to handle the entry/exit discussion separately. Hopefully I managed to convince you why states are useful and their instanciation brings some advantages. Of course, there is a price to pay, though a small one (if without data, 1 byte/state). This is in most cases not a huge cost. I agree there are cases where the price is still too expensive. I also agree, that the one current MSM back-end is not a solution for all problems, otherwise I would have written in stone that there is one backend and we'd be done. The MSM backend is a fully optimized machine, trying to pack as many features as possible at the lowest possible cost. There are however cases, where one would be ready to give up some features like state reuse and generic functors in exchange for reduced costs. For such cases, there is room for a mini-MSM backend (name from Barend Gehrels ;-) ). And in this case, your entry/exit solution appears a viable, interesting one for which I am thankful. When preparing the review, I had several possibilities: - make the current MSM backend, with lots of features, thus proving that the approach of the MPL book was a great one. - make a reduced, smaller cost version, with the certainty of being criticized for not having enough features (see review from FSM) and rending a disservice to the book. - make a 3rd one, more dynamic, which I want to do since a while. - make no review until all possible back-ends are done and make everybody wait at least one more year. Do we agree that solution 1 seems the more logical? I hope we managed to find a common ground and that a fruitful discussion can take place. Christophe

2 1

[test] new feature - colored output
by Gennadiy Rozental 13 Dec '09

13 Dec '09

Hi, I've implemented a change in regular human readable log and report outputs. You now have an ability to tell the unit test framework to produce colored output. New boolean runtime parameter is added: Environment variable: BOOST_TEST_COLOR_OUTPUT Command-line long: --color_output Command-line short: -x. By default the feature is disabled. Any comments are appreciated. Specifically: how does this feature works in different environments and if there is a way to make MS compiler to work properly (gcc on windows works fine in Windows shell, while msvc build does not) Gennadiy

1 0