- Boost - lists.boost.org

[smart_ptr] make_shared_array/allocate_shared_array function templates
by Roman Kecher 09 Nov '09

09 Nov '09

Hi, I'm suggesting to add the following function templates to allow easy, exception-safe, creation of shared_array objects: - make_shared_array (very similar to make_shared which is used to create a shared_ptr) - allocate_shared_array (again, same functionality like allocate_shared) Is there any reason not to include these? Regards, Roman.

3 4

Time for another bug sprint (after 1.41 ships)?
by Marshall Clow 09 Nov '09

09 Nov '09

Earlier this year, we had a "bug sprint", where many people focused on fixing bugs in Boost. We managed to get the # of open tickets down from 800 to about 720. As of today, there are 820 open tickets in Trac. Is it time to focus on swotting bugs again? 1.41 is scheduled for release on 1-November; that's six weeks from yesterday. How about a bug sprint starting on 14-November, finishing on 22- November? That's two weekends - and finishes up before the American Thanksgiving holiday. -- Marshall P.S. This doesn't mean that people have to wait until November to fix bugs ;-) ;-)

12 25

[function] "paranoia" vs efficiency
by Domagoj Saric 09 Nov '09

09 Nov '09

As far as I can see boost::function<>::operator() performs: if (this->empty()) boost::throw_exception(bad_function_call()); before invoking the stored function (object)... My question is why or why only this "checked"/"safe" approach/method of invocation exists? Because this: - causes (extra) code branching - causes the compiler to insert exception throwing and handling code in surrounding/calling code (which need not otherwise be if the function stored in the boost function instance is itself nothrow) - inserts a call to the bad_function_call constructor - disables the compiler from inlining the function (MSVC atleast) - disables NVRO (MSVC atleast, http://msdn.microsoft.com/en-us/library/ms364057(VS.80).aspx#nrvo_cpp05_top… ) while at the same time I would most often consider calling a "null-function-pointer" a programmer error (that would therefor need to be "handled" with an assert not an exception), not a runtime 'unpredictable' exception... ...IMO the default should be not to include this check (i.e. use an assert) and provide a safeInvoke() type of method for those users and cases that actually require/want this type of check/behaviour... ...or atleast "it would be welcomed" if a non-checking unsafeInvoke() type of method would be provided for those that are 'sure' that the boost::function<> object is valid (for example in the line before i've just performed the same check to decide whether to call the function object or not)... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

8 18

[shared_ptr] Set pointer to null
by Mateusz Loskot 09 Nov '09

09 Nov '09

Hi, I'd like to make a custom deleter resetting pointer to 0 or other value (e.g. for debugging purposes) after resource has been deallocated. Would anyone suggest better option to this presented below? struct DeleterT { void operator()(::T* ptr) { ::DestroyT(ptr); // uses Visual C++ specific integer type *reinterpret_cast<__int64*>(&ptr) = 0; } }; Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[iostreams] building zlib from source
by Vladimir Prus 09 Nov '09

09 Nov '09

I am working on improving detection of external dependencies (for 1.42), and I've noticed that the iostreams library is rather smart when it comes to building zlib (and bz2). It allows the user to specify either: - location of headers and libraries files, or - location of sources for zlib In the latter case, the sources will be compiled automatically. How important is the second use case? It's not very hard to support, and appears handy for Windows users, but if in practice, nobody cares, I can spend the time on other matters. Thanks, Volodya

2 3

[thread] Is interrupting a non boost.thread possible?
by Christoph Mathys 09 Nov '09

09 Nov '09

Hello I've a question about boost.threads: Is it possible to interrupt a thread for which I don't have a thread-object but which is using boost synchronization primitives (mutex, condition)? Thanks! Christoph

2 1

[1.41.0] Beta 2 plans
by Beman Dawes 08 Nov '09

08 Nov '09

Due to the issues exposed in the "Official warnings policy?" thread, there will be a second 1.41.0 beta, tentatively scheduled for Sunday, November 15th. Until Saturday, November 14th, the release branch is open for merges of low-risk bug fixes. In particular, fixes that clear compiler warnings are encouraged. Please do, however, make sure any changes are stable on trunk before merging them to release. I'll be traveling until Monday, with little or no email connectivity. So if questions arise, it would be great if the other release managers could step in with responses. Thanks, --Beman

5 5

ppc64 and OSX Snow Leopard
by Vladimir Prus 08 Nov '09

08 Nov '09

Folks, it was reported that in Snow Leopard, Apple has removed support for ppc64, and folks trying to use that receive fairly obscure errors. Some of Boost users were already confused by this. Now, this is of course more like Apple's problem, but here's a patch, against current trunk, to do a nice diagnostic of this in Boost.Build. The intention is that if you try to build just ppc64, or a two-way fat binary including ppc64 you get an error message, and if you try tobuild 4-way fat binary, ppc64 is skipped and you get 3-way binary. Can some of OSX users apply this patch to trunk and give it a try? If it works, I would like to merge to release branch. Thanks, Volodya

2 1

[1.41.0] Beta 1 release candidate
by Beman Dawes 07 Nov '09

07 Nov '09

1.41.0 beta 1 release candidates are available at http://boost.cowic.de/rc/ Before pushing the beta out to SourceForge, I'd appreciate it if several people would try the release candidate and report success or problems. Thanks, --Beman

16 38

compile problem with thread without rvalue references
by Bob Walters 07 Nov '09

07 Nov '09

I've just attempted a build of the current (1_40_0) boost distribution on a Solaris 10 machine, using the SunStudio12 compiler (cc). There seems to be a problem with boost::thread which is related to this compiler's lack of rvalue references. My build process has been: tar xzf boost_1_40_0.tgz cd boost_1_40_0 export BOOST_ROOT=`pwd` ./bootstrap.sh ./bjam toolset=sun address-model=64 The error I'm receiving: "./boost/thread/detail/thread.hpp", line 344: Error: boost::thread::thread(boost ::thread&) is not accessible from boost::move(boost::detail::thread_move_t<boost ::thread>). 1 Error(s) detected. "CC" -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB= 1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DNDEBUG -I"." -c -o "bin.v2/l ibs/thread/build/sun/release/address-model-64/stdlib-sun-stlport/threading-multi /pthread/thread.o" "libs/thread/src/pthread/thread.cpp" move() seems to rely on a copy constructor for its returned thread when rvalue references aren't supported. There is no such constructor. Aside from changing compilers, is there any work around for this?

1 0