- Boost - lists.boost.org

New video from Boostcon
by Marshall Clow 28 Oct '10

28 Oct '10

Roshan Naik: Logic Paradigm for C++ http://blip.tv/file/4307883 Some people have asked about Doug Gregor's Clang talk. Unfortunately, Doug's employer nixed recording that one. -- Marshall

1 0

Bidirectional streams/archives - Frames
by vicente.botet 28 Oct '10

28 Oct '10

Hi, The use I have is to implement binary messages that are user through protocol stacks. When sending a message, lower layers add usualy headers and trailers to payload comming from the upper layer. When receiveing a message, lower layers extract its corresponding headers and trailers before passing the payload to the upper layer. I'm thinking in generalizing the stream or archive concept, so we could in addition to been able to read from the begining and write at the end, been also able to read from the end and write from the begining; a kind of bidirectional stream or archive. I was thinking in namming the concept "frame", as frames are usualy composed of header, payload and trailer. Do you have other namming sugestion? Could this concept have any interest for Boost? Please, let me know if there is already someting on Boost or the standard library that could help me. Best, _____________________ Vicente Juan Botet Escribá

2 2

spirt status?
by Robert Ramey 28 Oct '10

28 Oct '10

What is the situation of the spirit library in the trunk? The serialization library now depends upon the latest spirit to parse xml archives. But now serialization can't be built for a number of compilers which previously could handle this library. This was not a surprise to me as its not unusual to require some tweaks to get this to work. But now I'm surprised that this hasn't resolved the issue. The newer version of spirit has been around for at least a year, and the serializaiton library xml grammar is very simple compared to other spirit applications so I didn't anticipate any major problems - but it seems that we now ahve them. Could spirit library developers take a look at this and give us an idea of what we should do about this? Is anyone working on this? Should we just roll back and try again before the next release? Robert Ramey

7 11

[gil][io_new] Problems with templates
by Christian Henning 27 Oct '10

27 Oct '10

Hi there, I don't see the woods because of all the trees. Could someone get the latest code from here: http://code.google.com/p/gil-contributions/source/browse/#svn/trunk and try to compile the following code: #include <boost/gil/extension/io_new/tiff_all.hpp> using namespace std; using namespace boost; using namespace gil; int main() { typedef mpl::vector< gray8_image_t , gray16_image_t , rgb8_image_t , gil::detail::gray1_image_t > my_img_types; any_image< my_img_types > runtime_image; read_image( "C:/gil_contributions/test_images/tiff/test.tif" , runtime_image , tiff_tag() ); return 0; } Why do I have this static assertion in read.hpp[662]? I don't understand why the two buffer types are different. Any help is very welcome, Christian

2 4

Google Code-in 2010 (another Google program like Summer of Code)
by Boris Schaeling 27 Oct '10

27 Oct '10

Boost is invited to become a mentoring organization in the Google Code-in 2010 program. If you have never heard about it (like me :): It's basically Google Summer of Code for pre-university students (the most important requirement is that participants are between 13 and 18 years old). This program is organized as a contest though: It's not so much about mentoring but setting up tasks in eight categories (writing code, documenting, translating etc.). Students will pick then tasks, and judges from participating organizations decide who won. :) While I've no idea if there is any interest to participate in this new program (are there any pre-university students on this mailing list for example?) I wanted to forward the invitation at least. As the deadline to apply as a mentoring organization is 29 October there is not much time left to decide either. Boris

4 7

[interprocess] Documentation for containers is missing
by vicente.botet 27 Oct '10

27 Oct '10

Hi, the documentation for the containers is missing since 1.44. Ion, could you se what can be done? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 1

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 26 Oct '10

26 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