- Boost - lists.preview.boost.org

[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

[test] Boost.Test broken in Trunk
by John Maddock 23 Nov '09

23 Nov '09

Folks, Boost.Test is currently completely broken in Trunk for msvc: compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-9.0\debug\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(54) : error C2059 : syntax error : '__declspec(dllexport)' d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(55) : error C2059 : syntax error : '__declspec(dllexport)' and: d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C2039: 'log_sink' : is not a member of 'boost::unit_test::runtime_config' d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C3861: 'log_sink': identifier not found Obviously this completely breaks regression testing for msvc as well :-( Strangely, I can't see how any of the recent fixes could have caused this either? John.

2 2

Does anyone use the IBM pSeries?
by Marshall Clow 23 Nov '09

23 Nov '09

We've got a really old bug (#583) with patches to support V8 of this compiler. Looking for someone to apply these patches to a local boost install, and report back on the results.... https://svn.boost.org/trac/boost/ticket/583 -- Marshall

1 0

Using units prefix dynamically to get the appropriate prefix for the size of the value?
by Paul A. Bristow 23 Nov '09

23 Nov '09

I'd like to use the units library prefix (k, M, G ...) system, but I'd really like to determine the prefix dynamically (automatically) depending on the value. For example, if I have a length of 12300 m I'd like an output of "12.3 km" but if my length is 0.0123 m, I'd like an output of "12.3 mm". I can't see how to do this (and including the correct length unit of m or meter of course). Suggestions? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 3

Possible regression in Boost.Test
by Ian Emmons 23 Nov '09

23 Nov '09

A previously reported issue in Boost.Test, which the bug tracking system indicates as fixed, is still present in the 1.41.0 release. The issue I am speaking of is entitled "Boost:Test pointer error with g++ 64-bit on Mac OS X 10.6 Snow Leopard", discussed here: https://svn.boost.org/trac/boost/ticket/3432 It looks to me like one of two things happened here. Either the bug was fixed on a branch but the branch was never merged into the release, or a merge conflict overwrote the change before it was ever released. In 1.38.0 and 1.39.0 the method in question looked like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete (test_suite const*)tu.second; else delete (test_case const*)tu.second; } } The ticket claims to have fixed the bug like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = (test_suite const*)tu.second; delete p; } else { test_case const* p = (test_case const*)tu.second; delete p; } } } But in 1.40.0 and 1.41.0 the method looks like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete static_cast<test_suite const*>(tu.second); else delete static_cast<test_case const*>(tu.second); } } Perhaps whoever switched the C-style cast to static_cast removed the local pointer variable and reintroduced the bug? In any case, the bug needs to be re-fixed, in the next release, and I would suggest adding a comment so that a future maintainer doesn't eliminate the apparently pointless local pointer variable, like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map // Important: The pointer MUST be copied to local // storage in order to avoid the issue described in // https://svn.boost.org/trac/boost/ticket/3432 if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = static_cast<test_suite const*>(tu.second); delete p; } else { test_case const* p = static_cast<test_case const*>(tu.second); delete p; } } }

2 1

[thread] unlock on multiple lockables
by Vicente Botet Escriba 23 Nov '09

23 Nov '09

Hi, I don't know if I have already requested that but ... Is there any deep reason to don't provide the equivalent of the free functions lock, try_lock Non-member function lock(Lockable1,Lockable2,...) Non-member function lock(begin,end) Non-member function try_lock(Lockable1,Lockable2,...) Non-member function try_lock(begin,end) to unlock multiple lockables? Non-member function unlock(Lockable1,Lockable2,...) Non-member function unlock(begin,end) Thanks, Vicente -- View this message in context: http://old.nabble.com/-thread--unlock-on-multiple-lockables-tp26471789p2647… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 5

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

23 Nov '09

>Is there any direct link for an online documentation? Yes, in the Sandbox, which will also be more up to date than the one in the Vault: http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/index.htm

1 0

[1.41.0] [integer] integer.hpp does not compile in MSVC 8.0 with /Za option on
by Adam Badura 23 Nov '09

23 Nov '09

An empty CPP file containing only inclusion of <boost/integer.hpp>: --------------- #include <boost/integer.hpp> --------------- does not compile in MS Visual Studio 8.0 Standard when /Za option ("Disable Language Extensions") is used. The output is following: --------------- D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(67) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(79) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(85) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(119) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(126) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(132) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(138) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(144) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(150) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(156) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer.hpp(88) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(94) : see reference to class template instantiation 'boost::int_max_value_t<MaxValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(89) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(90) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(91) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(101) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(107) : see reference to class template instantiation 'boost::int_min_value_t<MinValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(102) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(103) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(104) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(116) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(122) : see reference to class template instantiation 'boost::uint_value_t<Value>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(117) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(118) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(119) : error C2065: 'const_max' : undeclared identifier --------------- I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it. Adam Badura

6 13

Re: [boost] [Review] GGL review starts today, November 5th
by Christophe Henry 23 Nov '09

23 Nov '09

Steven Watanabe wrote: >FWIW, non-virtual destructors are the norm in Boost. >I strongly dislike the idea of having a policy enabling >virtual destructors. I understand this in many cases. OTOH, the geometry types seem to me to be begging for usage the OO way. A small note in the documentation seems to be better than hours of debugging and cannot hurt anyway. The policy was simply a suggestion as it proved a useful solution in my own experience.

1 0

Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>I remember hearing alot about UML years ago, but I have not heard very >much about it lately (last 5 years). >Any sense who popular UML is these days. It seems to me it was once >greatly touted as the cure to most of project management and >prototyping needs. >Does anyone have any experience using it? >Where is it primarily used, what kind of projects can benefit from it? I personally try to design my projects with UML, eventhough I mostly use only a few diagrams. It helps quite a bit for documentation and Model-Driven development. But I wouldn't want to start a big discussion about UML. Msm is implementing only a small part of it, the state machine chapter. There were state machines long before UML. The biggest advantage of following the standard whenever possible is that at least there is a standard and it is formally defined, so that you know what you get. If your question was about where to use state machines, this would need a longer answer. Common cases include GUI development, implementation of communication protocols or whenever you might be tempted to define some flags to define the state of a given class (those who never defined a dirty flag, raise your hand ;-) ). In these cases, state machines help you abstract away implementation details and allow someone else understand your code more easily. I also found them a huge help during development as thinking in terms of a model made a problem much easier to solve. HTH, Christophe

1 0

[iostream] closing filtering_ostream
by Vladimir Prus 23 Nov '09

23 Nov '09

Hello, I must be missing something basic, but I cannot find that in Boost.Iostream documentation. Suppose I am writing into filtering_ostream, and I'm done. I wish to close the ostream, flushing whatever remaining data and reporting whatever I/O errors arise to user. However: base64.cpp:17: error: ‘class boost::iostreams::filtering_ostream’ has no member named ‘close’ The documentation say: By default, if the Device at the end of the chain is popped or if the filtering_stream is complete when it is destroyed, all the filters and devices in the chain are closed using the function close. So I assume something is closed in destructor, but what if I don't want the destructor to potentially throw, and instead what to close the stream explicitly? - Volodya P.S. Actually, I'm sure there's a Trac issue saying that potentially throwing destructor is not good.

2 1

Meta State Machine library review starts Monday
by Tom Brinkman 23 Nov '09

23 Nov '09

I remember hearing alot about UML years ago, but I have not heard very much about it lately (last 5 years). Any sense who popular UML is these days. It seems to me it was once greatly touted as the cure to most of project management and prototyping needs. Does anyone have any experience using it? Where is it primarily used, what kind of projects can benefit from it?

1 0

Preliminary submission: generic linear algebra algorithms library Boost LA
by Emil Dotchevski 23 Nov '09

23 Nov '09

I remember some past discussions on this mailing list about the need for similar library in Boost, so I hope it is OK to skip the interest query and request a preliminary review for Boost LA. Boost LA provides a set of generic linear algebra algorithms, primarily for working with vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the vector_traits and matrix_traits templates. Documentation and source code available at http://www.revergestudios.com/boost-la, released under the Boost Software License. Thanks, Emil Dotchevski

9 25