- Boost - lists.boost.org

Why the integration branchmust remain clean, etc.
by David Abrahams 12 Jun '09

12 Jun '09

I just realized I can articulate what's not working for me about the current trunk/release branch arrangement. * IIUC, there are always lots of failures on the trunk because there's no pressure to keep it clean. * Before I check in a change in one of my libraries, I want to make sure I haven't broken anything else in boost. So naturally, I run the whole regression suite (there oughta be a better way!) * But since the trunk is not clean, I spend a lot of time analyzing problems that have nothing to do with my library. That's a real disincentive to making changes in Boost. In fact, I am confident my low activity in the repo over the last year or so is primarily caused by the amount of labor associated with testing my changes. Now, maybe you'll suggest that I test my own library, then damn the torpedoes and check in the changes, and let other people complain to me when their libraries break. That would work... except that many people aren't paying attention to the health of their libraries on the trunk. I suppose another approach might be to test against the release branch, then svn switch to the trunk and check in my changes there. But that is still laborious. I'm not sure what to do about this, but it's really killin' me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 10

Some good news for boost
by David Abrahams 12 Jun '09

12 Jun '09

Apparently we've been selected as an "alternate finalist" in the SourceForge Community Choice awards! They want us to answer some questions and provide some supporting material. If anyone else in the community would like to contribute to answering questions 1 and 2 below, that would be awesome. Marshall, you're the only person I know of that has any Boost-related video. What do you think about #4? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 5

Documentation Edits
by Zachary Turner 12 Jun '09

12 Jun '09

What is the standard protocol for editing documentation? It doesn't appear to be a wiki, unless you have to explicitly request write access in which I wasn't aware of that. The reason I ask is that there are many times where I've spent forever toiling over the documentation of some new library that I wasn't familiar with, because the documentation either provided no / insufficient samples, functions with very general names and one-liner documentation that says (for example) "runs the service". Which is pretty obvious when the function is called run, but no mention of the implications or what "running" even means. Other examples include lack of discussion over memory ownership (I spent 6 hours yesterday trying to trace down a memory corruption only to later find that in one of the many example programs for the library a single line comment that said "this causes X to take ownership of Y". If that had been in the documentation I would have spent 5 minutes tracing down the bug. So my point in all this is can the documentation be in wiki format, and as a fallback is there a way that someone other than a library owner/maintainer can edit it?

2 1

Re: [boost] Possible problem: Christian Schladetsch
by John Maddock 12 Jun '09

12 Jun '09

> Let's not turn an accidental mailing into a tar and feather. All things > said and done, he is at least attempting to contribute something to the > community. Indeed, can we please consider this thread closed now, Thanks, John Maddock. Boost Moderator.

1 0

1.40.0 showstoppers
by Vladimir Prus 12 Jun '09

12 Jun '09

During last release cycle, we talked that there should be a way to flag some issues as showstoppers for next release, so that next release is either delayed until the issue is fixed, or the issue is explicitly downgraded by the release team after consideration. However, I am not sure we've reached definitive agreement on how such issues should be marked. One proposal is to use the 'showstopper' status. Does that sound OK to our release managers? If so, shall this convention be documented somewhere, and should release procedures be adjusted to including checking this list prior to rolling betas and final release? I can do the necessary edits if everybod agrees, and tell me what to edit. Thanks, Volodya

1 0

Re: [boost] "boost cold shoulder" (was proposal for #pragmaonce support)
by Brian Wood 11 Jun '09

11 Jun '09

Sid Sacek writes: > I believe I belong to a third category that you didn't mention below: > 3. The middle-aged mellowed-out "try to always do the right thing", > "using namespace boost", crowd. I don't think doing the right thing implies automatically using a Boost library, but rather considering the options. I encourage people to "chew the meat and spit the bones" when it comes to Boost. Some of the libs are very helpful and are implemented well. Other libs have some problems -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I will say though that doing the right thing in my book usally means using Boost Intrusive and that Ebenezer Enterprises offers exclusive marshalling/serialization support for two Boost Intrusive containers. If there's interest in having marshalling support for other Intrusive containers, we are willing to consider adding more support in that area. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[multi_array] Negative strides
by John Reid 11 Jun '09

11 Jun '09

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them? John.

3 6

Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

I would like to propose conditional support for #pragma once be added to all header files in boost. This would involve, at the beginning of every header file, a preprocessor check to determine whether or not the particular compiler is on a whitelist of known compilers to optimized #pragma once. If so, #pragma once is used. so, something like this: #if defined(_MSC_VER) /* || defined(OTHER_PRAGMA_ONCE_ENABLED_COMPILER) ... */ #pragma once #endif the rest of the header file, including the original #include guard, could be as normal. to demonstrate the motivation for this, consider the sample on this page: http://www.gamearchitect.net/Articles/ExperimentsWithIncludes.html. At the bottom there is a zip file with a visual studio solution that contains 3 different projects. Each project contains 200 header file, each of which includes all of the other 199 header files. There is a single cpp file with a main function which includes all 200 header files. All 3 projects use internal #include guards. In addition: Project 'RedundantGuard' - Uses external include guards (wrapping the invocation of #include itself inside the appropriate guard) as discussed in the book Large Scale C++ Software Design Project 'PragmaOnce' - Uses #pragma once Project 'Nothing' - Uses nothing additional other than the internal include guards. Here are the build timings on my machine (Visual Studio 2008 Service Pack 2) RedundantGuard - 1 second compile + link time PragmaOnce - 1 second compile + link time Nothing - 15 seconds compile + link time In addition I have tested this in the code base of a commercial product I am working on (~40,000 lines of code). It consists of about 6 different projects, some of which have dependencies between each other and some which don't, so that parallel compilation can happen in some instances RedundantGuard - Not Tested PragmaOnce - 1 minute, 25 seconds compile + link time Nothing - 2 minutes, 1 second compile + link time So, I believe that boost compile times can benefit significantly from this. Thoughts?

20 38

Re: [boost] Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

On Tue, Jun 9, 2009 at 11:50 AM, <dherring(a)ll.mit.edu> wrote: > On Tue, 9 Jun 2009, Zachary Turner wrote: > > Here are the build timings on my machine (Visual Studio 2008 Service Pack >> 2) >> >> RedundantGuard - 1 second compile + link time >> PragmaOnce - 1 second compile + link time >> Nothing - 15 seconds compile + link time >> > ... > >> So, I believe that boost compile times can benefit significantly from >> this. >> >> Thoughts? >> > > Could you run benchmarks on gcc? Will my compile times suffer for your > improvement? > > - Daniel > It seems someone else in the thread has already run benchmarks on GCC, but regardless of how the benchmarks did or did not turn out, I can say with 100% certainty that nobody will suffer. That's the exact reason I mentioned that compilers should be whitelisted based on which ones benefit from #pragma once, and only use #pragma once for said compilers. #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif That's all it takes. Everybody benefits. Of course I don't have licenses for every C++ compiler around, but I'm sure there are other compilres in which it benefits also. So I would need some assistance from other people who do have other compilers to help find out which compilers it does offer an improvement on. And of course, the default would be to NOT use pragma once, erring on the side of caution. If you see any downsides to this approach let me know, but it seems like a win/win for everyone. To make it even more explicit, there could even be a global macro, which defaults to undefined, called BOOST_USE_PRAGMA_ONCE. The programmer would be forced to explicitly declare this macro before including any boost headers, and if it is enabled, boost would use pragma once.

9 16

possible problem with boost::iostreams::file_descriptor
by Zachary Turner 11 Jun '09

11 Jun '09

nested file_descriptor implementation class is defined as follows: struct impl { impl() : #ifdef BOOST_IOSTREAMS_WINDOWS handle_(reinterpret_cast<handle_type>(-1)), #else handle_(-1), #endif flags_(0) { } impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } ~impl() { if (flags_ & close_on_exit) close_impl(*this); } enum flags { close_on_exit = 1, append = 4 }; handle_type handle_; int flags_; }; In the second constructor in particular we have this: impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } I think this should be changed. Just because close_on_exit is specified to false does not mean a file is not open. It just means don't close it if it is. I think flags enumeration should be changed to: enum flags { close_on_exit = 1, good = 2, append = 4 }; and constructors / code should be changed accordingly. Otherwise following code (Windows) asserts, even though I don't think it should: bool is_open(HANDLE h) { return h && h!=INVALID_HANDLE_VALUE;} HANDLE h = ::CreateFile("C:\\autoexec.bat", GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); boost::iostreams::file_descriptor fd(h, false); BOOST_ASSERT(fd.is_open() == is_open(h)); Thoughts?

3 5