- Boost - lists.boost.org

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