- Boost - lists.boost.org

Boost regression notification (2006-12-02 [RC_1_34_0])
by Douglas Gregor 02 Dec '06

02 Dec '06

Boost Regression test failures Report time: 2006-12-02T13:39:41Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 31 failures in 9 libraries concept_check (8) iostreams (1) math (6) random (1) serialization (7) signals (4) test (2) utility (1) xpressive (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 msvc-6.5 msvc-7.0 qcc-3.3.5_cpp qcc-3.3.5_gpp concept_check_fail_expected: qcc-3.3.5_cpp qcc-3.3.5_gpp |iostreams| finite_state_filter_test: cw-9.4 |math| common_factor_test: borland-5.8.2 cw-9.4 msvc-6.5 msvc-7.0 qcc-3.3.5_cpp qcc-3.3.5_gpp |random| random_test: intel-linux-9.0 |serialization| test_no_rtti_xml_archive_dll: qcc-3.3.5_gpp test_reset_object_address: msvc-7.0 test_reset_object_address_dll: msvc-7.0 test_variant_xml_archive: borland-5.8.2 test_variant_xml_archive_dll: borland-5.8.2 test_variant_xml_warchive: borland-5.8.2 test_variant_xml_warchive_dll: borland-5.8.2 |signals| deletion_test: msvc-6.5 ordering_test: msvc-6.5 signal_n_test: msvc-6.5 trackable_test: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64 |xpressive| test3u: qcc-3.3.5_cpp

1 0

Re: [boost] Preliminary working prototypeofatomic_shared--multithreaded wrapper for shared_ptr.
by Talbot, George 02 Dec '06

02 Dec '06

> Chris Thomasson wrote: > > Sent: Wednesday, November 22, 2006 11:32 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Preliminary working prototypeofatomic_shared-- > multithreaded wrapper for shared_ptr. > > "Talbot, George" <Gtalbot(a)locuspharma.com> wrote in message > news:acfee74296c36aa7458ec7c5580b0b9c4564c67b@locuspharma.com... > > Hi, > > > I've attached to this e-mail a working prototype of a wrapper for > > shared_ptr that uses a spinlock so that the shared_ptr may be updated > > atomically from multiple threads. For example, two threads can both > > attempt to set the value of the same shared_ptr, and the last one will > > win. This wrapper includes a "compare_and_set" method for performing > > lock-free-style "read, copy, attempt swap, repeat" updating to a data > > structure, though, of course because the wrapper uses a spinlock, it > > isn't truly lock free. > > I suggest you take a look at a mostly lock-free implementation: > > http://appcore.home.comcast.net/vzoom/refcount/ > > Your wrapper uses the spinlock when it doesn't have to... A swap and a cas > to shared locations that contain pointers to the refcount > object do not need to be locked... I know. I was just doing a simple prototype first that has the interface that I want. I figure if I get everything working with the simple stupid spinlock, then I can go back and re-work with atomic operations. > Weak reference count modifications do not need to be > locked... That's good to know. > You don't need to use DWCAS either... Don't I need to do that for assignment and compare_and_set for the actual shared_ptr<>, since it's two words? (pointer to object and pointer to refcount.) This is good feedback. Thank you for the help. -- George T. Talbot gtalbot(a)locuspharma.com

2 1

[asio] Error handling. Revisited
by Oleg Abrosimov 02 Dec '06

02 Dec '06

Hello, I've read asio docs and was really impressed by this library's design. Thank you Christopher for this contribution. However, error handling was very annoying through all examples. Consider handle_read_body function from chat_client.cpp: void handle_read_body(const boost::asio::error& error) { if (!error) { std::cout.write(read_msg_.body(), read_msg_.body_length()); std::cout << "\n"; boost::asio::async_read(socket_, boost::asio::buffer(read_msg_.data(), chat_message::header_length), boost::bind(&chat_client::handle_read_header, this, boost::asio::placeholders::error)); } else { do_close(); } } It is a common idiom in current asio lib: void some_handler(const boost::asio::error& error) { if (!error) { // asynchronous operation succeed } else { // asynchronous operation failed } } This reminds me the motivation for the Null Object pattern: The object has a trivial state that should be checked explicitly in every method. It is often better to apply the degenerated case of the State pattern (The Null Object pattern) and eliminate all this annoying checks in object's methods. If we apply this to asio's async* methods, we should provide two handlers: first for success case and second for fail, for example: socket_.async_connect(endpoint, boost::bind(&chat_client::handle_connect, this), // success boost::bind(&chat_client::handle_connect_error, this, // fail boost::asio::placeholders::error, ++endpoint_iterator)); I've reworked the chat_client.cpp example with an assumption that such a two-handlers methods are provided and the result is below. I want to ask people in this list if they like this approach better, or not? class chat_client { public: chat_client(boost::asio::io_service& io_service, tcp::resolver::iterator endpoint_iterator) : io_service_(io_service), socket_(io_service) { do_async_connect(endpoint_iterator); } void write(const chat_message& msg) { io_service_.post(boost::bind(&chat_client::do_write, this, msg)); } void close() { io_service_.post(boost::bind(&chat_client::do_close, this)); } private: void handle_connect() { do_async_read_header(); } void handle_connect_error(const boost::asio::error& /*error*/, tcp::resolver::iterator endpoint_iterator) { if (endpoint_iterator != tcp::resolver::iterator()) { do_close(); do_async_connect(endpoint_iterator); } } // helper function to eliminate code duplication void do_async_connect(tcp::resolver::iterator endpoint_iterator) { tcp::endpoint endpoint = *endpoint_iterator; socket_.async_connect(endpoint, boost::bind(&chat_client::handle_connect, this), boost::bind(&chat_client::handle_connect_error, this, // Note there boost::asio::placeholders::error, ++endpoint_iterator)); } void handle_read_header() { if (read_msg_.decode_header()) { boost::asio::async_read(socket_, boost::asio::buffer(read_msg_.body(), read_msg_.body_length()), boost::bind(&chat_client::handle_read_body, this), boost::bind(&chat_client::do_close, this)); // Note there } else { do_close(); } } void handle_read_body() { std::cout.write(read_msg_.body(), read_msg_.body_length()); std::cout << "\n"; do_async_read_header(); } // helper function to eliminate code duplication void do_async_read_header() { boost::asio::async_read(socket_, boost::asio::buffer(read_msg_.data(), chat_message::header_length), boost::bind(&chat_client::handle_read_header, this), boost::bind(&chat_client::do_close, this)); // Note there } void do_write(chat_message msg) { bool write_in_progress = !write_msgs_.empty(); write_msgs_.push_back(msg); if (!write_in_progress) { do_async_write(); } } void handle_write() { write_msgs_.pop_front(); if (!write_msgs_.empty()) { do_async_write(); } } // helper function to eliminate code duplication void do_async_write() { boost::asio::async_write(socket_, boost::asio::buffer(write_msgs_.front().data(), write_msgs_.front().length()), boost::bind(&chat_client::handle_write, this), boost::bind(&chat_client::do_close, this)); // Note here } void do_close() { socket_.close(); } private: boost::asio::io_service& io_service_; tcp::socket socket_; chat_message read_msg_; chat_message_queue write_msgs_; };

2 1

Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
by Talbot, George 02 Dec '06

02 Dec '06

My mistake. So that seems like a bit of a useless guarantee--basically any structure constructed with shared_ptr can only be read by the same thread that's writing to the structure unless all of the pointer operations are guarded with a mutex or spinlock, right? Ignoring compare-and-swap, have you or anyone else experimented with using a spinlock (as you mentioned previously) to remove the above restriction? What would that do to performance and complexity? Could you use a compare-and-swap type of operation to implement read/write thread safety? -- George T. Talbot <gtalbot(a)locuspharma.com> > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Peter Dimov > Sent: Friday, November 10, 2006 10:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] boost::shared_ptr<>::compare_and_swap()-- > AmIinsaneforwanting this? > > Talbot, George wrote: > > > I'm sorry if I'm being too dense here. I think a section in the > > documentation saying exactly what is guaranteed and what isn't would > > help a lot. > > Here you go: > > http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

4 6

[proposal] Rank List (old name: AVL Array) in the Sandbox Vault
by Martin Knoblauch Revuelta 02 Dec '06

02 Dec '06

- Hi again, I have uploaded Rank List (presented here as "AVL Array" in the message "[proposal] Sequence container with O(log n) random access _and_ O(log n) insertion/removal (wherever)") to the Sandbox Vault. I've made a lot of changes, but the main one is the documentation: http://boost.cvs.sourceforge.net/*checkout*/boost-sandbox/boost-sandbox/lib… You will notice that I've kept all the features of the first proposal. I still believe that they are useful and they sould be maintained (the rationale explains why). As I said, I will remove them if this is the general desire in Boost. Please, could you first take a look to the docs (overview, rationale and/or FAQ) and then answer the next questions? A) Would you add Rank List to Boost? B) Do you suggest removing anything? I'd like to discuss the problem of tagging iterators as random access or just bidirectional. Thanks in advance, Martin

2 2

Re: [boost] FW: Suggestion for boost`s smart pointers
by Sohail Somani 02 Dec '06

02 Dec '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant > Sent: Friday, December 01, 2006 5:02 PM > > I wouldn't really need the extra indirection that seems to > be implied > > there but that's a step in the right direction. > > <nod> Agreed. The indirection is in there really only because you > said "C". The deleter type can easily be a C++ class type which can > then do anything you want. Ah http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#Addit ion%20-%20Class%20template%20unqiue_ptr Thanks :)

1 0

Re: [boost] FW: Suggestion for boost`s smart pointers
by Sohail Somani 02 Dec '06

02 Dec '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant > Sent: Friday, December 01, 2006 4:34 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Suggestion for boost`s smart pointers > > On Dec 1, 2006, at 5:00 PM, Sohail Somani wrote: > > > Most C libraries have make_X/free_X pairs. So a typical C call could > > look like: > > > > ... > > struct T * c = make_T(args); > > do_stuff_with_a_T(c); > > free_T(c); > > ... > > > > Which I would like to replace with: > > > > ... > > typedef some_ptr<T,Deleter<free_T> > T_ptr; > > T_ptr c(make_T(args)); > > do_stuff_with_a_T(c.get()); > > ... > > Does this work for you? > > typedef unique_ptr<T, void (*)(void*)> T_ptr; > int args; > T_ptr c(make_T(args), std::free); // assumes make_T uses > std::malloc > do_stuff_with_a_T(c.get()); > > http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html I wouldn't really need the extra indirection that seems to be implied there but that's a step in the right direction.

2 1

Re: [boost] FW: Suggestion for boost`s smart pointers
by Sohail Somani 02 Dec '06

02 Dec '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger > >>I was referring to the file pointer, which is pretty much the > >>only "C resource" I use. > >>You're right when it comes to malloc/free, of course - but do > >>we really need it? > > > > Anytime you deal with C atleast, the answer is yes. > > > > I doubt it's good practice for a C library to allocate stuff > and hand it > to the user who has to then free it or to free stuff that > comes from the > user... > > The other cases are: > a) it's up to the user to obtain the memory, so new/delete will work > b) the library provides ctor/dtor routines, so custom > deleters are needed Most C libraries have make_X/free_X pairs. So a typical C call could look like: ... struct T * c = make_T(args); do_stuff_with_a_T(c); free_T(c); ... Which I would like to replace with: ... typedef some_ptr<T,Deleter<free_T> > T_ptr; T_ptr c(make_T(args)); do_stuff_with_a_T(c.get()); ...

2 1

Yet another bignum type
by Daryle Walker 01 Dec '06

01 Dec '06

This is something I've been working on for the past few months. It's in the Sandbox and I just uploaded it to the new Vault as "big_radix_whole.tar.bz2" under the "Math - Numerics" directory, i.e. <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam e=big_radix_whole.tar.bz2&directory=Math%20-%20Numerics&>. The files might choke on some systems, since I used naked min & max and the test file has #pragma marks all over it. (My IDE function-lists all the test modules as "BOOST_AUTO_TEST_CASE()", without anything in the parentheses, so I needed the marks to navigate the huge file.) I'm using Xcode 2.4, with Apple's special GCC, on a Mac OS X 10.4.8 PowerPC system. The only documentation right now is the Doxygen comments. It's a run-of-the-mill bignum type. It uses the philosophy of the STL containers to use a separate template parameter for the memory allocations. The type is radix-specific, also given as a template parameter. It's of the simplest bignum type, an arbitrary-length unsigned integer class. (Signed integers, fixed-point, floating-point, rational, etc., variants can all be built off of this kind of bignum.) As such, the renditions of the traditional algorithms are fairly pure. The biggest issue from a mathematical standpoint is that the type can't be a proper ring, since it doesn't support additive inverses (besides zero). Every other arithmetic operation (that doesn't need negative values) can work. The work-around for subtraction is the addition of "subtract-absolutely" member functions, which compute the absolute value of the difference, and return a "bool" indicating what the sign would have been. Many of the operations are repeated, each with optimized algorithms for the different sizes of the parameters. Since the traditional method of multiplication is actually a fused-add/multiply, member functions for such fused actions were added. There are many variants for shifting-up where additions/subtractions start since it's faster than doing a separate shifting operation first. And it saves memory, which was an important goal in all the algorithms, along with the strong exception guarantee. Besides the asserts, there is generally no protection for pre-condition violations (except for exceptions for negative results, divides by zero, and conversions). There are commented-out plans for functions that do powers and (truncated) roots, especially squaring and square-roots, and pseudo-reciprocals (for an N-digit value, find another M-digit value, with M <= N, closest to giving a product of Radix**2N, useful to implement exact-division by multiply-by-reciprocal, which is cheaper for huge N). What other routines should be added? Any hints on how to do said routines? Should there be Serialization? Could Spirit and/or Regex be used for the I/O routines? Any compiler workarounds to be added? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

15 38

Re: [boost] FW: Suggestion for boost`s smart pointers
by Sohail Somani 01 Dec '06

01 Dec '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Tobias Schwinger > Sent: Friday, December 01, 2006 12:17 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] FW: Suggestion for boost`s smart pointers > > Sohail Somani wrote: > > Thanks for your reply but the domain of COM objects lends > itself well to shared_ptr. > > As to scoped_ptr. I don't quite understand the "but" in that sentence. Agreed. But something that applies to scoped_ptr + deleter doesn't always apply to shared_ptr. > > I went through the archives after the posts and I have > realized that > > scoped_ptr is not changing! I will still disagree that the > deleter shouldn't > > be a parameterized type. > > What's wrong with: > > template<typename T> void free_resource(T* ptr) > { delete ptr; } > void free_resource(std::FILE* f) > { std::fclose(f); } > void free_resource(IDispatch * o) > { o->Release(); } > > template<typename T> > struct scoped_ptr > { > // [...] > ~scoped_ptr() { free_resource(this->p_); } > // [...] > }; > I don't particularly like requiring implicit function declarations. I'd rather tie them to the resource pointer type somehow. That's just my own preference which may or may not be totally wrong (but its not). I think its too easy for people to forget to do it. I prefer parameterized type + typedef. > > The only other option is using a type erasure mechanism > like shared_ptr which > > is more trouble than its worth for things like deallocating > C resources. > > I was referring to the file pointer, which is pretty much the > only "C resource" I use. > You're right when it comes to malloc/free, of course - but do > we really need it? Anytime you deal with C atleast, the answer is yes. Sohail

2 1