August 2005 - Boost - lists.boost.org

Re: [boost] Interest in an ODBC library?
by Corwin Joy 28 Aug '05

28 Aug '05

Looking at the issue of how to declare the binding functions, what I had proposed below (which is what I did in DTL) is remarkably similar to the functions required by the boost serialization library so it really might make sense to leverage off of that as pointed out earlier. There are a few "extra" things we do in DTL binding that I don't see in the serialization library which should be highlighted though: 1. Binding types. If you want to execute a stored procedure then when you bind a column or parameter you have to store information about the binding type (input, output, in/out). 2. Validation / final construction before save and load. In DTL, after the members in a class have been initialized from the database, we optionally allow the users to associate a validation function that can be used to perform any final class construction tasks including how to handle NULL fields. So e.g. we might have a class like: class { string Location; bool Location_is_null; double TempInCentigrage; double TempInFarenheit; } In the database, only Location and TempInCentigrade will be stored. When the class is initialized from the DB, only these two fields get set and we call a UserValidate() function to let the class finish constructing and initialize the rest of its internal state. Here is a link to the DTL documentation for further examples, we call this function SelVal there: http://dtemplatelib.sourceforge.net/SelVal.htm Similarly, we also have an InsVal that enforces any final validations or calculations that need to be performed prior to writing to the database (auto-generated keys are one common application, as are policies on how to handle NULL values). Honestly, I'm kind of surprised that boost:serialization does not have a similar concept, it may be that I just didn't look hard enough through the docs.

1 0

Re: [boost] Interest in an ODBC library?
by Brian Braatz 28 Aug '05

28 Aug '05

> On Behalf Of Hajo Kirchhoff > > Brian Braatz wrote: > > you split the lib into a few pieces: > > > > 1- Get the data from the data base and stream it into X > > 2- a stock form of "X" (like the table you described) > > 3- Helpers for binding > > > > if you built the thing that way, then it will be usable by those of us > > out there who have large bodies of code relying on things like ADO > > recordsets. I would love to replace the recordsets, but I need to be > > able to selectively use pieces of your library and I need to have a > > usage model that is similar. > > > > Thanks, interesting thoughts. > > Hajo > [Brian Braatz Writes:] If you are interested in collaborating, I have wanted to (for some time now) build the table<> aspect of what you are working on. My goals: 1- functional drop in replacement for ADO recordset 2- Dynamic and static "views" and indexes 3- binding model that does NOT force you to use the bindings supplied with the library this is something ADO lacks, and something I have had to work around to great frustration 4- the ability to COPY from one table<> to another table<> * ADO does NOT ALLOW you to copy recordsets. (brilliant no?) Additionally - I am not sure if he is still interested, but Joaquin Munez and I exchanged emails awhile back about collaborating on such a beast. The general idea was to take the functionality in multi-index container and make it work dynamically. (and there is more) I am working on something unrelated to this discussion that could form a good foundation for table<>. I should have something to share middle of next week. Just let me know if you are interested in putting our heads together. :) Brian

9 43

Range adaptor for adjacent_difference
by Chad Parry 28 Aug '05

28 Aug '05

(Resending to the Boost distribution list.) I have a suggestion for the range_ex library. It is such a useful library -- IMHO, the Boost.Range library is useless without it. I would also like to see it include a numeric.hpp that has a version of adjacent_difference, etc. In my mind, any standard algorithm that takes an input iterator and an output iterator as parameters could be rewritten as a range adaptor. I attached a sample implementation. It's not done using Boost coding standards or anything. BTW, I also found the "tail" (a.k.a. "pop_front") adaptor to be useful in conjunction with adjacent_difference. Here's how I use it in my toy project: QuoteSum sum( accumulate( make_ResUse_range(result) | boost::adaptor::transform( boost::bind(adaptable_constructor<QuoteAddend>(), boost::bind(&parseTimestampColumn, boost::bind(&mysqlpp::Row::operator[], _1, 0) ), boost::bind(&mysqlpp::Row::operator[], _1, 1) ) ) | adjacent_difference() | tail(), QuoteSum(), AccumulateQuotes(inverseYearDuration, annualMeanRate) ) ); Thanks for the work that went into the library -- I hope it gets adopted. I personally find it much more powerful than BOOST_FOREACH. -- chad

2 1

[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