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

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