- Boost - lists.boost.org

[thread library rework] Ready to start
by Ion Gaztañaga 30 Aug '05

30 Aug '05

Hi to all, As previously discussed here, I'm trying to organize a boost thread rework in order to help C++ thread standarization. In this moment, Kevlin Henney is working on a paper to be presented int the next ISO meeting based in his C++ thread work which is available here, in this presentation-paper: http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf This approach proposes futures approach to C++ threads, and also defines lock mechanisms similar to boost::mutex and boost::condition with some changes. I've contacted with Kevlin and he is ready to help as much as he can with the Boost community to develop a good thread proposal. The idea is that we could have a working implementation of the proposal above boost threads. The presentation-paper does not currently cover all the functionality we have, like thread specific storage, barriers and read-write locks neither proposed message-queue, so there is a lot of work to do. There is an active discussion on futures that can be added to this effort since it proposes future-operations that are not incompatible with the proposal, but an extension. We need to keep the thread discussion constructive and effective, although any of us has strong opinions on threading. It would be nice if we could first concentrate in "basic" functionality that does not forbid future proposals. For example, thread cancellation is a hard issue, but it can be added later if the proposal allows to do that. I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading. There are many areas to cover, but in this post I would like to say that the reworking effort is alive and we need to do some serious work. Like always, ideas are good but work is better, so let's try to avoid extremely long discussions so that we can have C++ threads in the following standard. I'm ready to try to organize a bit the effort and Michael Glassford, mantainer of boost threads, is ready to help, although he has no much time. Anyway, we know there are some good thread implementations out there, and we can take some ideas. And let's try to create a basic, simple, working thread tools but without forbidding extensions in the future. For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory. I plan to add more features detailed in the paper soon (mutexes, conditions, etc...) above boost threads, because it provides a good portable framework. Currently there is no other documentation that Kevlin's presentation, but I will start making some boost documentation in this library, once we start defining more elements. I will try to write some posts regarding concrete issues, like barriers, read-write mutexes or message-queues so that we can focus the work. Obviously if anyone wants to join this effort with ideas, code, organization etc... we can split the work on several issues. Regards, Ion P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.

4 9

serialization support for std::complex and boost::ublas::vector
by Neal Becker 29 Aug '05

29 Aug '05

Here are a couple of useful additions for serialization. std::complex is pretty trivial, and a no-brainer IMHO. I implemented support for ublas::vector unbounded_array only. Would be nice to do more, but that's all I need at the moment. #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/split_free.hpp> template<typename Archive, typename T> inline void save (Archive &ar, const std::complex<T>& z, const unsigned int) { ar << real (z); ar << imag (z); } template<typename Archive, typename T> inline void load (Archive &ar, std::complex<T>& z, const unsigned int) { T i, r; ar >> r; ar >> i; z = std::complex<T> (r, i); } namespace boost { namespace serialization { template<class Archive, class T> inline void serialize (Archive &ar, std::complex<T>& z, const unsigned int file_version) { boost::serialization::split_free (ar, z, file_version); } } } template<class Archive, class U> inline void save (Archive &ar, const vector &v, const unsigned int) { unsigned int count = v.size(); ar << count; typename vector::const_iterator it = v.begin(); while (count-- > 0) { ar << *it++; } } template<class Archive, class U> inline void load (Archive &ar, vector &v, const unsigned int) { unsigned int count; ar >> count; v.resize (count); typename vector::iterator it = v.begin(); while (count-- > 0) { ar >> *it++; } } namespace boost { namespace serialization { template<class Archive, class U> inline void serialize (Archive &ar, vector& v, const unsigned int file_version) { boost::serialization::split_free (ar, v, file_version); } } }

7 23

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

29 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-29T15:06:11Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 69 failures in 7 libraries: foreach (28) graph (3) iostreams (1) parameter (4) python (2) serialization (30) wave (1) |foreach| array_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin pair_byref: vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: vc-6_5 vc-6_5-stlport vc-7_0 stl_byref: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-9_4 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

Re: [boost] [regex] missing header inclusion
by François Dumont 29 Aug '05

29 Aug '05

I don't really agree that the patches for the missing headers are fixes for STLport support. They are rather fixes to make boost less Standard library implementation dependant. There are of course not many available Standard library implementations on the market but it is not a reason to make this kind of shortcut :-) Thanks for applying those, I hope I will have soon a final fix for the bjam STLport toolset as for the moment they are not correctly handling: 1. The fact STLport do not support the wrapper mode anymore 2. The modification in the library naming convention. The last issue will then be the lexical_cast problem if you remember. lexical_cast used to not handle correctly configuration with no wchar_t intrinsic support but with wstring granted by the Standard lib. Have anything change lately ? If no shouldn't this kind of config be officially not supported anymore by boost ? I can do a fix to the stlport.hpp file for that if you need it. Bests

2 2

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

28 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-28T14:52:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 87 failures in 8 libraries: foreach (37) functional/hash (1) graph (7) iostreams (1) parameter (4) python (6) serialization (30) wave (1) |foreach| array_byref: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin array_byval: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin call_once: cw-8_3 cstr_byref: cw-8_3 cstr_byval: cw-8_3 dependent_type: cw-8_3 pair_byref: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 pair_byval: cw-8_3 vc-6_5 vc-6_5-stlport vc-7_0 rvalue_const: cw-8_3 rvalue_nonconst: cw-8_3 stl_byref: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin stl_byval: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3_3-darwin user_defined: cw-8_3 cw-9_4 vc-6_5 vc-6_5-stlport vc-7_0 |functional/hash| point: borland-5_6_4 |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 |iostreams| mapped_file_test: intel-win32-9_0 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.1-linux intel-win32-9_0 msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

[date_time] typo in gregorian.html
by Yuval Ronen 28 Aug '05

28 Aug '05

"proleptic" was misspelled as "propleptic". (I'm practicing for "The shortest Boost bug/doc report" competition ;-) )

2 1

RFE 1274707 (Re: [Boost.Thread]: consider removing catch(...)fromthread_proxy)
by Matt Gruenke 28 Aug '05

28 Aug '05

Coincidentally, I just filed an RFE on this very topic (something I'd been meaning to do for a while, but forgot about until I upgraded to 1.33.0). It was suggested to me that I mention it here. Actually, I'd have posted here, in the first place, but it seems I misunderstood the prerequisites for joining this list (I thought it was for code contributors, only). From the archive, I can see this thread has covered most, if not all, of my points. Still, my RFE is probably more cohesive than any single message, on this topic, I've come across in the archives: http://sourceforge.net/tracker/index.php?func=detail&aid=1274707&group_id=7… BTW, I really don't understand this continual talk of a user-supplied/overridable handler function. It still compromises debugging, and without managing to provide anything the user can't already do in the user-supplied threadfunc. (I'm only mentioning this because it's a proposal not addressed in my RFE.) Thanks for considering my views. Matt Gruenke Software Engineer IntelliVid Corp.

1 0

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