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

[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

[serialization] polymorphic archives + boost_class_export generates linker errors
by Christoph Heindl 28 Nov '09

28 Nov '09

Hi, I've posted this with no luck to the boost-users mailing list: the attached example [1] generates a couple of linker [2] errors on msvc 9.0 / boost 1.40.0 all related to missing archive_serializer_map symbols. when switching from polymorphic archives to corresponding non-polymorphic archives the attached example runs fine. It seems that the usage of BOOST_CLASS_EXPORT in conjunction with polymorphic archives triggers the linker error. I tried to add explicit template instantiations, such as [3], for the missing types to boost archive, recompiled boost and was able to get rid of the linker error. The problem then, however, is that the example fails at runtime with an assertion that a type-lookup did not succeed. So I guess adding the explicit template instantiations was not the correct approach. Is this a bug? Can anyone confirm this issue? Best regards, Christoph

4 10

[random] documentation rewrite
by Steven Watanabe 28 Nov '09

28 Nov '09

AMDG I'm in the process of updating the Boost.Random documentation. I've put what I have right now at: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The content is mostly the same as the current docs, although I've filled in some missing pieces and fixed some of the more egregious out of date docs. Any comments, criticism, etc, are welcome. In Christ, Steven Watanabe

5 10

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9

Removing LEDA adaptors from Boost.Graph
by Jeremiah Willcock 27 Nov '09

27 Nov '09

Are there any users who are using the LEDA interfaces to Boost.Graph? There are several tickets filed against them but the tickets are all years old. Is it safe to remove them? Do they need a deprecation period first? -- Jeremiah Willcock

2 2

[LibrariesUnderConstruction]Mirror - update
by Matus Chochlik 27 Nov '09

27 Nov '09

Hi, I would like to ask the admins to update the info about the Mirror library on the LibrariesUnderConstruction page in particular to add the links to the C++0x version of Mirror on sourceforce: http://sourceforge.net/projects/mirror-lib/ and to add a link to the online docs for the C++0x version: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ TIA ________________ ::matus_chochlik

2 2

[LibrariesUnderConstruction] Boost.Numeric_Bindings
by Rutger ter Borg 27 Nov '09

27 Nov '09

Hello all, I see the Numeric_Bindings library is missing on the LibrariesUnderConstruction trac page. This library is under development since 2002. Herewith a short description of the library. Boost.Numeric_Bindings is a C++ library for numeric computing. It is a generic layer between data containers and linear algebra algorithms. For the data container part, it supports both compile-time statically sized and run-time dynamically sized vectors, matrices, through a traits system. Currently it includes traits for C-arrays, for standard vectors, for uBLAS' containers, Eigen containers, TNT, Boost.Array, to name a few. It offers compile-time inspection, iterators, and views on all mentioned containers. For the algorithm part, it provides a C++ interface to algorithms offered by BLAS, LAPACK, and more. This covers algorithms from most vendor-provided math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML, NVidia's CUDA, etc.. The "stable" release is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/ The current development version is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Questions and/or comments are welcomed. Thanks, Rutger

3 4

Compiler warnings from Macs, IBM acc, Borland, Comeau, Metroworks, et al - are they a Problem?
by Paul A. Bristow 27 Nov '09

27 Nov '09

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (bottom of the page) has a collection of suggestions for 'quieting' warnings on MSVC and GCC, but no information on other compilers yet. Can users of these compilers please 1 Assert that they never have a problem with unhelpful compiler warnings from Boost stuff, or 2 Send common warnings and suggestions for dealing with them by suppressing or by 'fixing' the code (so that I can add to the guidelines. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Boost.Array Maintainer
by Dean Michael Berris 27 Nov '09

27 Nov '09

Good day everyone, Does anybody already maintain Boost.Array? I see quite a number of patches and "todo" tickets and am wondering whether someone should be taking care of such a crucial piece of the collection. If there isn't anybody willing to maintain Boost.Array I don't mind looking after it until someone else does. Question: does someone have to be a maintainer of an existing library (or author of one of the accepted libraries) to become a maintainer of an existing (orphaned?) library? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

6 6

[unordered] 1.41.0 unordered_map doesn't allow declaration with incomplete type.
by Jon Spencer 27 Nov '09

27 Nov '09

The new version of the unordered library doesn't allow you to declare an unordered map with an incomplete type. The following code would compile with the old version but not the new: struct a; struct b { boost::unordered_map<int, a> c; }; Or the more useful: struct d { boost::unordered_map<int, d> e; }; As far as I know these constructs are allowed with the other standard containers. The problem show up in "boost/unordered/detail/fwd.hpp" with the the declaration of value_base, which requires that the value_type of the map not be incomplete at declaration time. Jon.

2 1

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 27 Nov '09

27 Nov '09

Thomas Klimpel wrote >> Some of the accepted boost libraries seem to >> receive only minimal maintenance by their original authors, >> and making it easier to contribute >> libraries to boost would probably only increase the number of >> libraries in minimal maintenance mode. So I >> guess the recent efforts to encourage the boost >> community members to spend some maintenance time on >> libraries they haven't authored is exactly the >> right thing to do for the current situation. Agreed, that is a problem, but different from the one I'm trying to emphasize here. >> I'm not sure whether you want to highlight the excessive >> quality criteria for acceptance into boost here, >> or the lack of review managers. Probably more the lack of review managers. I wish more of the core boost library developers would step up and mentor new library submissions. Not sure why they don't. Its actually quite fun. >> But the sandbox is actually quite a nice place to flesh out a >> potential library. And there is quite a number of libraries in the >> sandbox that are currently in active flesh out mode, and will stay in >> that mode for quite some time. The sandbox is just a nice place to dump a library. Most are quickly abandoned and receive very little attention. Why? Exposure, they need exposure. Having a place in for the promising experimental libraries to to get some exposure, and where the authors can toot how great their library is would be fun for all involved. That's why I come to boost -- for an exchange of ideas and to be inspired by others. The sandbox does not do that for me. Having libraries in the experimental branch would focus everyone attention on the upcoming libraries. Nothing can focus a library's authors attention if he knows that his library is getting exposure and being noticed by others. I played a part in developing the the review queue, but it never changes. I don't like how its evolved and its stuck in the status quo. The review queue does not give enough exposure and its now taking about a year to get your library reviewed. Uggh. Actually, I would like to see that the review queue is abandoned and replaced with the experimental branch. The only important review would then be when to decide when the library has matured enough to move it from the non-stable to the stable branch of boost. The review wizards would manage this process. It would be much more fun for all involved. The current system is stale and not inspiring the level of innovation that I believe is possible here.

15 21

Re: [boost] Review Queue Needs Attention
by Tom Brinkman 26 Nov '09

26 Nov '09

>> judging by the review schedule (almost no review managers), that would mean >> boost isn't very interested in new libraries in general. It would seem so. >> I would recommend that authors try find a review manager before they request a review. Review managers are generally recruited from people that already have a library that has been approved in boost, that means you luke (hint). The wizards could open it up to anyone. Its been considered, but rejected in the past. I would like to focus attention on something different. That would be creating a "non-stable" branch of boost, where the proposed libraries would live for a while, get some exposure. Since most libraries are header file only, it should not be a problem. While not all will compile on all platforms, and certainly not have perfect documentation, it would be a place for future boost authors to elicit feedback. The experimental libraries would not affect the core boost libraries in any way. I'm absolutely convinced that it would encourage lots more participation. There is so much more to do, we haven't even scratched the surface of what is possible. The core boost authors have put in place a wonderful place to come and share ideas, but we are letting it flounder. Ugh.

7 6

Failures on SPARC64 [Was [1.41.0] Beta 1 available]
by Alexander Churanov 26 Nov '09

26 Nov '09

Folks, I've tried to re-built 1.41 and 1.39 using the suggested patch. The libraries build successfully, but a single test ( "spinlock_try_test" ) for smart_ptr fails. Please, examine the issue and provide with solution or workaround. I've created a ticket on that - https://svn.boost.org/trac/boost/ticket/3678 Alexander Churanov, maintainer of devel/boost-* for FreeBSD

1 0

[Review] GGL review starts today, November 5th
by Christophe Henry 26 Nov '09

26 Nov '09

I apologize in advance for not being able to bring a complete review due to my lack of knowledge of the problem domain, but I hope to bring a few elements. I also apologize in advance for the unfair treatment to Luke that I was not able to do the same about Polygon due to my lack of time at the point of the Polygon review. *What is your evaluation of the design? 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 found only 2 points to criticize: - linestring has std::vector as basis class, and therefore it should be clearly documented that this class is not made to be derived from. - most or all of geometries classes have no virtual destructor and thus this should be clearly documented or changed. Better even would be to give the user choice through a policy. *What is your evaluation of the implementation? The code is clean and nice to read and I found it pretty easy to understand (apart from the deep geometry stuff of course). *What is your evaluation of the documentation? The examples are nice to read, the rest of the doc is a bit light and would probably not let me do more complicated stuff. I'd love an example about every feature. *What is your evaluation of the potential usefulness of the library? For me quite big. I'd probably never need the advanced features but the simple ones would solve my biggest problem, which is how to avoid ever having to implement something like this myself, which I would probably never manage anyway. About the completeness of the library, I am not able to judge it and trust the more experienced reviewers. *Did you try to use the library? With what compiler? Did you have any problems? I compiled several examples with VC9 + VC10 beta2. Both compiled without warnings level 3. The VC10 code analyser found a few points (reported to one the library writers), which I suppose are minor. Interestingly, the analyser did not find a bug in the linestring example, which happens only with VC10. This bug needs fixing but must be pretty simple to correct. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours reading and running the examples and checking the analyser and compiler level 4 warnings. I also spent 2 hours looking at the code. *Are you knowledgeable about the problem domain? Not at all. I'm simply looking for a library in case I ever need to do something in this domain. *Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. YES, eventhough I wouldn't count my own opinion as a full vote due to my lack of domain expertise. I like: - some nice features I understood like the linestring and polygon - the fact that the code is clean (meaning lots of care has been spent on it) and that the authors are responsive, which is a sign that the library will be well-maintained. - the examples I like less: - the documentation which gave me the frustrating feeling I missed most of the cool stuff and needs some warning messages for the problems I cited above. Best regards, Christophe Henry

5 7

GGL Review
by Gordon Woodhull 26 Nov '09

26 Nov '09

I believe GGL should be accepted as Boost.Geometry My main concern is the number of things which are incomplete. Certainly the obvious lackings such as missing boolean operations, clockwise versus counterclockwise polys, closed versus open polys, should be fixed or rationalized before this is released. It sounds like Barend and friends have promised to complete all of these things. I hope Hartmut is willing to manage a mini-review when the authors believe this is ready for release, to make sure that all concerns raised in the first review have been addressed in some way. I asked the same for Boost.Polygon; I think it is even more important here because the scope is much broader, whereas Polygon seems to have covered integer polygons pretty well. Then there are a lot of things which the authors claim are possible but which will probably need to be contributed by others: triangles, 3D, ellipses, splines, homogeneous coordinates ... I am confident that the authors will help these things to happen, and I have no reason to think that they won't fit in. OTOH it may be that some concepts do not fit in; for example, it's not clear to me whether or not the 45/90 degree concepts of Boost.Polygon are orthogonal or skew. It is going to take some time for everyone to figure this out, and I think that Boost is the right forum for this discussion. I hope that future domain libraries are developed as extensions to GGL, but it may be that they demand their own frameworks. I think it's naive to assume outright that all can fit into one framework, but I am optimistic. Both libraries allow external data structures and concepts to be adapted to them, and so the first step in determining their commonality will be to write those adapters. I'm pleased to see that Luke has already started this effort from his side. Oh, for concept maps! My two cents on floating point robustness: in many applications, the use of geometrical computations is "one-way": there is a model, some operations are applied to produce coordinates, which are then output. This is mostly true in the domain I wish to use this library, graph drawing (network visualization). If the results are not fed back into the system, floating point robustness is not going to be an issue. While some work could probably be done here, I think it is OK that users must understand the issues with floating point for best results. I'd like to see GGL run with Boost.Polygon's robustness tests and randomly generated efficiency tests. It sounds like this has already begun. A couple of people asked for GIL examples. This would require a line and curve bitmap rendering library, which would be a really cool addition to Boost. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== Sorry I have not had time to conduct a more thorough review. I have spent a couple of hours looking at the documentation and examples, and have read the review discussion thoroughly (another five or six hours). I've also followed most of the discussion in the past. ===== What is your evaluation of the design? ===== It seems very well thought out, for the domain which has been explored so far. The only concern I have (which I haven't thought out thoroughly) is the absence of hierarchical concepts. IIUC a new class must subscribe to all concepts, not just the most derived. This seems like it might get onerous when there are a lot more concepts / if the granularity is reduced. ===== What is your evaluation of the implementation? ===== From the discussion and from the presentation at BoostCon, I understand that not everything which is described is implemented, and everything which is implemented does not completely live up to the standards which the library sets. Again, I think these discrepancies should be resolved either by implementation or by narrowing the scope and documenting. As is, it's rather confusing. ===== What is your evaluation of the documentation? ===== I'd like to see an overview of the concepts - there are the detailed descriptions in doxygen but nothing written in English. :-) Doc seems mostly to consist of very technical rationales, which are good, and then examples, which are also good. But not much overview. I think doxygen is convenient for developers but not very useful for users, because of the high structure/content ratio. ===== What is your evaluation of the potential usefulness of the library? ===== Very useful. ===== Did you try to use the library? With what compiler? Did you have any problems ? ===== Not yet. ===== Are you knowledgeable about the problem domain? ===== As others have pointed out, it's not clear the domain is well- defined. I'm not familiar with GIS. I have developed visualization and graphics applications which need 2D geometry for more than a decade, and this looks like it will serve many of my needs. I wish both this review and the Polygon review had been delayed until the libraries were more mature. As it is, we're going on trust that the promise will be fulfilled. But I understand that there are social and real-world constraints as well as technical and I think it's best that both libraries are accepted a little early so that the community has a chance to cooperate in lifting the concepts. I am very happy to see the authors resolving some of their differences. There's a long road ahead... Cheers, Gordon

2 2

Re: [boost] [Serialization] warnings and maybe a 'bug'
by bernard cupic 26 Nov '09

26 Nov '09

Is it possible tha the problem is in the shared_ptr_helper.hpp file in the line 114: Â Â Â template<class T> Â Â Â struct non_polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance(); Â Â Â Â Â Â Â } Â Â Â }; If you compare it with the following code (same file, just below the upper code): Â Â Â template<class T> Â Â Â struct polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance().get_derived_extended_type_info(t); Â Â Â Â Â Â Â } Â Â Â }; it smells like a bug to me. Best regards. -- Bernard Cupic Software Development Manager USCS d.o.o. Flaciusova 1, HR-52100 Pula e-mail: [1]bernard.cupic(a)uscs.hr tel/fax: +385 52 380 687 References 1. mailto:bernard.cupic@uscs.hr

1 0

[xpressive] Significant compiler warning
by Ian Emmons 26 Nov '09

26 Nov '09

I have a program that uses Boost.Xpressive. When compiling this code on the Macintosh with the darwin-4.2.1 toolset, I get the following compiler warning: .../boost_1_41_0/boost/xpressive/traits/cpp_regex_traits.hpp:84: warning: left shift count >= width of type Here is the offending line of code: umaskex_t const highest_bit = 1 << (sizeof(umaskex_t) * CHAR_BIT - 1); The problem (if my thinking cap is screwed on correctly) is that the 1 that is being shifted is of type int, and is not converted to the target type of umaskex_t until after the shift operation. I believe that this should be changed to the following to avoid highest_bit being set to zero: umaskex_t const highest_bit = static_cast<umaskex_t>(1) << (sizeof(umaskex_t) * CHAR_BIT - 1);

2 1

[Exception] SFINAE use breaks Borland in Trunk
by John Maddock 25 Nov '09

25 Nov '09

Boost.Exception is currently failing for Borland compiles with for example: http://tinyurl.com/ycu779q The issue appears to be use of SFINAE like techniques without a BOOST_NO_SFINAE fallback. The problem here is that since Boost.Exception gets pulled in by almost everything, we need it to be lightweight and well supported, otherwise the rest of us are stuck even if we want to continue to support the older compilers :-( Thanks! John.

3 4

Re: [boost] [msm] scalability
by Christophe Henry 25 Nov '09

25 Nov '09

> a library that I plan to submit to boost causes > 50 s compile times even for simple examples, > so do you have any recommendations on where to start? There is a template profiler from Steven Watanabe, you could start there: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… > my library invokes a lot of Boost.Serialization and some MPL/fusion code, > so I'm not even sure if I can do anything about that within my library. As you use some MPL, you should check all your algorithms for complexity (especially if you use many mpl::fold). A quadratic complexity in a metaprogram will hurt you pretty fast. I had the feeling that SFINAE also hurts you quite much on some compilers. HTH, Christophe

3 2

Idea: Boost Software Foundation?
by Dean Michael Berris 25 Nov '09

25 Nov '09

Hi Everyone, I have been watching the passionate debate about how to go about achieving the following: 1. Make Boost less monolithic and more open to contributions 2. Make Boost easier to distribute and support 3. Make Boost better but less complex and more manageable Someone mentioned the "incubator" idea and now that I think about it more I think this model works very well for Boost. Let me try to draw some parallels between the Boost C++ Library and the Apache Software Foundation: 1. As a project, Boost and Apache try to (and I'd like to say both do) deliver high quality open source components under a liberal and commercially friendly license. Boost has many sub-projects that are worth naming like Boost.Build, (Boost.?)Quickbook, BCP, and Boost.Jam (although a little stagnant IIRC). Maybe treating other libraries as sub-projects that have a publicly-accessible and easily "forkable" repository would be a good thing. Git and Github come to mind. 2. As a software distribution, Apache has decentralized the release management of the libraries and software projects under its umbrella. This means sub-projects can depend on specific version releases of other sub-projects instead of making sure that there's only one release that bundles everything together. 3. As an entity, the only difference I see between Apache and Boost are that: * Boost is a volunteer-backed, non-foundation backed entity, while the Apache Software Foundation is legally a non-profit non-stock organization. * Boost does not have resources that "it" owns while ASF employs people in different capacities. * Although the Boost Software License and the Apache Software License are both OSI approved, there seems to be no legal team dedicated to ensuring that the terms of the licenses (and the contributions made by contributors) are "properly" applied. I don't want to instigate an "uprising" here, but I for one would like to see a Boost Software Foundation whose main task would be to further the Boost-licensed projects, and lends its name to signify the high quality and organized peer-reviewed and meritocracy-driven C++ application and library development for the betterment of the C++ language and vendor/implementor/library-author community. And then to see the Boost Software Foundation have a formal means of having projects "built for Boost-inclusion" be drawn into an umbrella project to become "incubated and developed with Boost Quality in mind". If I understand how Apache projects are run, it appears that: * A project manager is assigned/nominated by the community to represent a sub-project in the bigger Apache project. * There are official developers who have commit access to the repository; developers who want to become an official developer of the project signs a contributor agreement which states in no uncertain terms that they agree that their changes committed to the repository are licensed under the Boost Software License. * To become a "committer" to the project, you have to be asked by official developers or nominated by peers based on your contributions in the form of patches or pulls from your "fork". I do not see why this model should not work for Boost granted that some people already take the libraries they maintain as their full-time (or almost full-time) projects (Boost.Thread, Boost.Spirit/Fusion/Phoenix). And because of the decentralized nature of this model, the only "review" that has to happen is whether a sub-project should be incubated, and whether projects in the incubator are deemed "mature" enough to become full-blown Boost.* projects. One other idea about distribution: the biggest hindrance I think is the lack of a "centralized" or "repository-like" location from where released versions of a library can be pulled easily. Haskell has Cabal, Perl has CPAN, Debian has official 'apt' repositories, Ruby has multiple Gem foundries, Python has the Cheese shop (?). Although SVN is centralized by nature, it's not the best means of distributing releases that can be kept in-sync from various locations. Maybe the Boost community might be able to come up with a similar solution and contribute towards building a C++ package-based solution to distributing libraries in a cross-platform and scalable manner? I hope this helps. I personally have no idea how to get a Boost Software Foundation up and running but I do want to participate in that effort in a substantial manner if other people think that would be a good idea and would like to make it happen too. Have a good day everyone, that's my $0.02 worth. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

5 11

[thread] Bug sprint: #2100 thread fails to compile with -fno-exceptions
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Ticket description: "The thread component fails to compile with GCC when -fno-exceptions is specified. The attached patch allows the libraries / tests shipped with boost 1.35.0 to compile. There didn't seem to be a better option to make g++ happy than to just #ifndef out the catch(...) block, as it would otherwise complain about the throw in the block." from https://svn.boost.org/trac/boost/ticket/2100 Hi, I think that Boost.Thread has not been designed to work without exception. What would be the behavior of the application if we remove just any throw statement? In order to achieve the reporter goal, we should need to add functions returning a return code. IMO this is out of the scope currently. Thus I propose to close the ticket. Anthony, do you agree? Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint%3A--2100-thread-fails-to-compile-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

[thrad] #3179 Sleep with local_time
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, Anthony this ticket have a simple solution. https://svn.boost.org/trac/boost/ticket/3179 Nest follows my contents Replying to anonymous: When calling sleep with an absolute time, it sleeps about two hours instead of one second in code similar to the below example. ptime now = second_clock::local_time(); this_thread::sleep( now + second(1) ) After a lot of headache I think that might is due to a missmatch with utc and local time. Please make it possible to sleep until a "local time" (local time zone) and write something about it in the documentations, I haven't found anything special about which type of time should be used. Changed 5 days ago by viboes ¶ The this_thread::sleep prototype is template<typename TimeDuration> void sleep(TimeDuration const& rel_time); The TimeDuration? you can pass as parameter must be one for which system_time+TimeDuration? is defined. You are right that this should be documented. BTW the interface for thread::sleep is void thread::sleep(system_time const& abs_time); Anthony, to be coherent, shouldn't you add the absolute time interface on the namespace this_thread? Waiting fro Boost.Chrono, what about adding void sleep(system_time const& abs_time); void sleep_until(system_time const& abs_time); template <class TimeDuration> void sleep_for(TimeDuration const& rel_time); Best, Vicente -- View this message in context: http://old.nabble.com/-thrad---3179--%09-Sleep-with-local_time-tp26513016p2… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2361 thread_specific_ptr: nature of the key, complexity and rationale
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, As you have made some modifications on the thread-specific_ptr, maybe you could now complete the documentation to answer the questions of the ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2361--%09-thread_specific_ptr%3A-nature-of-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, thanks for fixing this ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2742-Why-the-at_thread_exit-cleanup-functio… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

Boost sprint: #3407 boost::call_once not re-entrant (at least in win32)
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, I have changed the ticket from threads to thread As this works as expected, Anthony could just add on the documentation why reentrant call_once functions are not a good idea. The explanation of Steven could be a good starting point: "I'll also point out that there is no good behavior for a recursive call to call_once. If it calls the function again, then f will be called twice. If it does not, then whatever initialization that call_once is doing may be incomplete. In either case, you have to know whether a call can be recursive and carefully design for it. If it happens accidentally, you're probably toast regardless of how it behaves. In the face of recursive calls it is impossible to maintain the post-condition that the function has run exactly once." After this modification IMO the ticket can be closed. Best, Vicente -- View this message in context: http://old.nabble.com/Boost-sprint%3A--3407-boost%3A%3Acall_once-not-re-ent… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 20

[test] New ticket #3664 (SIGCHLD always considered fatal error)
by Johan Nilsson 25 Nov '09

25 Nov '09

New ticket: https://svn.boost.org/trac/boost/ticket/3664 Regards / Johan

2 2

Boost Server Downtime Wednesday Morning
by Doug Gregor 25 Nov '09

25 Nov '09

The main Boost server will be down for a short time Wednesday, November 25th (tomorrow!) from 8:00AM Eastern time to 8:30AM Eastern time to replace some memory. This outage will affect most of Boost's services, including the mailing lists, boost.org web server, and Boost Subversion repository (including the sandbox). Sorry for the inconvenience! - Doug

1 0

Re: [boost] Re view Queue Needs Attention
by Tom Brinkman 25 Nov '09

25 Nov '09

>> What's the difference between a non-stable branch as you're suggesting and >> the existing sandbox? The only difference I could see is to establish some >> kind of pre-review process. But that would just move the problem to a >> different spot, no? The "non-stable" branch would be for libraries that have requested reviews or for "approved" libraries that have not yet stabilized. The "sand-box" branch would be for all other libraries that either have not requested reviews or don't plan to. The "review-wizards" John or Ronald or any of the "boost-moderators" could monitor the "non-stable" branch. This would clear the review queue. The only important review would be to establish when a particular library has achieved sufficient maturity to be moved from the "non-stable" branch to the "stable" branch. Once a library is in the "non-stable" branch, the library could be reviewed by anyone anytime. There would be no need for scheduled reviews, like we've had, although they could still be done, if the review manager wants to schedule it. The reviews would be ongoing and done in a blog format, not limited to a ten day block of time. After a library has been in the "non-stable" branch for say six months, the review manager could posts its progress to the mailing list and pose questions to elicit more feedback. The "non-stable" branch would be included as part of the boost installation, but only an optional part, not required. If a library is distributed as "non-stable", it should get lots and lots of attention. Nothing focuses an authors mind more than if they know that their library is going to get some exposure. The libraries in the review queue are not getting the exposure that they need, and are just sitting there for 6-18 months. Very few people are actually aware of these libraries. A better job needs to done to elicit feedback from domain experts. Having only a 10 day review period is way to short. It needs to be like 6-12 months, where the domain experts can contribute at their leisure. This could best be done if a "non-stable" branch is created, which is distributed along with the "stable" branch.

1 0

[serialization] how to serialize map of non-default-constructible?
by ivo.t＠moss-soft.de 24 Nov '09

24 Nov '09

Hi to everybody, I'm new to the list, work for some time with Boost and C++ and have a fair knowledge but am not an expert yet. I try to serialize a map whose type ist not default-constructible, and I'm seriously stuck there. I thought the load_construct_data and save_construct_data overrides would help me there, but that seems not to be the case. I tried to create a private default constructor hoping that the map (respectively pair) constructor could access it, due to the boost::serialization::access friend declaration, but that didn't work as well. I really do _not_ want to make a public default constructor. What could I do as a workaround?? Any help would be greatly appreciated!! Btw, I work with Boost 1.39 and Visual Studio 2005. Thank you very much in advance Ivo

2 1

[filesystem]: infinite-recursion with symlink
by variadic.template 24 Nov '09

24 Nov '09

While playing around with boost::filesystem and the recursive_directory_iterator, I'm running into a infinite-recursion caused by symlinks. Not following symlinks would be, a solution, of course, but... So, is there a way to ascertain the path where the symlink is aiming at? And a second question: I didn't find anything about permission-handling - are there any plans? In my eyes, this is something essential for a filesystem-library. Thanks in advance

5 7

Proposal for library addition: faster signals/slots, reactor, atomics
by Helge Bahmann 24 Nov '09

24 Nov '09

Hello everyone I have written a small library providing: - a (thread-safe) signal/slot implementation - poll/timer/reactor implementation - atomic operations modelled after the proposed C++0x standard (x86 32/64 bit, ppc, alpha, more if someone donates hardware; fallback implementation using locks) Currently I am reworking the library to be more closely tied to and better reuse services provided by Boost. Obviously, there is considerable functional overlap with Boost.Signal/Boost.Signals2 and Boost.Asio, however what sets my implementation apart is that it is considerably faster, measurable in both synthetic tests and real-world applications (the main way this is achieved is through extensive use of atomic operations and carefully designed accessor protocols instead of locking, there is a small documentation section explaining the technique). The signal/slot implementation is thread-safe, with the same guarantees as Boost.Signals2, but about 3 times as fast as (thread-unsafe) Boost.Signal (!) and about 6 times as fast as (thread-safe) Boost.Signals2. The reactor implementation is obviously only suitable for Unix-like systems, while the proactor interface provided by Boost.Asio is a nice and portable abstraction. However, my reactor implementation is about 2-3 times as fast on Unix-like systems for typical network-server-style apps. Moreover I have always found Boost.Asio to be difficult to integrate with third party libraries (think ALSA or ldap) and frameworks (think Qt, Glib), so other developers not interested in portability may also prefer a bare reactor implementation. If you are interested, I invite you to have a look at: http://www.chaoticmind.net/~hcb/projects/libtscb Maybe parts of the library might be interesting for Boost? In particular the atomic operations could be salvaged and provide a "transitional" implementation internal to boost as an interim solution until compiler vendors catch up with C++0x, and I would also like to propose the reactor as a higher-performance alternative to Boost.Asio (my signal/slot implementation lacks combiners and other features provided by Boost.Signals2). Best regards Helge Bahmann

6 7

[serialization] Boost fails to serialize via reference to a pointer
by Alexander Churanov 24 Nov '09

24 Nov '09

Folks, I've encountered an issue and not sure whether it is a bug in boost or in the application. >From the compiler error messages it looks like there is a bug in boost and a reference (or value) is to be returned from the function which has a pointer return type. The issue was detected when building x11-toolkits/gigi with the boost-1.41. The error log fragment is available at http://alexanderchuranov.com/gigi-boost-1.41.0.log . The operating system is FreeBSD 7.2-RELEASE/i386 . The compiler is c++ (GCC) 4.2.1 20070719. One can reproduce the issue using the following preprocessed translation unit: http://alexanderchuranov.com/saveload.ii The command-line is g++43 -o saveload.o -c -fno-strict-aliasing -pipe -Wall -Wno-parentheses -O2 -pthread saveload.ii The application successfully builds with 1.39.See http://portsmon.freebsd.org/portoverview.py?category=x11-toolkits&portname=…. Alexander Churanov, mainatainer of devel/boost-* for FreeBSD

2 1

[Spirit] Who's using Spirit
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Hi all, We started to collect references to projects and products using Spirit here: http://boost-spirit.com/home/?page_id=594. If you're interested in getting your product/project mentioned on this page, please drop me a note. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

1 0

2nd Call for Participation - BoostCon 2010
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 4-10, 2010, www.boostcon.com 2nd Call for participation ---------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposal submissions due: Dec 10th, 2009. Proposals decisions sent (tentative program available): Jan 15th, 2010. Fully scheduled program available: Feb 5th, 2010. Session materials due: Apr 15th, 2010. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[new Warnings policy] what to do about msvc "deprecation" and "unsafe" warnings
by Robert Ramey 24 Nov '09

24 Nov '09

I've implemented the suggestions in "new warnings policy". It probably DID catch a few bugs which have probably been in there for years. It wasn't as bad as I thought - mostly tedium and a few hours of testing. But now I have a couple of questions: a) I added <toolset>gcc:<warnings>all # ? <toolset>msvc:<warnings>all # == /W4 To my jamfile. With MSVC 9.0 I now get a blizzard of "deprecation" and "unsafe" warnings. If the policy is updated to address this, I will implement the recommendations. Robert Ramey PS I'm wondering if I should replace the above with something which maximizes the warning level for all compiles. Perhaps just <warnings>all #?

16 59

[test] Use of snprintf
by Mateusz Loskot 24 Nov '09

24 Nov '09

Hi, I'm testing Boost with Comeau C/C++ frontent which, as far as I found, does not support mixing C++ and C99 modes. So, compiling Boost.Test library fails because ::snprintf can not be found [1]. I could not find any guidelines regarding use of elements of C99 in Boost libraries (are there any?). Scanning Boost libraries for snprintf shows that it's not widely used, but only in 3 files: boost/test/impl/debug.ipp boost/test/impl/execution_monitor.ipp libs/format/benchmark/bench_format.cpp Would it make sense to remove use of snprintf? [1] https://svn.boost.org/trac/boost/ticket/3558 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

5 10

[msm] scalability
by Simon Gittins 24 Nov '09

24 Nov '09

Hi There I've been looking at the msm library with respect to using it in an application with a reasonable number of transitions and states. In order to simulate a larger application (without having to write more code), I've been using MsmSimple.cpp and EumlSimple.cpp and have been duplicating the rows in the transition table (the original code has 12 transitions, and I would copy and paste all the transitions so we end up with 24, or 36 etc transitions). In this way I hoped to be able to get a reasonable approximation of the compile time performance and limitations of the library. I'm testing with VS8. I have a couple of comments/questions: - I think it would be worthwhile talking a little more about compile time performance in the documentation. Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time). - Is there provision to split a machine across multiple compilation units (I assume not)? - You include instructions for how to increase the maximum size of an MPL vector, but this only works up to 50 entries. What do we need to do to increase this further? - Euml looks really cool, but I'm getting an ICE when using it with 36 transitions in EumlSimple.cpp (12 and 24 work fine though). - One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm? The library is looking really powerful and expressive (not to mention fast!) for small state machines. Cheers Simon Gittins --------------------------------------------------------------------- CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. ---------------------------------------------------------------------

1 0

boost::lambda and math functions
by Peter Foelsche 24 Nov '09

24 Nov '09

I've the following template function: template<typename T> T exp2(const T T0_d) { return exp(0.5*T0_d) + 2*exp(T0_d); } I want to define this as a lambda function in place (but don't know how). It will be used with T=double and T=MyAutomaticDerivativeClass. I've already defined the return type of arithmetic operators applied to MyAutomaticDerivativeClass: namespace boost { namespace lambda { template<class Act, typename X, typename Y> struct plain_return_type_2<arithmetic_action<Act>, X, Y> { typedef ... type; }; } } What else is missing? Thanks Peter

2 2

GGL Review
by Phil Endecott 23 Nov '09

23 Nov '09

Dear All, Here is my review of GGL: I have attempted to try the same examples that I did for my Boost.Polygon review. Unfortunately limited time has made it impossible for me to be as thorough as I would have liked. Here is what I have done, and the issues that I encountered along the way. (You may want to look at my Boost.Polygon review for background. It can be seen here: http://thread.gmane.org/gmane.comp.lib.boost.devel/193204/focus=193758 ) My first exercise was a GUI application in which I wanted to merge a large number of small rectangles into a single more complex polygon. Unfortunately I failed at the first step with this: I wanted to teach the library about my existing types (point, box, etc), but how to do this is not properly documented. It seems that there are some macros (with not-Boost-style names) but their only mention in the documentation is in an example. Yes, I could probably have worked out what to do from the example, but I have limited time and furthermore I don't think it's acceptable to expect a library end-user to learn something relatively fundamental like this from an example. (From my brief look at the example, it does look as if this mechanism is significantly less verbose that what I had to do to teach Boost.Polygon about my types, which is a good thing.) So I moved on to my second example, which reads a file containing the borders of the states and provinces of the US and Canada and determines which ones contains points that the user enters. I implemented this using the geometry types provided by the library, so the question of adapting to types did not arise. This all worked quite smoothly, though I did encounter the following issues, mainly with the documentation, which I imagine could be corrected quite easily: - The docs do not say what the C template parameter in point_xy<T,C> is. - The "complete list of members" for ggl::linear_ring is empty. (Presumably the issue here is that the members are all inherited from the std::container; it could at least say that.) - The documentation for ggl::linear_ring says that V is a "container type e.g. std::vector, list, deque"; it should describe this in terms of std concepts (presumably bidirectional container) so that I know if my own custom type will work. Looking at the code I don't see any concept-checking for this; that would be nice. - The args to the within() function are reversed wrt the equivalent function in Boost.Polygon. This is a good example of the issue that I raised in a previous email, where the generic nature of the concisely-named functions can lead to mistakes. - Doxygen doesn't give the full path to the headers, i.e. "point_xy.hpp" rather than "geometries/point_xy.hpp". - There seems to be a dependency on Boost.Math that isn't mentioned on the list of dependent libraries. - The library doesn't seem to be in namespace boost. I guess the intention is to add this later. This is unusual. - I was surprised that the box class doesn't have width and height members. - I got a page full of warnings from my test program; the cause seemed to be unused parameters in within.hpp, lines 118 and 178. Since I have touched only a small fraction of the library, I imagine there are other places with the same issue. As I said, these are minor issues that I imagine could be corrected quickly. However they did give me the impression that the library is still very much a work-in-progress - especially the documentation - rather than a fully-formed finished work. I don't necessarily believe that a library has to be perfect before it can be accepted into Boost, but I think it needs to be a little less rough around the edges than this. That unfortunately was all of the actual testing that I have been able to do. I'll now discuss other issues: Firstly there's the situation concerning Boost.Polygon. My feeling is that the situation that has developed here is very unfortunate. I think it's extraordinary that Boost can even consider having two incompatible, overlapping Geometry libraries reviewed within a few weeks of each other, with authors who are so publicly antagonistic towards each other. How on earth did we get into this situation? (Answer: IMO, the progress towards review flowed to the current situation by following the path of least resistance, and "someone" - a "leader" ? - should have jumped in earlier to steer things in a more constructive direction.) Anyway, Boost.Polygon has now been accepted (within an hour of this review starting! I mean, was that calculated to be antagonistic?) and we have to consider what that implies. One option is to imagine the two libraries in parallel universes. That may be the most stress-free way. But it's not what would deliver the best results for Boost's end users. What I would prefer to see is some work to investigate how more common ground can be introduced. For example: - Common terminology. ("within" vs. "contains", "extents" vs. "envelope", and dozens more. GGL's not-unreasonable adoption of OGC terminology is an issue here.) - Inter-operable types. I would like to hope that the basic geometry traits classes could be shared. Failing that, perhaps a method of forwarding from one set of traits to the other could be used. I am unsure how deeply the choice of tag dispatch vs. SFINAE makes inter-operation more difficult. Maybe someone could comment on that. Let me say a little about performance. There has been a great deal of discussion about this on the list. My feeling is that all libraries should document the worst-case complexity of all of their functions. In the current case we have polygon boolean operations where I believe I learnt as an undergraduate 20 years ago that they should be O(n log n). Here IIUC the implementation is worst-case O(n^2) but typically better. I feel uncomfortable with that, however many benchmarks and years of real-world use have gone in to it. Is it not possible to contrive an introsort-like "fallback" solution that gives both good typical case performance and an optimally-bounded worst case guarantee? The other controversial implementation issue is floating-point robustness. I'm still not clear what the position of this library is on that. Are we just given assurances that it seems to be robust in real-world use, or is it believed that it actually is certainly robust? I expected to see this discussed in the library documentation, but I don't see anything - maybe I've missed it. If it is "believed to be robust in real-world use", it would be helpful to describe the possible failure modes (e.g. segfault, runs forever, or just outputs the wrong answer.) In summary: Congratulations to the authors on getting their library to this point. I'm sure that it contains much useful code. At this time, the library is let down by incomplete documentation, and I feel it should be rejected for that. I believe it is also essential that some effort is done to find common ground (I'm avoiding saying "merge") with Boost.Polygon. If the authors are unable to work together, then I would prefer that Boost keep things simple for its end users, and avoid years of antagonism on the mailing list, but suggesting that one (or other!) library should exist outside of Boost. To answer the usual questions: - What is your evaluation of the potential usefulness of the library? Very useful. - Did you try to use the library? With what compiler? Yes; gcc-4.x on Linux. - How much effort did you put into your evaluation? I've spent about 5 hours in all. - Are you knowledgeable about the problem domain? I'm not a geometry expert, but I have done projects that could make use of this sort of library. Regards, Phil.

16 51

Lots of issues with Boost.Test in Trunk?
by John Maddock 23 Nov '09

23 Nov '09

I'm getting an absolute ton of warnings - of the kind that are normally errors - from Boost.Test while working on Boost.Integer: compile-c-c++ ..\..\..\bin.v2\libs\integer\test\integer_test.test\msvc-9.0\debug \threading-multi\integer_test.obj integer_test.cpp d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(941) : warning C4535: calling _set_se_translator() requires /EHa d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1128) : warning C4273: 'boost::execution_monitor::catch_signals' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(190) : see previous definition of 'catch_signals' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1199) : warning C4273: 'boost::execution_monitor::execute' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(173) : see previous definition of 'execute' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1340) : warning C4273: 'boost::execution_exception::execution_exception' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(125) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1348) : warning C4273: 'boost::execution_exception::location::location' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(117) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/debug.ipp(637) : warning C4273: 'boost::debu g::under_debugger' : inconsistent dll linkage and so on. Normally, I would put this down to a problem with Boost.Integer's Jamfile, but in this I see nothing wrong. Any ideas anyone? Thanks, John.

4 6

[serialization] [1.41] serialization of shared_ptr<> fails to compile
by Marco Jez 23 Nov '09

23 Nov '09

Hello, I'm still having troubles with Boost.Serialization in Boost 1.41. The following example code fails to compile with latest Boost release, while it works with 1.39: #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/shared_ptr.hpp> #include <iostream> // dummy struct with no actual serialization code struct Test { template<typename A> void serialize(A &, unsigned) {} }; int main() { boost::archive::binary_iarchive ia(std::cin); boost::shared_ptr<Test> x; ia & x; return 0; } The compiler (MSVC 9) gives me this error: error C2440: 'return' : cannot convert from 'const boost::serialization::extended_type_info_typeid<T>' to 'const boost::serialization::extended_type_info *'c:\boost\include\boost-1_41\boost\archive\shared_ptr_helper.hppIt seems that an address-of (&) operator is required in shared_ptr_helper.hpp at line 111, that is: ... return boost::serialization::singleton< ... should read: ... return &boost::serialization::singleton< ... This change makes my code compile, but I'm not sure whether it's an appropriate fix or not, as I don't know Serialization's internals. Cheers, Marco

2 1