- Boost - lists.boost.org

[hash] Expected behaviour of hashing quiet NaN?
by Markus Schöpflin 19 Apr '05

19 Apr '05

Currently "functional/hash - hash_float_test" fails on Tru64/CXX6.5 (See http://tinyurl.com/8opfo) The reason of the failure is that QNaN and 0 give the same hash code on this platform. I was wondering what the expected hash of QNAN actually should be. Is it some platform dependent value? I put some traces in hash_detail::float_hash_value(), and the cause for the same hash value for 0 and QNAN seems to be that static_cast<int>(QNAN) gives 0 which then results in a call of hash_combine(0, 0) for both 0 and QNAN. Does anybody know what the expected result of static_cast<int>(QNAN) is? My guess is that either I should get a floating point exception for this expression or that the return value is unspecified and errno is set to [EDOM], but this is pure speculation on my side. Markus

3 7

Proposal: intrusive containers
by Olaf Krzikalla 19 Apr '05

19 Apr '05

Hi, I have finished the first version of my STL-like intrusive containers and I want to propose the idea for boost. For detailed informations please visit: http://people.freenet.de/turtle++/intrusive.html Best regards Olaf Krzikalla

2 2

patch for numeric_cast
by Toon Knapen 19 Apr '05

19 Apr '05

Currently following situation does not generate a bad_numeric_cast. <test> unsigned int ui = std::numeric_limits< unsigned int >::max() ; int i = boost::numeric_cast< int >( ui ) ; </test> Nevertheless 'i' is -1 instead of some very big number. To catch this kind of error, I propose to apply following patch to boost/cast.hpp (in attachment). The current implementation casts the value for to the target-type and back to the original type and verifies that it is still the same value. For the example above, the intermediate result will be -1 although casting it back to the original type will result in the original value. So the patch verifies that this intermediate result will not be negative. If the patch is accepted I will also add a test in the current regression-test of numeric_cast. toon -- Check out our training program on acoustics and register on-line at http://www.fft.be/?id=35

1 0

async socket i/o [long]
by Michel André 18 Apr '05

18 Apr '05

There has been some discussion on this on the list lately. Is there anyone working on it. I have been pondering an interface that supports both async and blocking io combined. And an event dispatching model that can handle several types of dispatching mechanism through a the same interface to provide for a lot of differnet implementations. At heart of this is an io_stream base class that should serve as base for classes like tcp_stream and udp_stream. class io_stream : public event::event_handler { public: // blocking read virtual io_result read( void* buffer, size_t byteCount) = 0; // blocking write virtual io_result write( const void* buffer, size_t byteCount) = 0; // asynchrounous read. virtual io_result async_read( void* buffer, size_t byteCount, boost::function<void(const io_result&)>) = 0; // asynchrounous write. virtual io_result async_write( const void* buffer, size_t byteCount, boost::function<void(const io_result&)>) = 0; virtual void close() = 0; protected: }; the event_handler interface is at heart of event handling and dispatching. class event_handler { ublic: virtual ~event_handler(); // returns a pointer to the dispatcher the source // is attached to or NULL if the source isn't attached. event_dispatcher* dispatcher(); protected: enum event_type_t { read_event, // A read can be done without blocking read_done_event, // An async read is completely done write_event, // A write can be done without blocking write_done_event, // An async write is completely done connect_event, accept_event }; typedef std::bitset<6> event_set_t; // returns the current set of events we want to receive event_set_t event_filter() const; // updates the current event set by oring // current filter and the set provided void update_event_filter(event_set_t set); // an opaque handle to the underlying source virtual void* handle() = 0; /// callack when event occurs. /// event - type of event dispatched /// bytes - number of bytes affected by the event /// size_t(-1) if unknown. /// error - an event specific error code 0 if no error /// eventData - a void* pointer that contains opaque /// data supplied when initiating the operation NULL of none /// is supplied or not available void dispatch_event( event_type_t event, size_t bytes, unsigned int error, void* eventData) = 0; private: event_handler(const event_handler&); event_handler& operator=(const event_handler&); }; From this we could be notified both of full async completes or just ready to write and ready to receive. And when a concrete io_stream implementation receives notification it can check on the flags if the read have completed or of we must do a read or write to fullfill the pending operation that must be stored within the implementation. This makes for implementations of the event dispatcher (including simple select, kqueue, iocp or some other mechanism both edge and level triggered). The event dispatcher interface looks like: class event_dispatcher { public: /// attaches an event handler to an dispatcher /// all dispatchable events for the event handlers /// handle will go through this dispatcher. an event handler /// and its associated handle is attached /// to a specific dispatcher throughout its life time virtual void attach(event_handler& source); /// Removes an event handler from set. notifications /// wont be sent to this dispatcher to the event handler /// after this point. virtual void detach(event_handler& source); /// notify the event_dispatcher that the event filter /// has changed for the given source virtual void notify(event_handler& source); /// dispatch pending events blocks timeoutSecs waiting /// for event. returns true if an event was dispatched /// during the call. virtual bool dispatch_event(unsigned int timeoutMsecs); /// adds a callback to be called asynchrounously the next /// as soon as possible. virtual void asynch_dispatch(boost::function<void> callback); }; This can be implemented in various ways through simple select for single threaded version, and leader follower select for multithreaded with several threads hanging in dispatch_events and handling and event and promoting a new leader to catch next set. And it could be implemented using io completion ports or kqueue for scalable variants. To top this of we have connector and acceptor base classes class connector : public event::event_handler { public: std::auto_ptr<net::io_stream> connect_stream() = 0; void async_connect_stream( boost::function<void(const io_result&, std::auto_ptr<net::io_stream>)> callback) = 0; }; class acceptor : public event::event_handler { public: std::auto_ptr<net::io_stream> accept_stream() = 0; void async_accept_stream( boost::function< void(const io_result&, std::auto_ptr<net::io_stream>)> callback) = 0; }; And tcp_acceptor and tcp_connector to implement these for tcp. Eg the tcp acceptor: class tcp_acceptor : public acceptor { public: acceptor(const ip_endpoint& localEndPoint); acceptor(event::event_dispatcher& dispatcher, const ip_endpoint& localEndPoint); std::auto_ptr<net::tcp_stream> accept() = 0; void async_accept( boost::function<void(const io_result&, std::auto_ptr<net::tcp_stream>)> callback) = 0; /// Acceptor functions std::auto_ptr<net::io_stream> connect_stream() = 0; void async_connect_stream( boost::function<void(const io_result&, std::auto_ptr<net::io_stream>)> callback) = 0; }; I think these interfaces would allow for a range of implementations under the same umbrella. The os dependent sockets part should be handled by a socket facade class. The io_result class is a helper class that handles reporting of the actual result and eventual error outcome of an operation. It combines error codes and exception throwing. // encapulates a result of an net operation // throws an io_error if none of the following // members haven't been called before destruction: // failed,success,error_code,throw_exception. struct io_result { enum error_code_t { e_success, e_cancelled, // operation was cancelled e_pending_io // an net operation of the specified type is already pending }; error_code_t error_code() const; bool failed() const; bool success() const; void throw_exception() const; // bytes transferred by the last operation size_t byte_count() const; }; So this is the outline of an interface that I think could serve as a foundation for a net library. I will try to go about and implement prototype for this using both select and iocp. But there are some things to iron out such as thread saftey and such (since it will necessary to at least having several threads blocking in dispatch_event at least the event_dispatcher would have to be thread safe and probably parts of the event source d). What are your initial thaugths on this, implementatble? flexible enough? efficient enough? What are you others doing in this field? And maybe we should do something together instead if we are sitting in different cornes hacking on something similar. I know for one i need help with boost.build, how to produce documentation according to boost standard, multi platform testing and the like ;). Regards /Michel

4 18

Re: [boost] Re: Boost to the rescue
by brangdon＠cix.compulink.co.uk 18 Apr '05

18 Apr '05

In-Reply-To: <6.2.0.14.2.20050417091210.0840a328(a)mail.rudbek.com> vawjr(a)rudbek.com (Victor A. Wagner Jr.) wrote (abridged): > > The shear size of boost bothers me in that I don't want to burden > > my source code control system unnecessarily. > > 21 meg isn't that much (for the headers) Actually it's quite a lot. This is a "new tool" issue - once any new tool is incorporated into the code, we have to keep it around for ever, even if it proves useless and we stop using it 6 months later. It's a barrier to entry, and it would be a lower barrier if boost took 1 meg or 10k. Basically I am supporting the idea of splitting boost into a collection of small, independent packages. I don't know how big the subset I selected was, but it was probably nearer 10k. From memory it was operator.hpp, smart_ptr.hpp and static_assert.hpp, plus whatever they depend on (which I discovered by repeatedly attempting to compile). I didn't want to include anything I couldn't see an immediate use for. Instead I encouraged my colleagues to view the website and add anything they wanted from it. Nobody has yet done so, which I suppose weakens the claim that a small subset will lead to a bigger one. > > The dependency issue bothers me too. > > You'd seriously rather that people copy/paste code to reduce > dependencies? There's a trade-off. It depends on the size and complexity of the library code. For example, I once experimented with using operators.hpp to generate != from ==. The benefit seemed borderline. There is a hump involved in using 3rd party code, and for a one-line routine: inline bool operator!=( const MyType &a, const MyType &b ) { return !(a == b); } it hardly seems worth it. Operators.hpp has over 900 lines of code, full of #ifdef's for various compilers, templates and inheritance. To understand it you need to know about subtle language issues: for example how the inline "friend" generate non-member functions, or the nuances of the empty base class optimisation. The documentation is long and complicated. None of this can be understood at a glance, where-as the hand-written version above can. > > I've had code break because a boost header somewhere redefined min > > and max. > > where? when? A few weeks ago. Probably using boost 1.31 - I'm not at work to check. I don't recall which header I #included. Probably shared_ptr.hpp. > the real problem is that MicroSloth [...] #define min and max as > a result of using windows.h !!!! I know. The point remains. Experienced programmers know that using any 3rd partly library can introduce problems. Boost is no exception. -- Dave Harris, Nottingham, UK.

5 5

[test] unused test file?
by Vladimir Prus 18 Apr '05

18 Apr '05

It looks like libs/test/test/unit_test_suite_ex_test.cpp is not used by any test. It was previously used by the unit_test_suite_ex_test test, but that test was remove in revision 1.26 of libs/test/test/Jamfile. Should the above file be remove too? - Volodya

2 1

RE: [boost] How to merge set<int>
by Eyal Farago 18 Apr '05

18 Apr '05

if you want to use the std::merge algorithm: set<int> c; std::merge(a.begin(), a.end(), b.begin(),b.end(),std::inserter(c, c.end()); but there is a simpler way to do it: set<int> c(a); //copy c'tor c.insert(b.begin(),b.end()); eyal. -----Original Message----- From: zlf [mailto:zlfcn@hotmail.com] Sent: Monday, April 18, 2005 6:52 AM To: boost(a)lists.boost.org Subject: [boost] How to merge set<int> Hi, I have to sets(set<int> a,b). How to use function [merge] to merge the two sets to another one(set<int> c)? thx zlf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Proposal: Design by Contract / Pre & Postconditions library
by Yariv Tal 18 Apr '05

18 Apr '05

Is there a need for a Design by Contract (a.k.a Pre & Post conditions) library? I've written a library that allows for pre & post conditions and adds an additional "exceptional" condition type. Each condition is tested at a different point in the methods invocation, and an assert occurs if the condition does not hold. Unlike many other such libraries it allows for defining all condition types at the begining of the method, instead of making you define the "post" checks just before method exit (which usually constrains you to a single-point-of-method-exit design). See EXAMPLES below. Here's a quick summary of condition types: - Pre conditions - tested immidiately - Post conditions - tested on exiting the method normally (not due to an exception). You can use both "pre"(=old) values and "post" (=current) values in the test expression (i.e. "pre(size) < post(size)"). If the method returns a value then you can also, with some work on your part, test against it (i.e. "retval > 0"). - Exceptional conditions - tested on exiting the method due to an exception. You can use both "pre" and "post" values in the test expression. - Delayed Assert - this is just a small add-on that allows you to seperate between an assert's definition time and testing time. It's useful when an assert needs to compare some new value to an "old" value (usually solved by saving the old value in a temp variable, which I find messy). Again, see EXAMPLES below. I've been using it with the current project at my work place and found it to be very useful. The implementation uses scope guards to execute user defined predicate functors at the correct points in the method's life cycle. The predicate functors can be explicitly defined or defined on the fly (boost.lambda is my favourite tool for this). When a scope guard is destroyed I check to see if an exception occured (I found 2 ways to do this, see below) and according to the condition type the predicate is executed, causing an assertion failure if it returns false. The pre/post conditions can be written in either an Eifel like way (require/ensure within a conditions-body-endbody block) or simply via pre/post condition macros (require that you compiler support the uncaught_exception function). Any comments and questions are, of course, welcome. Yariv Tal. P.S. Here are the EXAMPLES: ==[Eifel like require & ensure]========================================= // Defining a contract for a stack's class "push" method // using Eifle style (within conditions-body-endbody block) void Stack::push(const T &a_item) { CONDITIONS // Conditions that must hold when entering the method REQUIRE(m_buf != NULL); REQUIRE(m_used <= m_size); REQUIRE(m_size > 0); // Conditions that must hold when exiting the method // Note that I do not assume a single exit point ENSURE(post(m_used) <= post(m_size)); ENSURE(post(m_size) >= m_size); ENSURE(post(m_used) > m_used); // Conditions that must hold if an exception occurs EXCEPTIONAL(post(m_used) == m_used); EXCEPTIONAL(post(m_buf) == m_buf); EXCEPTIONAL(post(m_size) == m_size); BODY if(m_used == m_size) // grow if necessary { unsigned int newSize = (m_size+1)*2; // grow factor T* newBuf = NewCopy( m_buf, m_size, newSize); delete[] m_buf; // again, this can't throw m_buf = newBuf; m_size = newSize; } m_buf[m_used] = a_item; // if this copy throws, the increment ++m_used; // isn't done and the state is unchanged ENDBODY } ------------------------------------------------------------------------ ==[Pre/Post style]====================================================== // Defining a contract for a stack's class "push" method // using pre/post style (requires that compiler support // the uncaught_exception function) void Stack::push(const T &a_item) { // Conditions that must hold when entering the method PRECOND(m_buf != NULL); PRECOND(m_used <= m_size); PRECOND(m_size > 0); // Conditions that must hold when exiting the method // Note that I do not assume a single exit point POSTCOND(post(m_used) <= post(m_size)); POSTCOND(post(m_size) >= m_size); POSTCOND(post(m_used) > m_used); // Conditions that must hold if an exception occurs EXCEPTCOND(post(m_used) == m_used); EXCEPTCOND(post(m_buf) == m_buf); EXCEPTCOND(post(m_size) == m_size); if(m_used == m_size) // grow if necessary { unsigned int newSize = (m_size+1)*2; // grow factor T* newBuf = NewCopy( m_buf, m_size, newSize); delete[] m_buf; // again, this can't throw m_buf = newBuf; m_size = newSize; } m_buf[m_used] = a_item; // if this copy throws, the increment ++m_used; // isn't done and the state is unchanged } ------------------------------------------------------------------------ ==[Using a Delayed Assert]============================================== void Stack::push(const T &a_item) { // ... conditions are defined here, as in previous examples if(m_used == m_size) // grow if necessary { // =[Define a Delayed Assert]==== // Use the "assertdef" macro to define a delayed assert. // This assert will be evaluated at a later time, when we use the // "assertnow" macro, and will check that the buffer, m_buf, // has changed. Note that we must give the assertion a name. assertdef(GrowChangesBufferToNewBuffer, post(m_buf) != m_buf); unsigned int newSize = (m_size+1)*2; // grow factor T* newBuf = NewCopy( m_buf, m_size, newSize); delete[] m_buf; // again, this can't throw m_buf = newBuf; m_size = newSize; // =[Test the Delayed Assert]==== // Assert the previously defined "delayed assert". assertnow(GrowChangesBufferToNewBuffer); } m_buf[m_used] = a_item; // if this copy throws, the increment ++m_used; // isn't done and the state is unchanged } ------------------------------------------------------------------------

4 6

Re: [boost] Re: Boost to the rescue
by brangdon＠cix.compulink.co.uk 18 Apr '05

18 Apr '05

In-Reply-To: <000a01c542df$a4807770$0500000a@Hagrid> bjorn(a)4roald.org (=?iso-8859-1?Q?Bj=F8rn_Roald?=) wrote (abridged): > So what are the real obstacles: > 1. Managers acceptance of introducing a new tool > 2. Convincing other developers on your team > 3. Lack of consistant documentation > 4. Lack of consistant support of all platforms (to me Sun CC support > has been a problem) > 5. Lack of a good measure of the stability of the API of various boost > libraries > > I feel like no. 5 is a real concern the boost team could do something > about with little effort. You do not feel secure that the next > version of boost will support your code, thus you feel like it may > be risky to stick your neck out. Really? As a new user I kinda took stability for granted, at least as much as for any other 3rd party library. Are you sure this isn't only an issue for people who are already using some parts of Boost? I'd say the first problem is shear ignorance that the library exists at all, followed by ignorance of the first 3 paragraphs of the website's current front page. Boost is special. The second problem is of finding useful stuff in Boost. A lot of it is quite esoteric. The bits which aren't esoteric many programmers will already have invented for themselves. For example, shared_ptr can be in both categories. Many programmers don't see the need for smart pointers at all, and those who do probably have written their own. The third problem is a perception that the library is more academic than useful. The emphasis is on strict standard conformance, portability to compilers I don't care about, and language corner cases I don't care about (eg multiple virtual inheritance). This is often reflected in library code which is hard to read and understand, and often based on esoteric implementation techniques. The fourth problem is that as with any 3rd party library, boost will often not be exactly what one wants. If you write it yourself you can customise it. The shear size of boost bothers me in that I don't want to burden my source code control system unnecessarily. The dependency issue bothers me too. I've had code break because a boost header somewhere redefined min and max. Linking issues may be a problem; I don't know. I have extracted a small subset of boost that was header-only. I never touched bjam. -- Dave Harris, Nottingham, UK.

5 5

How to merge set<int>
by zlf 18 Apr '05

18 Apr '05

Hi, I have to sets(set<int> a,b). How to use function [merge] to merge the two sets to another one(set<int> c)? thx zlf

1 0