- Boost - lists.boost.org

Crazy Borland/Codegear long long behaviour?
by John Maddock 30 Nov '09

30 Nov '09

I'm having a load of trouble getting Boost.Integer to play nice with the Borland/Codegear compilers, for example given: void print_val(long long l) { std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFF00000000LL) >> 32); std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFFLL)) << std::endl; } And then: static const long long MaxValue = SCHAR_MAX; static const long long sll = _LLONG_MAX; const long long cll = _LLONG_MAX; long long ll = _LLONG_MAX; BOOST_TEST(MaxValue <= ::boost::integer_traits<boost::long_long_type>::const_max); // fails BOOST_TEST(MaxValue <= _LLONG_MAX); // passes BOOST_TEST(MaxValue <= sll); //fails BOOST_TEST(MaxValue <= cll); // fails BOOST_TEST(MaxValue <= ll); // passes print_val(_LLONG_MAX); // OK prints 7fffffffffffffff print_val(ll); // OK prints 7fffffffffffffff print_val(sll); // Oh no, prints ffffffffffffffff print_val(cll); // Oh no, prints ffffffffffffffff So as soon as a long long is declared const (whether static or not) it seems to be incapable of actually holding a sensible value!! Anyone got any ideas what's going on or any workarounds? Thanks, John. PS I'm still using Borland-5.8.2, but judging by the test matrix results the latest versions have similar issues.

3 4

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Felipe, > Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? I'm not sure I understand the question. Please excuse (and correct) me if I miss the point. You mean, why not remove action and guards from the transition table and delegate all handling to a state (source or target)? Well, you can do this if you want, as there are already such methods defined, on_entry and on_exit. So theoretically you could use a _row, which has only source state / event / target state and delegate all work to on_entry and on_exit. It would work in some cases. However, you could also have the following: _row< State1, event1, State3>, _row< State2, event2, State3> and maybe _row< State1, event3, State4> Now you have a problem in State1 and 3. State3 can be the target of 2 transitions from 2 states and State1 can be the source of 2 transitions to 2 states. Where to add the common handling? It'll fatally end with some if/else on the event type. If you carefully choose your on_entry/exit, action and guard you will avoid this and get cleaner code with on_entry and on_exit (called each time a state is entered/left independently of the event) doing the work common to all transitions and the action/guard the work specific to one event. To be honest, as on_entry and on_exit are templatized on the event you could use SFINAE to handle event-specific tasks and get rid of actions and guards anyway but SFINAE isn't everybody's tool. If you feel good with them, then sure, why not? > That should get the transition table a lot smaller and maybe even > faster for not using a pointer (though speed-wise, that's a wild > guess). Luckily Msm allows you both ways :) You have a valid point with your wild guess. I'm unsure myself why but if you use the functor-based frontend, which is doing strictly the same, you will see some speed gain (about 20%) compared to the pointer version. I hope I could answer the question satisfactorily. Regards, Christophe

1 0

[config] BOOST_CONSTEXPR and C++0x constexpr
by Vicente Botet Escriba 29 Nov '09

29 Nov '09

Hi, I was wondering if it will be useful to define BOOST_CONSTEXPR as follows #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #else #define BOOST_CONSTEXPR constexpr #endif and if it is correct to use it as for example static BOOST_CONSTEXPR Rep zero(); If this is the case, could this be added to Boost.Config? If not, what I'm missing? Best, Vicente -- View this message in context: http://old.nabble.com/-config--BOOST_CONSTEXPR-and-C%2B%2B0x-constexpr-tp26… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

GGL Review Results
by Hartmut Kaiser 29 Nov '09

29 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

2 1

Boost.Integer makeover
by John Maddock 29 Nov '09

29 Nov '09

Folks, Boost.Integer has had a quick makeover in Trunk - starting from the "last known good" release - and then fixing all outstanding issues filed since that release. New-look docs are visible here: https://svn.boost.org/svn/boost/trunk/libs/integer/doc/html/index.html I'd really appreciate it if: * Folks can read through the docs looking for the usual SNAFU's * Test the code on whatever exotic compilers/platforms you may have available. Some random thoughts that occurred to me while doing this: * I don't see the point of the static-min-max templates - there are 4 of them when 1 would probably do (template <class T, T val1, T val2> static_min_max), but in any case the implementation is almost too trivial for a separate template to make sense? * I haven't added mpl-compatible templates yet as per https://svn.boost.org/trac/boost/ticket/1224, is there demand for this? Cheers, John.

9 22

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Darryl, > I found code size of stripped executables compiled with gcc 4.3 to be > quite reasonable - especially at high optimisation levels, although > still about twice the size (the docs state) VC9 achieves. I'm assuming > that the large sizes mentioned are simply due to the generated files not > being stripped. Correct. Stripping will greatly improve the executable size, eventhough it'll still be more than what VC produces. > I was unable to compile the euml example - I haven't investigated the > errors yet. g++4.3 should manage this. Please contact me if you need any assistance. > I had hoped to pick what I'd consider a realistic use for a high > performance FSM tool (a low level comms protocol) and do a basic mock-up > implementation using MSM. However a reasonably typical layer 2 protocol > (LAPD) has 8 states and a transition table that in a condensed form (row > for each event, column for each state with the column describing the > actions and transition) is 10 pages long, so it is pretty obvious I > can't do that... Its likely that a bit of refactoring could bring the > total number of transitions down somewhat using composite states, but > the number of events to be handled exceeds the typical limits for number > of transitions so this still seems hopeless. 8 states doesn't seem like a huge number to me. How many transitions are we talking about? I'm not so sure that it can't be done, especially as you're using g++ 4.3 which is the best compiler with Msm. I managed to compile 100 transitions in about 40s (while running in a VM). I'm pretty sure the compiler can manage more. Supposing that every of your 8 states has a distinct transition to every other state including itself it'd be 64 transitions, which your g++4.3 will easily manage. You can even allow yourself to have more than one to every state. In the very worst case, if you had so many events (say more than 100) that g++4.3 itself would crash we could easily group events with the same source and same transition inside the same event and reduce the number of transitions to what g++ would manage. > At this point, I really like what msm is trying to do - it just doesn't > quite do it for me in a practical application. Maybe that just means > waiting for Moore's law and compiler technology to catch up? Well, it'd be a solution but hopefully we won't have to wait yet ;-) Seriously, I'd be happy to work with you on this one. It'd be quite fun and I'm pretty confident it can be done if I'm right about my assumption on the number of transitions. Regards, Christophe

2 1

First results using Comeau C/C++ compiler
by Mateusz Loskot 28 Nov '09

28 Nov '09

Hi, After quite some time of trying to build Boost, especially Boost.Test, using Comeau C/C++ frontend with GCC 4.x on Linux, I've started to get some promising results. During this investigation I was juggling number of fixes and patches [1] and eventually I found quite surprising solution. Yesterday, while reading signal.h and other headers to find out how to get signals features compiling for Boost.Test library, I came across an interesting macro which seems to be a passkey to the world of GNU C Library for Comeau toolset :-) It is _GNU_SOURCE macro [2]: "If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions." Defining this macro seems to solve all issues I reported [1] so far. BTW, I've sent request to Comeau team for their opinion about usage of this macro with Comeau C/C++ frontend. Hopefully, it will be assumed safe to use, then we've got solution for all/most of the problems. Second due to the fact Comeau does not support linking as shared, I had to explicitly request to link Boost.Test binaries statically. I attach patch for Boost.Test Jamfile.v2 files adding the macro and configuring static link for como toolset. Let it be an example showing what kind of changes/options are needed by como toolset to build Boost.Test binaries. I haven't tried, but I suppose it's safe to assume that the same changes are needed to build other libraries like Asio, Program Options, and others. I'm going to find it out. To summary, there are two required changes in build configuration to enable como toolset, so far. So, what is the best approach to incorporate those two settings to other libraries (only those when it's needed): * Should I hack all Jamfiles where those changes are needed? * Or, it would make sense to set these options for como toolset, by default? * Where <link>static should go? To Jamfiles or nowhere and static linking should be explicitly enabled as bjam argument? I also tested: como --v2 link=satic Gennadiy, I'm sorry for making quite a mess in Trac by reporting number of tickets and submitting number of patches which eventually turned out to be unnecessary. It took me number of iterations to sort it out and I was subsequently recording my discoveries. [1] - int64_t/uint64_t https://svn.boost.org/trac/boost/ticket/3548 - snprintf, vsnprintf https://svn.boost.org/trac/boost/ticket/3558 - POSIX features (e.g. signals.h) https://svn.boost.org/trac/boost/ticket/3662 [2] _GNU_SOURCE http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[flyweight][#3658] Dependency on static initialization/destruction order
by Andrey Semashev 28 Nov '09

28 Nov '09

Hi, I've created the ticket #3658 [1] on the flyweights library. The ticket is about Boost.Flyweight depending on the static initialization/destruction order, which can lead to application crashes in some cases. The library does provide certain tools to work around the problem [2], but these tools are only usable in the most obvious cases and do not solve the problem in its root. What I have proposed in the ticket is to implement reference counting in the flyweights, so that the flyweight value is only destroyed when no flyweight handles refer to it. AFAIK, Boost.Flyweight already has reference counting, so the work is only to shift value owning from the holder to the flyweights. Comments are welcome. [1] https://svn.boost.org/trac/boost/ticket/3658 [2] http://www.boost.org/libs/flyweight/doc/tutorial/technical.html#static_init

2 2

[msm] Review
by Juraj Ivančić 28 Nov '09

28 Nov '09

Hi all, This is my first attempt at reviewing a library, so please bear with me. - What is your evaluation of the design? I think that MSM is brilliantly designed and offers a great deal of advantages over StateChart (SC). The part I like the most about MSM compared to StateChart is the way state machine is defined. Transitions are not a part of state, but are listed in the state machine itself in the transition table. Although it is generally a bit more difficult to write the MSM transition table than its SC counterpart (especially when resolving transition conflicts) I found it very rewarding. It gets difficult to get a clear picture of SC state machine when it gets large - especially when many custom_reactions are used. Also, when composites are used in SC, it is difficult to figure out the hierarchy. IOW SCs distributed sm definition makes it very hard to get a clear picture of what is going on without a pen and paper at hand. Please do not think that I have anything against SC - I have been using it since it became a part of boost and still intend to. It has saved me from writing my own feeble double-dispatch implementations and saved me a lot of time and nerves on more than one occasion :) MSM does lack some of the SC functionality. There is no state-local storage in SC sense, as all states are constructed when main state machine is constructed. This can be easily worked around though. It is impossible to stop event from propagation (SCs discard_event()) without actually changing state. You cannot conditionally defer an event. There seem to be some differences on how event deferral is handled when composite states are used. This part is a still bit mysterious to me. A MSM feature I really like though is that on transitions both source and target state exist. This allows storing transition event data in the target state in case this is needed. This could not be done in SC because on target state construction event that caused the transition is lost. The latest MSM 2.0 offers separation to front-end/back-end. This is potentially a very powerful feature which makes me hope that some day in the (nearby) future I'll be able to create/modify a state machine in some GUI app and have it automagically transformed into high performance C++. The author seems masochistic enough to try to tackle this. :) - What is your evaluation of the implementation? Reading the implementation quickly causes a severe headache. - What is your evaluation of the documentation? It found it well written and containing useful examples. The first part is pretty much quick-start guide, and it gets more and more complicated as you read along. I found it lacking info on some border-line cases. It does however often reference UML state machine standard, which I am unfamiliar with, so this could be my fault. Aesthetically - I'm not a great fan of one big fat html documentation and would prefer to have it broken down and cross-referenced as most boost libraries docs are organized, but this is just a minor issue. - What is your evaluation of the potential usefulness of the library? I find it very useful in its current state. Furthermore, I gathered that the author is planning on adding new front-ends (back-ends?) thus making it even more so. - Did you try to use the library? With what compiler? Yes, with MSVC9. - Did you have any problems? As it often is with metaprogramming libraries, error messages leave much to be desired. I had to figure out how to use mpl::vectorX with X>50. This ancient post helped: http://tinyurl.com/yf7e9mo It wouldn't hurt to have it included in some way in the docs. There are some behind-the-scenes vector unions in MSM, so it is possible that you will require, e.g. mpl::vector60 without ever directly using mpl::vector with more than 40 members. The exact formula for determining max needed vector size would be useful. MSM state machines compile for ages. I also managed to find a bug or two and some documentation errors. I sent reports to the author and he had them resolved in literally hours. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? As in-depth one can get without looking under the hood. Thorough read of the docs, playing around/testing and nagging the author :) - Are you knowledgeable about the problem domain? Not especially. I spent a great deal of time using StateChart and have played with the MSM 2.0 for the last couple of weeks (since the announcement on this list). I have also recently ported a pretty complex state machine (~15 states, ~80 transitions) from SC to MSM. And finally, yes, I think that this library should be accepted as a part of boost.

1 0

Interest in Devector implementation?
by christopher hopman 28 Nov '09

28 Nov '09

So, I have been working on a devector implementation for the last week or so (see https://svn.boost.org/trac/boost/wiki/soc2009#Boost.Devector) There is some stuff that still needs to be done, and some testing that is still needed, but I thought I would check if there was interest in such a thing. The implementation is basically a standard deque implementation with one addition. That is, there can be allocated "chunks" both before and after those in use. This leads to a couple of advantages for users. First, in many use cases, devector is faster than deque because it will have less allocations. For example, when used strictly as a queue, the regular deque has a number of chunk allocations linear in the total number of elements inserted in the queue, devector has allocation linear in the maximum elements in the deque at one time. When used as a stack, a particularly bad case can occur with a normal deque implementation, the case where the top of the stack switches back and forth between two chunks. Second, this allows users of devector to reserve space on either side of the structure. This does not give the same efficiency boost as vector::reserve, but, possibly more important, it allows for stronger exception guarantees and for better guarantees about when iterators are invalidated. Another benefit of devector is that chunk size is not a compile time constant. In fact, chunk size is not even required to be constant over the lifetime of a given devector. Also, devector iterators allow lower level access than std::deque as described by Matt Austern ( http://lafstern.org/matt/segmented.pdf) Support for in-place construction (described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2212.html) will become available with c++0x's emplace_back(). Though I expected that std::deque would have a slight performance advantage due to its compile-time constant chunk_size, early tests have actually shown devector to have a slight advantage even in cases where it has no advantage from not deallocating unused blocks. My guess is that this is due to std::deque needing to do more work to maintain its invariants in the face of exceptions. Again though, that is just some simple early testing that I did. The current implementation does not actually allow changing chunk_size (though this is actually a matter of like 5 LOC), nor does it give the segmented iterator access (again a simple addition). Code is available at http://pages.cs.wisc.edu/~hopman/devector/ (along with code that tests most of the std::deque interface). -Chris Hopman

1 0