- Boost - lists.boost.org

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

Re: [boost] Proposal: Monotonic Containers: Performance test
by Christian Schladetsch 11 Jun '09

11 Jun '09

void test_speed() { typedef monotonic::map<int, monotonic::list<int> > map_with_list; monotonic::inline_storage<1000000> storage; map_with_list m(storage); size_t count = 10000; boost::timer timer; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m.insert(make_pair(random, monotonic::list<int>(storage))); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "monotonic: " << elapsed << endl; // do the same thing, with std::containers { typedef std::map<int, std::list<int> > map_with_list; map_with_list m; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m[random] = std::list<int>(); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "std: " << elapsed << endl; } } monotonic: 0.005 std: 0.09

4 5

bug-sprint #2114, 2 comments
by Alexander Arhipenko 11 Jun '09

11 Jun '09

I have 2 major comment on the updated patch. Consider following snippet from gcc.hpp: #if __GNUC__ >= 4 && !defined(__MINGW32__) && !defined(__CYGWIN__) # define BOOST_SYMBOL_EXPORT __attribute__((visibility("default"))) # define BOOST_SYMBOL_HIDE __attribute__((visibility("hidden"))) # define BOOST_SYMBOL_IMPORT BOOST_SYMBOL_EXPORT ...And assume following scenario: Someone is writing shared library (let's name it foo) with 'visilibility=hidden' option. Library foo is using e.g. boost_filesystem. In this case, all the symbols marked with BOOST_FILESYSTEM_DECL will be exported from foo library. This could easily break foo library's ABI (in case of migration to the newest boost version etc.), so BOOST_SYMBOL_IMPORT should be defined for gcc as empty macro: # define BOOST_SYMBOL_IMPORT. The second comment: BOOST_EXCEPTION_EXPORT/IMPORT are intended for re-exporting exceptions from shared library. So, they should be defined for gcc as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_EXPORT and not as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_IMPORT Note: for the current patch version this part works as expected, since BOOST_SYMBOL_EXPORT == BOOST_SYMBOL_IMPORT for gcc. See also this thread (search for exception): http://lists.boost.org/Archives/boost/2008/12/146068.php Regards

4 8

[candidate bloom_filter] Default Sequence
by JOAQUIN M. LOPEZ MUÑOZ 11 Jun '09

11 Jun '09

Currently, the default Sequence template arg is class Sequence = fusion::vector< detail::default_hash<0>, detail::default_hash<1>, detail::default_hash<2> > which implies the default K is 3. I propose to generalize this a bit so that we have something like template<typename K> default_hash_sequence...; such that default_hash_sequence<K> is the fusion sequence default_hash<0>,...,default_hash<K-1> (I don't know Fusion but I'm sure this can be done) and then put class Sequence = default_hash_sequence<3> So, a user can easily set bloom_filter<foo,default_hash_sequence<K> > with a K other than 3. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1