October 2010 - Boost - lists.boost.org

Review Request: Boost.Process
by Boris Schaeling 27 Oct '10

27 Oct '10

I would like to ask for a formal review of Boost.Process (draft version 0.4). * The source code can be found in the Boost Vault (search for process.zip or click on <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=proces…>). The source code can also be downloaded from <http://www.highscore.de/boost/gsoc2010/process.zip>. * The documentation can be found online at <http://www.highscore.de/boost/gsoc2010/>. If you wonder why the library looks like as it does today I recommend to read the thread at <http://thread.gmane.org/gmane.comp.lib.boost.devel/207594/> which was a kind of unofficial review. :-) Boris

5 8

[function] function wrapping and exception safety recap
by Daniel Walker 27 Oct '10

27 Oct '10

Hi all, While it's fresh on my mind, I just want to recap the previous discussion and to make sure this is brought to Doug's attention. http://thread.gmane.org/gmane.comp.lib.boost.devel/209304 To summarize, there have been several complaints from users who don't use RTTI about boost::function's dependency on Boost.Exception. boost::function has a strong exception safety guarantee and uses boost::throw_exception to implement it. This affords users sophisticated options as to how exceptions are actually thrown (or not thrown in RTTI-free environments), since boost::throw_exception can be defined/customized by the user. This is a great feature for some, but others would prefer a function object wrapper that behaved more like a function pointer; i.e. no exception safety guarantee and no RTTI dependency. The following feature request and patch try to answer this demand by adding a new function object wrapper to the Boost.Function family of wrappers: boost::unsafe_function. boost::unsafe_function is simple to generate with only slight modification to the code that generates the existing boost::function/functionN family. https://svn.boost.org/trac/boost/ticket/4720 Some concerns have been raised regarding the efficiency of the NULL pointer check in boost::function's operator(), but I believe this is a side issue at best and possibly a case of premature optimization. In optimized object code, the overhead of the pointer check is so small that it is difficult to detect (from simple benchmarks with MSVC Release mode and gcc -02). Regardless, in circumstances where aggressive compiler optimization is unavailable, unsafe_function could be used to address this concern as well. (I measured a ~15% reduction in time with gcc -01, for example.) Of course, as Peter and Emil pointed out, one could eliminate the pointer check in boost::function if its default "empty" state actually wrapped a valid function, e.g. throw_bad_function_call(). This may be a good idea by itself, but again, this is tangential to the present feature request to provide a function object wrapper that is independent of boost::throw_exception and RTTI. Finally, there have been suggestions to alter boost::function's exception safety guarantee directly through either policies or constructor options. These solutions are functionally similar to unsafe_function, so preferences between them may be a matter of personal taste. Personally, I like having two distinct class templates for two orthogonal levels of exception safety. Also, I like that anytime I encounter an instance of boost::function, I know it has the same strong exception safety guarantee it has always had, without having to wonder how it was instantiated or constructed. So, in this case, my preference is to expand the Boost.Function family of function object wrappers, rather than alter boost::function itself. Daniel Walker

7 22

[Backtrace] Any interest in portable stack trace?
by Artyom 27 Oct '10

27 Oct '10

Hello, Is there any interest in getting portable stack trace to boost - get something similar to Java's printStackTrace. Basics: 1. Getting stack trace of return pointers 2. Converting this pointers to human readable trace Extras: 1. Create exception classes that capture stack trace on throw (only pointers) 2. Print a trace on catch Supported Platforms: Linux, Mac OS X, Solaris and Windows >= XP using MSVC. Tested on: Linux x86_64, GCC, Linux x86, GCC Linux x86_64, Intel Windows XP 32bit, MSVC 2008 How implemented: Linux/Mac/Solaris with GCC: Capture trace using backtrace Convert trace using dladdr + with demangling Requires: compilation with -rdynamic for fetching symbols Linux/Mac/Solaris with Other compilers: Capture trace using backtrace Convert trace using backtrace_symbols (no demangling) Requires: compilation with -rdynamic for fetching symbols Windows/MSVC Capture trace using RtlCaptureStackBackTrace (XP and Above) Convert trace using dbghelp.lib using SymFromAddr Requires: debug info (PDB files) for fetching symbols All other: Create an empty trace For example: #include <boost/backtrace.hpp> #include <iostream> int foo() { throw boost::runtime_error("My Error"); return 10; } int bar() { return foo()+20; } int main() { try { std::cout << bar() << std::endl; } catch(std::exception const &e) { std::cerr << e.what() << std::endl; std::cerr << boost::trace(e); } } Prints: My Error 0x403fe1: boost::stack_trace::trace(void**, int) + 0x1b in ./test_backtrace 0x405451: boost::backtrace::backtrace(unsigned long) + 0x65 in ./test_backtrace 0x4054d2: boost::runtime_error::runtime_error(std::string const&) + 0x32 in ./test_backtrace 0x40417e: foo() + 0x44 in ./test_backtrace 0x40425c: bar() + 0x9 in ./test_backtrace 0x404271: main + 0x10 in ./test_backtrace 0x7fd612ecd1a6: __libc_start_main + 0xe6 in /lib/libc.so.6 0x403b39: __gxx_personality_v0 + 0x99 in ./test_backtrace Initial Source Code: http://art-blog.no-ip.info/files/backtrace.tar.gz Any interest? Artyom

14 27

Report # 29 (aka 1.45 blockers) is too narrow
by Jim Bell 26 Oct '10

26 Oct '10

I think that boost report # 29 (https://svn.boost.org/trac/boost/report/29) is too narrow a query. If you remove the "Milestone" filter you get nearly fifty tickets marked Showstopper, going back 22 months. A ticket's originator may not know what milestone to fill in, and his/her ticket shouldn't be lost because of that. I think they all need review.

8 15

Seek within a file stream using large offsets - reactivation
by Mateusz Loskot 26 Oct '10

26 Oct '10

Hi, I need to solve problem with seeking streams for large files. The problem leaks on Windows 32 and 64 bit, but the solution I'm looking for needs to be portable to Unix too. I have discussed this issue on #boost IRC and it looks Boost.IOStreams does not provide any cure for it. I've just found this problem was discussed 5 years ago. http://lists.boost.org/Archives/boost/2005/03/83087.php with some interesting suggestions: http://lists.boost.org/Archives/boost/2005/03/83140.php I'm wondering, has been there any motion on any level, Boost or C++ standard, to solve it? I'm looking for recommendation of any solution that would be sensible for this problem. (I can't ask my clients to move to STLport :-)) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Re: [boost] [Backtrace] Any interest in portable stack trace?
by Brian Wood 26 Oct '10

26 Oct '10

On Oct 20, 2010, at 3:47 PM, Artyom wrote: > > > Initial Source Code: > > http://art-blog.no-ip.info/files/backtrace.tar.gz > > > Any interest? I'm not able to access that link so far today. I'm getting a server not found error. Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Phoenix as a Boost library
by Edward Diener 26 Oct '10

26 Oct '10

I am curious to know if Phoenix will ever be released as a Boost library, or is it meant to be forever coupled with Spirit ? I have avoided it because it has never been released separately or had its documentation appear among the list of Boost libraries. I got the impression that it would be released separately, and expected to see it in Boost 1.44, but evidently that did not happen.

9 31

[Boost.Serialization] Detecting if Boost.Serialization is supported for a type
by Ioannis Papadopoulos 25 Oct '10

25 Oct '10

Hi, I have two methods of serialization and I would like to choose between them. One is Boost.Serialization and the other is my hand-made one. Is there any (relatively) portable way that can allow to find out if Boost.Serialization is supported either through the intrusive or the non-intrusive way without requiring from the user to add more in her class to define the serialization method? Thanks

2 4

Interface for configuring third-party dependencies
by Vladimir Prus 24 Oct '10

24 Oct '10

Boosters, it seems that increasing number of upcoming libraries want to depend on third- party dependencies (Locale and GIL.IO being examples) and it would be nice to agree beforehand on an interface that is acceptable to everybody. This email attempts to suggest such interface. = Configuring location of dependencies = In general, for each external dependencies Boost.Build should try to check if it's available without configuration -- that is, in locations normally searched by the compiler/linker. If that fails, user has two way to help the search process. First, it will be possible to specify environment variables (either in OS environment, or using Boost.Build -sVAR=VALUE command-line option). For example, given a name of external dependency of 'zlib', the used variables are: - ZLIB_INCLUDE_PATH - ZLIB_LIBRARY_PATH - ZLIB_LIBRARY_NAME - ZLIB_ROOT The first two specify where the headers ahd libraries are located. The third specifies how the library file itself is named (and has sensible defaults most of the times). ZLIB_ROOT is a shortcut to set both include path and library path to $root/include and $roo/lib respectively. This approach is fairly easy to use for one-off builds of Boost by users. Second, it will possible to specify external dependencies in user-config.jam, or any other configuration file. This approach is slightly more complicated, as one has to edit a config file, but retains configuration and permits to specify multiple configuration for an external dependency -- which is not possible using environment variables. Roughly, the syntax will be: using zlib : condition <target-os>windows : include-path whatever : library-path something-else ; The 'condition' parameter specifies when this declaration will be picked up. Other parameters mirror the environment variables above. = Controlling use of external dependencies = Sometimes, it might be desirable to disable use of external dependency even when it's available. To than end, for each external dependency a new feature should be provided, for example: use-zlib When a value of "off" is specified, zlib won't be used by any boost component. Also, for every specific library that uses an external dependency, a more specific feature will be defined, for example: iostream.use-zlib to control use of that dependency in specific library. Does anybody have comments on this? Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

8 17

[interprocess][iostreams] trac#4234
by Domagoj Saric 23 Oct '10

23 Oct '10

As part of my work on GIL.IO2 (https://svn.boost.org/svn/boost/sandbox/gil/boost/gil/extension/io2/detail) I've somewhat improved/generalized the original 'proof of claim' code from the post mentioned in the ticket (https://svn.boost.org/trac/boost/ticket/4234) However, in the same process I've gone through the Interprocess implementation of memory mapped files and AFAICT the various platform specific distinctions seem unnecessary: - AFAIK the POSIX 'anonymous inheritable' shared memory functionality is also available on Win32 - kernel-life time shared memory emulation with memory mapped files on Windows is also unnecessary. It can be either provided directly by bypassing the Win32 APIs using the native NT API (I volunteer to help with the implementation or can do it from scratch by myself) or a new distinction can be made (that does not have anything platform specific in its interface) such that a user can choose between a handle/process life time (which I suppose would be enough most of the time, because what use is there for a client to map a shared memory region after the server has already terminated) or kernel life time shared memory regions (which would then be emulated on Win32)...AFAICT the only thing the Win32 API lacks for this is getting the size of the mapped region which could perhaps be emulated by passing the size at the begining of the mapped region... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 4