October 2010 - Boost - lists.preview.boost.org

[Thread][Release] Boost.Thread and 1.45 release
by Anthony Williams 29 Oct '10

29 Oct '10

Hi, I've fixed all the outstanding "showstopper" bugs in boost.thread on trunk (including the thread interruption issue, #2330), apart from #3847 (https://svn.boost.org/trac/boost/ticket/3847) - "Unable to statically link thread lib on ia64" I don't know how to fix this, and this platform doesn't appear to be actively tested. Is it OK to merge the other fixes to the release branch? Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

3 8

[constrained_value] Constrained Value review results
by Gordon Woodhull 29 Oct '10

29 Oct '10

Greetings, Substituting for Jeff Garland, I am pleased to present the results from the constrained_value review. The library is available at http://rk.dl.pl/f/constrained_value.zip The documentation is at http://rk.dl.pl/r/constrained_value Enjoy! Gordon 1. History The idea for a constrained value library goes back to at least 2004; Christopher Diggins proposed a mini-library at that time. In 2007 Joe Gottman suggested that Jeff Garland's constrained_value.hpp in date_time could be a top-level library. Concurrently, Robert Kawulak (henceforth RK) was working on his own library for the purpose, which he also started in 2004, unaware of the others. RK announced his library on November 11, 2007. Discussion continued into 2008; on June 19, RK announced his library was ready for review and it was put in the queue. The review began on December 1 2008 and continued until around December 15 (with some trailing discussion of the definition of invariant and why exceptions should not be used to check invariants). Gordon Woodhull reviewed the thread's 260 messages in the summer of 2010 and produced this report, dividing the issues raised between those where there was consensus on a change, those where no resolution was found, and those where the author and requesters (mostly) agreed that no change was needed. 2. Votes Eight people voted for acceptance of the library; there were no "no" votes. However, many people stated conditions on acceptance. Thanks to Chris (indy271828(a)sympatico.ca) Vicente Botet, Zach Laine, John Maddock, Thorsten Ottosen, Stjepan Rajko, Daryle Walker, and Gordon Woodhull for providing reviews. (In addition, Paul Bristow provided a review which looks like a yes but does not explicitly say so.) Thanks also to David Abrahams, Kim Barrett, Neal Becker, Paul Bristow, Edward Diener, Jeff Flinn, Joe Gottman, Mathias Guanard, Mika Heiskanen, Giovanni Pierro Deretta, Thomas Klimpel, Michael Marcin, OvermindDL1, John Phillips, raindog, Ravi (lists_ravi(a)lavabit.com) Johan Råde, Sebastian Redl, Peter Simons, Steven Watanabe, Utku Yaman, and Deane Yang for participating in a very active discussion. 3. Issues to be Addressed Floating point By far the most contentious issue in the review was the statement in the library documentation that floating point is not supported, and a few reviewers made fixing this a condition on acceptance. The issue is that the x87 math instructions (which are the default for 32-bit Intel compiles) utilize 80-bit registers which are then rounded down to 64 bits when a double value is written to memory. This can cause two values which were not equal to become equal later, with fairly unpredictable behavior depending on optimization and what code intervenes between calculating a value and comparing it. One solution is simply not to use the x87 math instructions by enabling the SSE2 math instructions instead. However, users may want the extra precision, and there is no way for a library to control this option. A few reviewers confused this issue with the frequent need for fuzzy comparison with epsilon; it was shown that the bug can still appear with epsilon-based comparisons. Jeff Garland points out that the Boost Numeric Interval library, http://www.boost.org/doc/libs/1_42_0/libs/numeric/interval/doc/interval.htm has also dealt with the x87 and NaN problems. It uses the round-trip-to-memory approach for x87. There is potential to create constraints for constrained_value using numeric::interval, and perhaps any other fixes for floating point belong in that library. Many solutions were proposed; after debate there were four left standing: * Force the new value to be written to memory Kim Barrett suggested the following function, noting that it should not force a memory write unless the value is in a register. inline double exact(double const& x) { return *const_cast<double const volatile*>(&x); } Gordon Woodhull has tested this against example provided by Thomas Klimpel in a message titled "floating point FUD" of January 23, 2010 (http://article.gmane.org/gmane.comp.lib.boost.devel/198817) and it does work. However, many people objected to this solution because of efficiency concerns: it requires a round-trip to memory (or at least to cache) for every assignment. * Only allow >= or <= for floating point types, and make sure the bounds are truncated 80- to 64-bit truncation can cause two values to become equal, but if one of them is already truncated, it cannot cause them to swap order. Since it is likely that the value will be changed much more frequently than the bound, it would suffice to apply truncation just to the bounds when they are set, e.g. with the exact() function above. However it does not seem that this solution can work if the bounds are dynamically calculated; the library supports bounds being returned by an inlined function. Johan Råde also suggested that it might be possible to implement < and > in terms of <= and >= and the std::nextafter function. * Force the processor to use 64-bit precision Johan Råde mentions a floating point control register which could be used in http://article.gmane.org/gmane.comp.lib.boost.devel/183760 There were also mentions of possible assembly code solutions, but none were provided and this was generally unpopular because it requires someone very knowledgeable to maintain it. John Phillips argued that reducing the precision will "lose significance faster than expected". * Another interesting solution was suggested by Stjepan Rajko: that the test might not be the same as the invariant. This is what testing with epsilon would guarantee. If the value passes the test it is guaranteed to satisfy the invariant, but only the test and not the invariant is in code. So some values might be rejected which are okay, but no bad value is accepted. RK felt that any floating point solution should be implemented separately from constrained_value, because he does not have the expertise. But he should be willing to document the scope of the problem better, including the SSE2 compiler flags that avoid the problem altogether. The first solution (truncation of the value) does not seem to require any changes to the library. Truncating the bounds might require some extra customization points. NaN Another problem with floating point is NaN, which compares false with everything. It might be okay if the bounds inclusion test always returned false. But the closed range is implemented as !(x < lower) && !(upper < x). Stjepan Rajko suggested that it should always be compare(lower, x) && compare(x, upper) where compare is < for excluded bounds and <= for included. It seems like this solution would work well for floats but not necessarily for user-defined types, which might only define operator<(). Substitutability with the underlying type A few people requested the ability to set a compiler flag in order to substitute the constrained_value with the underlying type. This is not exactly possible, unless the user is willing to explicitly extract the value using static_cast<T>(cv). The library does provide unconstrained<> which in most cases optimizes away, but the interface is not perfectly compatible with the underlying type. Constraints not copied when operators used The use of operators invokes implicit conversion to the underlying type, which means that in a statement like constrained_value x(10, constraint(...)), y(-x); y ends up with uninitialized constraints. Steven Watanabe suggested that the operators could be overloaded, but RK argued that the behavior would be application-specific: "For some applications returning a constrained value would be OK (but again there is the problem that the constraint may reject the modified value) while for others it's better to return the underlying type." Constrained strings Jeff Garland offered that he has written constrained_string classes for allowing values from a set of strings, and for validation against a regex. RK said he might add a constraint type which validates against set<T>, and affirmed that a regex validator would be nice too. Bounding on only one side Utku Yaman and others requested a way to bound integers on only one side. RK noted that you could set one of the bounds to the maximum or minimum possible integer, but this is verbose. Default arguments would be confusing, and RK thought maybe he would supply lower_saturating_int and upper_saturating_int. Note that there is a more general problem, especially if floating point is allowed. (Also consider e.g. fixed point, rational.) Recoverable error policy - error policy changing the value There were some objections to the error policy taking three parameters - the new value, the member value, and the constraint. Does it really need to change the member value? Yes, RK explained, because this is a recoverable error policy. Vicente Botet asked that the concept be called RecoverableErrorPolicy. Serialization Neal Becker requested support for serialization. RK agreed this is worth looking into and pointed out a couple of difficulties. One, a way to not serialize empty (or static) policies is needed. Two, non-default constructible types such as odd_number might require use of load_construct_data() / save_construct_data() instead of serialize(). Rename bounded_int This class name does not convey the fact that the bounds are specified at compile time. Neal Becker suggested compile_time_bounded or static_bounded. RK says the first name is too long, and the second might imply that the bounds are static members (which is also a legitimate use case). sizeof static constrained types == sizeof underlying type Assuming that the empty base class optimization is being applied correctly, which seems to be the case, if the constraint and the error policy are empty, the size of the constrained value should be the same as the size of the underlying type. However, this was not the case on all platforms, at least at the time of the review. The library should include sizeof tests in its test suite so that potential users know if there is unexpected overhead on their platform. Specify static bounds as open<0>, closed<100> for bounded<> and bounded_int<> Requested by Vicente Botet. If possible, this would reduce the number of template arguments and would be more clear than the current bounds exclusion boolean parameters. Some default constructions may throw If zero does not satisfy the constraint, then a default-constructed constrained value may throw an exception. (There are other examples, like non-empty string.) Many reviewers requested a means to provide a default value, which can be done by wrapping the underlying type, but RK felt a default value class was out of scope. At the very least this should be documented and probably an example given. Examples Vicente Botet requested: * an example showing how to create a constrained class by derivation and/or containment which adds/removes methods from the constrained value interface * a date example where changing the month affects the bounds for the day. * example of static bounding on only one side * example of bounds calculated at runtime by a function ("runtime dynamic bounding") Others: * example of constraints with static members - allows shared mutable constraints with no overhead per instance. Tests! Many reviewers were offended that there were no tests in the review version. RK said he would write some. Documentation * document the concepts and provide tests with concept archetypes. It turns out that these are documented briefly in the doxygen documentation of constrained<> at http://tinyurl.com/39v8o6r, but many reviewers were expecting a section in the main document. * Stjepan Rajko pointed out that the constraint can't depend on mutable members of the underlying type, and wondered if there were other implicit requirements, such as the way copy construction or swapping works. He requested these be documented. * Gordon Woodhull suggests a section on space efficiency and which configurations should allow the size to be optimized to the same size as the underlying type, and spelling out in each example what the cost in space is. * Thorsten Ottosen requested benchmarks of non-checking unconstrained against just using the underlying type. RK offered that he had looked at the generated assembly on some platforms. 4. Unresolved debates Error policy is allowed to change constraint Vicente Botet objected to the "bounded object with memory" example, which tracks extremal values by setting the bounds to include any new values. And Thorsten Ottosen objected to the inefficiency of change_constraint using construct-and-swap: it's not necessary to swap the constraint unless it might be changed by the error policy. This seems to be an example of a monitored value, which RK does not want to write himself, so does it belong in this library? RK argued that it does no harm, so why not allow? Double-checking and disabling assertions A number of people were concerned with the inefficiency of first checking the constraint, and then also asserting that the constraint is satisfied after the assignment has happened or the error handler has been called. But RK argued that it was necessary to check the invariant to make sure that the assignment operator and the error handler are doing their job. Besides, it is possible to disable the asserts with either BOOST_DISABLE_ASSERTS or NDEBUG. There was some discussion of adding an assert policy or a specific macro (with no clear conclusion). Disabling checks There is unconstrained, which offers a way to replace one constrained type with an unconstrained type, but Chris (indy271828(a)sympatico.ca) requested a way to disable all checks with a single macro. It might not be good enough to use a single error policy and select between throwing version and an assign-anyway version, because the compiler won't always optimize this away. More members, less free functions Thorsten Ottosen thought that any functions which change the state of the object should be members, not free functions. In particular, change_constraint might be less efficient than possible because the construct-and-swap requires copying the constraint. This does seem to be partly an ideological debate. Specific classes instead of a general super-template Vicente Botet requested that the interface use specific classes instead of typedefs: currently many of the specializations, like bounded<>, are metafunctions that apply some parameters to the generic constrained_value and return a new type, and then the specific operations are free functions. Instead these could be full classes with member functions. RK argued that this would result in unnecessary duplication. Way to disable the arithmetic operators Vicente Botet requested a solution in code or in documentation for users who don't want the arithmetic operators defined. 5. Ideas not requiring any action Monitored Values Stjepan Rajko suggested (and Vicente Botet expanded on the idea) that constrained value is really a special case of a more general "monitored value" class, in which a monitor policy decides how to handle any assignment. So constrained value would be a monitored value where the monitor policy checks a constraint, possibly calls an error policy, and then asserts the constraint. RK did not want to implement this and resisted suggestions to allow the assertion to be disabled in order to allow this use case, because without an invariant, it's not really a constrained value. But he suggested that monitored value could be implemented by someone else and constrained value could be re-implemented in terms of it. "Monitored value" might not be the best name for the general class, because "monitor" suggests something passive, rather than something which controls the outcome of assignment. A way to run a function on a constrained value Stjepan Rajko requested a way to make a copy of the value, run a function on it, and then reassign back, preferring the syntax call_using_copy(f, x) to x = f(x). But he notes this could be written as a free function. Multiple ranges Edward Diener requested a way to supply multiple ranges, but agreed that the syntax would be unattractive. Assertions instead of exceptions Thorsten Ottosen requested a way to have only assertions and no exceptions, and RK pointed out that this can be done either by specifying an error policy which asserts, or even with an assign-anyway error policy, which leaves the invariant checking in place. Exclude bounds parameter Vicente Botet found it confusing that bounded_int takes false to mean include bounds and true to mean exclude the bounds. RK explained that this is an artifact of the way within_bounds is templated on a type which can be either a compile-time or a runtime value, e.g. mpl::true_ or bool; this technique means there can be no default argument to the constructor and thus the more common option must be false, the default constructed value of bool. Constraints between several variables. Vicente Botet suggested a sort of constrained_tuple where if you set one field it would affect the constraints for the other fields. E.g. a date object where the month and year would affect the valid range for the day. With the current interface you'd have to set the whole date at once. Constrained values as sets of instances Exploring the problem domain, Vicente Botet suggested another possible implementation of constrained value where the constrained value type keeps track of which instances satisfy the constraint. This class would offer a split operation which moves any instances which satisfy a more specific constraint into the new set. Changing the constraint would similarly return the set of instances which are now excluded.

12 49

Boost Threading Shared Memory
by Tanya Gillis 29 Oct '10

29 Oct '10

I have a question regarding Boost threads, and am awaiting acceptance into the Boost Threads forum. I was wondering if anyone can help me. I am creating a multithreaded application using Boost threading, and would like to know how shared memory is implemented by Boost for threading. Each thread creates an object separately, and that object has a private member variable. We are seeing in our application that that member variable is looking the same, as if it was shared among the threads. Is this plausible? How does it work? Thanks.

2 1

Call for interest - BOOST_AUTO_FUNCTION
by Matt Calabrese 28 Oct '10

28 Oct '10

I've been noticing that a lot of times in 0x code I've found it useful to create a very simple "auto function" macro that uses trailing return type syntax with decltype with 1-liner functions that automatically repeats the same expression in both the return type and the return statement. #define AUTO_FUN( name, param_list, expression ) \ auto name param_list -> decltype( expression ) { return expression; } There are two big advantages to this. The first and most obvious one is that it reduces redundancy when you have a 1-line function template which has a difficult to deduce return type that you generally would use decltype on, and the more subtle benefit is that since the exact expression is repeated in the return type you automatically get "perfect-fit" SFINAE. By that I mean it provides a quick way to SFINAE-out potential instantiations before instantiating the implementation. Because of this, even though a return type may be simple to deduce without decltype, the macro is still a valuable tool since it can cause substitution to fail if the body of a function template would fail to instantiate. You get very basic, automatic, syntax-only concept checking for free. It's a simple macro, but I find that it gets lots of use. As an example: http://codepaste.net/iqzbiz The above example is a simple "multi_cast" that chains several static_casts in a row (the example code shows a potential use-case). The subtlety here is that the return type is easily deducible without the need for decltype (the return type would just be "TargetType"). Instead, the macro is used because it causes substitution to fail if the body of the function would fail during instantiation. So when using "multi_cast" here, If someone attempts to do a cast where any of the intermediate types is not a valid conversion, rather than getting a complicated error nested inside of several instantiations, you get a single error message at the top-level call-site stating that there is no match for the function call (well, at least it's a simple to read error in gcc... *cough*). This works because if the body of any of the calls would have an error, substitution would instead fail, meaning substitution would fail for the caller, all the way back up to the top without any bodies being instantiated. In other words, it's SFINAEs all the way down :| I find this type of functionality to be very useful, particularly in libraries. In fact, I find myself using it for just about all 1-line function templates. Do others agree that this would be a worthwhile addition to boost? Documentation should be quick to write up. The macro would of course be renamed to something along the lines of BOOST_AUTO_FUNCTION If anyone thinks multi_cast would be useful, let me know and I'll also spin off a separate thread for that, though I'm tempted to think it's more of a curiosity than something that would get much use. -- -Matt Calabrese

11 54

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

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

Anyone have access to Sun Studio 12 compiler?
by Marshall Clow 23 Oct '10

23 Oct '10

I have a bug report on that compiler (Sparc, Solaris 9) that I don't have any way to reproduce. Thanks! -- Marshall There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

3 5

Git mirror
by Vladimir Prus 23 Oct '10

23 Oct '10

It seems like there's a git repo that is supposed to mirror SVN, at: http://gitorious.org/boost/svn/commits/master But the last commit there is from Sep 15. Is this the way it should be? - Volodya

4 5

Re: [boost] [Boost.Serialization] Detecting if Boost.Serialization is supported for a type
by Ben Hendrickson 23 Oct '10

23 Oct '10

Loannis Papadopoulos wrote: > I successfully made a template supports_boost_serialization<T> that > detects if T::serialize() exists. > > However, I cannot address the case of a stand-alone serialize() function > - since there is a generic boost::serialization::serialize(Archive&, T&, > const unsigned int), there is not way (that I know of) to figure out if > non-intrusive serialization exists for a specific T. Another hard case is inherited serialize methods - consider class T inheriting from class B, and B::serialize() exists. Does your implementation of supports_boost_serialization<T> detect that? If it does, I am interested in how. Ben

2 2

need to get boost compiled so I can get Shareaza built
by Kevin Simonson 22 Oct '10

22 Oct '10

I'm trying to get the Shareaza source code to build in my local directory. When I try to build the only error I'm getting now is "Cannot open include file: 'boost/cstdint.hpp': No such file or directory". So it looks like I need to compile Boost. Some time back I went to the sourceForge "Developers.GettingStarted.Boost" page (I'd been referred there by a document that said I needed to compile Boost to be able to build Shareaza), and followed its instructions to the point of copying "bjam.exe" into my "boost_1_44_0\boost_1_44_0" directory, next to "boost.css". The next thing it said to do was to open "a command prompt window, and navigate it to the boost_1_33_1 folder where bjam.exe is located," and then paste "the text below onto the command line, and press Enter." The text in question was "{{{1}}}". I assumed that what this meant was to execute "bjam {{{1}}}". But when I actually did execute "bjam {{{1}}}" I got the messages: warning: No toolsets are configured. warning: Configuring default toolset "msvc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: could not find main target {{{1}}} notice: assuming it is a name of file to create. nBuilding the Boost C++ Libraries.nn warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. don't know how to make <e>{{{1}}} ...found 1 target... ...can't find 1 target... The docs said executing this command would cause a "C:\Boost" directory to be created, but one wasn't, so even if the error messages didn't look discouraging, it's pretty clear that I didn't accomplish what I needed to to get Shareaza compiled. And running the Shareaza build afterwards generated the complaint about "boost/cstdint.hpp" anyway. So my question is, what do I have to do to get Boost compiled, so that I can go on and build Shareaza? I'd appreciate any information you can give me. Kevin S

4 4

[1.45] Thread issues
by Bryce Lelbach 22 Oct '10

22 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 https://svn.boost.org/trac/boost/ticket/3847 https://svn.boost.org/trac/boost/ticket/3882 https://svn.boost.org/trac/boost/ticket/4614 https://svn.boost.org/trac/boost/ticket/4632 https://svn.boost.org/trac/boost/ticket/4258 https://svn.boost.org/trac/boost/ticket/4736 A few of these are related or similiar in nature. Long story short, Boost.Thread has some rather serious issues on mingw. One report indicates that statically linking Boost.Thread with VC8 and VC10 is broken. These are quite serious. The library maintainers have not responded to any of these tickets. The mingw problems are reproducible for me, the supposed VC problem appears to work for me. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzAlJEACgkQO/fqqIuE2t65YQCeNKpTO1+9IdAGleAPY+3XFIeC wIQAoImdTt1vpQjvxc0+hJ4jyQ9G9QaA =vck0 -----END PGP SIGNATURE-----

6 8