- Boost - lists.boost.org

[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