- Boost - lists.preview.boost.org

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