- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1274839 ] bind/placeholders.hpp breaks GCC 3.4 + precompiled headers
by SourceForge.net 27 Aug '05

27 Aug '05

Bugs item #1274839, was opened at 2005-08-27 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274839&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: Mark Rodgers (mark_rodgers) Summary: bind/placeholders.hpp breaks GCC 3.4 + precompiled headers Initial Comment: Like a number of other compilers, GCC (version 3.4.3) appears to have problems related to precompiled headers that contain anonymous namespaces - such as the one in bind/placeholders.hpp. There seems to be some consensus that it currently does have issues in this area (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591) I noticed the workarounds in bind/placeholders.hpp (Boost version 1.33.0) for other compilers, and tried them with the above version of GCC. I discovered that only the work-around using static inline wrapper functions (i.e. the one for Borland compilers) seems to work. I've only encountered this problem in bind/placeholders.hpp. However, this problem could presumably exist anywhere anonymous/unnamed namespaces are used. This seems to be a one-line fix. I'll submit a patch file, separately. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274839&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Feature Requests-1274707 ] Remove try/catch(...) in thread.cpp:thread_proxy()
by SourceForge.net 27 Aug '05

27 Aug '05

Feature Requests item #1274707, was opened at 2005-08-27 14:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: thread Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Gruenke (mgruenke) Assigned to: William E. Kempf (bill_kempf) Summary: Remove try/catch(...) in thread.cpp:thread_proxy() Initial Comment: THE CASE AGAINST try {} catch (...) {} IN libs/thread/src/thread.cpp:thread_proxy() The only platform on which I've used boost::thread is Linux + GCC. So, on the debugging front, I can only speak to that. In this configuration (using pthreads), the behavior of an exception being allowed to propagate outside of a thread function is quite useful - you get a backtrace of the entire call sequence leading up to the throw, AND a full unwind back from that point (which looks like further entries in the call stack). However, if an exception is caught & rethrown, all of the prior call & unwind history is lost. Obviously, this also happens if an exception is caught and not rethrown - which is the current (circa version 1.33.0) behavior of thread_proxy(). I've tried a number of experiments, as well as inspecting pthreads & glibc code, and have been unsuccessful at reproducing this behavior in user code. However it's so useful that, on virtually every project where I'd like to use boost::thread, I eventually resort patching the source to remove this last-resort try/catch block. For a library to be of much practical value, debugging must not be significantly impaired (and even enhanced, where possible without significant compromises). The additional complexity of multithreaded programs makes this all the more important. I think this point stands pretty well, on its own. A more troubling aspect of this try/catch block is that the thread terminates in exactly the same way via an otherwise unhandled exception as it does when the user-supplied threadfunc exits cleanly. If the user of boost::thread didn't think to catch the particular exception in question, then it's unlikely it employed and is inspecting any other mechanism for determining whether the thread accomplished its goal. This assumption violated, it's unsafe to assume the program will continue to function correctly. Since the thread exists in the same memory space as the rest of the process (and shares library state, if not also other data structures), an unhandled exception indicates bad state in the process, or some other invalidated assumption. In fact, in non-exception-safe code, it may even produce bad state. Any of these conditions makes it unsafe to assume the program will continue to operate correctly. Finally, there's a more philosophical point that should probably be made. The primary purpose of exceptions is to provide proactive notification of program errors (as opposed to relying on return codes - which facilitate errors being silently ignored). Why should behavior of uncaught exceptions in other threads be any different than main? Yet thread_proxy() just quietly drops them on the floor. As a user, I normally expect that no unhandled exceptions were thrown, if my program runs to completion. WHAT WILL HAPPEN IF IT'S REMOVED? If the user specifically wants this behavior, it can suitably augment its user-supplied threadfunc to contain the catchall. There's nothing wrong with simply stating that the behavior of exceptions that propagate outside threadfunc is undefined. While changing this might "break" some existing code, it's really quite likely that code is already broken - though the user simply doesn't know it. IMO, there's nothing wrong with libraries evolving to detect more errors and invalid conditions. CONCLUSION In summary, I believe the current behavior is: 1. Dangerous - hides program errors in a most un-exception-like manner. 2. Unfriendly - defeats useful debugging functionality, on some platforms. 3. Surprising - users don't expect libraries to inhibit propagation of their exceptions. 4. Unnecessary - the user can easily supply this behavior, if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1274707&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-08-27)
by Douglas Gregor 27 Aug '05

27 Aug '05

<html> <head> <meta http-equiv="refresh" content="1; url=issues-email.txt"> </head> <body> <p>Update in progress (building archive index, done in approximately 19 seconds), please wait...</p> </body> </html>

1 0

Preparing for 1.33.1 ?
by John Maddock 27 Aug '05

27 Aug '05

So.... it looks like we have a number of small niggles, not least of which is the shared_ptr problem, so do we go for a 1.33.1 release? Assuming "yes", can everyone who's made changes to the RC_1_33_0 branch, please make sure that those fixes are logged in the news section of index.htm. I've added preliminary entries for config, shared_ptr and regex, but the following libs also have changes: hash, iostreams parameter program_options serialization test The plan then would be to produce an early *beta* of the tarballs/zips sometime soon (I may be able to do this on Saturday), this would act as an initial hotfix release as well as the first beta: we can then move on to a fairly leisurely cycle (two weeks or so?) of one or two more betas, followed by a final 1.33.1 release. The aim would be to: * Give lib authors more time to fix any issues that may have come up. * Test a beta release procedure and see how it works out. * Give uses a little more time to report critical issues that still need fixing, but aren't in the Beta. We also need to decide how much of our testing resources to devote to testing 1.33.1: this is the biggest argument against another release, we do not want to stall main branch development. How does this sound to everyone? John.

15 21

[Boost-bugs] [ boost-Bugs-1274584 ] wave crashes with this input
by SourceForge.net 27 Aug '05

27 Aug '05

Bugs item #1274584, was opened at 2005-08-27 15:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274584&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jmihalicza (jmihalicza) Assigned to: Nobody/Anonymous (nobody) Summary: wave crashes with this input Initial Comment: wave.exe crashes when it is given this input. Using a debugger it turns out that in cpp.re in the fill function memcpy gets a negative number as count (-> very big positive number 'coz size_t is unsigned) -> crash. Somehow s->lim == 0, this is why count becomes negative in memcpy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1274584&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[repost][multi_index][rfc] random access indices
by JOAQUIN LOPEZ MU?Z 27 Aug '05

27 Aug '05

Hello all, I'm considering whether to add to Boost.MultiIndex a new type of indices with random access semantics, somewhat similar to std::vectors. As I wouldn't like to keep adding things to the library without some actual feedback as of its suitability, I've written some preliminary notes about how these indices could look like, located at: http://195.235.93.150/rnd_indices_spec.html I'm very interested in knowing your opinion about this stuff, ways of improving the spec, and most of all whether it is really an interesting thing to have in Boost.MultiIndex 1.34. Please go ahead and comment on this. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[regex] missing header inclusion
by François Dumont 27 Aug '05

27 Aug '05

Hello The sprintf function reference in the using directive at regex_workaround.hpp is declared in stdio.h or cstdio which is not included. This missing header inclusion makes build of boost regex lib impossible with msvc-stlport toolset and surely with many other STLport toolsets. I try to remove the using directive as this function is not used in this file but it is in regex lib sources so the fix is really to add the header inclusion. Bests *** regex_workaround.hpp.orig Thu Aug 25 05:32:32 2005 --- regex_workaround.hpp Thu Aug 25 05:32:50 2005 *************** *** 22,27 **** --- 22,28 ---- #include <new> #include <cstring> + #include <cstdio> #include <cstdlib> #include <cstddef> #include <cassert>

2 2

serialization as generialized I/O
by Neal Becker 27 Aug '05

27 Aug '05

Looking again at mersenne_twister, one of the objections that has been raised to adding serialization support, is that there is already iostream I/O support. It is in principle possible to leverage iostream to do serialization. Unfortunately, that approach is hardly efficient and rather ugly IMHO. But, what about the other way around? If we have generic archive support, can we use it to eliminate the need for iostream? I think so. In fact, consider this code (assuming serialization suport added to mersenne_twister): typedef boost::mt19937 rng_t; int main() { rng_t rng1; std::ostringstream os; boost::archive::text_oarchive oa(os, boost::archive::no_header); oa << const_cast<const rng_t&>(rng1); std::string st (os.str()); std::cout << rng1 << '\n'; std::cout << st << '\n'; } As it is, the 2 outputs are almost identical. There is only one difference: the text_oarchive (,no_header) output prints 2 leading '0' characters. Is there some way to suppress this preamble? If so, then we have a more elegant solution. All we need to do is put in the serialization support and remove the iostream support, since serialization is just a generalization of i/o.

2 2

Redhat boost rpm update
by Neal Becker 27 Aug '05

27 Aug '05

Well, they ignored me again - this is from the posting: * Fri Aug 12 2005 Benjamin Kosnik <bkoz(a)redhat.com> 1.33.0-1 - Update to boost-1.33.0, update SONAME to 2 due to ABI changes. - Simplified PYTHON_VERSION by Philipp Thomas <pth(a)suse.de>

3 2

optional.hpp problem on AIX and fix (forwarded from boost-users)
by Peter Dimov 26 Aug '05

26 Aug '05

Rich Cook wrote: > That fixed it! Thank you very much for your valuable help. > > To be clear, when I replaced line 388 of optional.hpp: > > get_ptr_impl()->T::~T(); > > with > > get_ptr_impl()->~T(); > > My program compiled fine. > > On Aug 26, 2005, at 2:20 PM, Peter Dimov wrote: > >> Rich Cook wrote: >> >> >>> Ah, but does it work on AIX? :-) >>> Sorry, I couldn't resist. (My posts are getting ignored, so I >>> assume nobody uses boost on AIX. >>> >> >> This might well be the case. Have you tried replacing the problematic >> >> get_ptr_impl()->T::~T(); >> >> construct at line 388 of optional.hpp with >> >> get_ptr_impl()->~T(); >> >> or perhaps >> >> get_ptr_impl()->~value_type(); >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0