- Boost - lists.boost.org

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

CW x86 is dead
by Miro Jurisic 18 Apr '05

18 Apr '05

I don't think this has any immediate effect on boost, but MW recently sold off their x86 compiler. See <http://www.metrowerks.com/Discontinued/default.htm>. meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

1 0

Typeof library -- review version available
by Arkadiy Vertleyb 17 Apr '05

17 Apr '05

Please take it at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

3 3

[iostreams] non-blocking i/o : revenge of char_traits
by Jonathan Turkanis 17 Apr '05

17 Apr '05

Hi All, I announced casually in the iostreams docs that the first release would include hooks for non-blocking and async i/o, so users wouldn't have to rewrite their filters when these models were fully supported. Then I spent months worrying about the best way to implement it, and finally solicited advice here few weeks ago. The main idea was to have get() return a class type (basic_character) capable of holding either a character or one of two special values representing EOF and EAGAIN. After receiving some good suggestions, I implemented basic_character last week, and unfortunately found some serious usability problems, especially relating to the conditional operator. As I considered various possible changes to basic_character, I made (as they say on Court TV) a gruesome discovery: basic_character was starting to look more and more like char_traits. Since it's pointless to replace one horrible bloated class with a completely different one, I'm considering defining a template boost::iostreams::char_traits which extends std::char_traits and adds a would_block() function. The return type of get() would remain char_traits<>::int_type. Users writing templated code would test the return type against char_traits<>::eof() and char_traits<>::would_block() using char_traits<>::eq_int_type; users writing narrow- or wide-character components could use the convenience constants boost::iostreams::WOULD_BLOCK and boost::iostreams::WWOULD_BLOCK, in addition to EOF and WEOF. The main technical problem is I'd have to pick values for WOULD_BLOCK and WWOULD_BLOCK separately for each supported standard library. What do people think? Jonathan

1 1

Network library: What we have until now
by Boris 17 Apr '05

17 Apr '05

I updated http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet to document why what decisions were made. We have until now: * The network library should support four I/O models which are known to many programmers as blocking, non-blocking, multiplexing and asynchronous. * It should be possible to switch between I/O models at runtime (which means you have one socket class supporting all I/O models instead of different socket classes each of them supporting only one I/O model). * There should be an asynchronous I/O library as other libraries might want to do asynchronous I/O, too. * There should be an asynchronous design pattern which should be used by all Boost libraries which support asynchronous operations. * On a low level the network library should be close to what is known as Berkeley sockets to many programmers. * On a high level there should be I/O streams support. As far as I can see from all the discussions that's what we agree on. There have been some ideas like event handlers and dispatchers but I am not sure where to put them - have a look at http://www.highscore.de/boost/net/packages.png please (which is also in the Wiki page). This is the overall architecture of the network library. If you want me to change or add something please tell me. Boris

6 13

Re: [network] An RFC posted to the sandbox
by Don G 16 Apr '05

16 Apr '05

Hi Bob, >Caleb Epstein writes: >> As far as the appropriate subseconds type goes, we >> should probably pick the highest-possible resolution >> that makes sense, which I'd contend is probably >> microseconds. Some operating systems may be able to >> slice time (and signal events) at resolutions below >> milliseconds, but I doubt any can go deeper than >> microseconds. > > I wouldn't take that bet. I know Mac OS X can measure > time as finely as nanoseconds (but I have no idea how > many services, i.e. sockets, actually work at > nanosecond resolutions; it doesn't seem outside the > realm of possibility that, given the way technologies > advance, that within a few short years, microseconds > simply won't be fine enough. One of the nice things > about double-as-time-unit is that it avoids resolution > issues altogether. With processor speed basically stalled out around 4GHz, it is at theoretically possible to measure time to about 0.25ns. Not that a scheduler would muck about at that level. For timeout purposes (especially for networking), I think microsec is fine. In particular, this is what select() wants. epoll_wait uses milliseconds. Windows generally uses milliseconds. The kqueue/kevent folks do want nanoseconds. The precision of the implementation is not clear (just it's interface). Having said that, I like Caleb's proposal to offer multiple ctors for timeout purposes as long as they don't get ambiguous. That way, floating point can be used as well as pure integer (if that kind of thing still matters to anyone<g>). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

6 7

boost::lazy_operators ???
by Sascha Seewald 16 Apr '05

16 Apr '05

i wonder if it would be possible to support lazy evaluation in boost::operators. we could provide "lazy" operator class templates and combine them with the "normal" operator class templates. example: class point : boost::addable< point<T> // point + point (normal) , boost::subtractable< point<T> // point - point (normal) , boost::lazy_dividable2< point<T>, T // point / T (lazy) , boost::lazy_multipliable2< point<T>, T // point * T, T * point (lazy) > > > > { ... } what do you think? sascha -- +++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++ GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/dsl

2 1

type_traits on steroids
by Preston A. Elder 16 Apr '05

16 Apr '05

Hi, I am wondering how to create a 'type trait' such as 'is_ostreamable', ie: class A {}; class B {}; std::ostream &operator<<(std::ostream &os, const A &in) { return (os << in); } // Note, no operator<< for class B // --- somewhere else .. ;) class X { std::ostream out; template<typename T> void Impl(const T &in, boost::mpl::bool_<true>) { out << "(" << typeid(in) << ") " << in; } template<typename T> void Impl(const T &in, boost::mpl::bool_<false) { out << "(" << typeid(in) << ") 0x" << std::hex << (unsigned int) &in; } public: X(std::ostream &os) : out(os) {} template<typename T> void DoIt(const T &in) { Impl(in, boost::mpl::bool_<boost::is_ostreamable<T> >()); } }; So the above would print the type name, and then the value of the entry IF the entry could be streamed to a std::ostream. Otherwise, it would print the type name and the address of its memory location (in hex). Obviously the above is just an example, but one that illustrates my need :) Question is, how to do it? Its easy enough to get a compiler error when something is not supported, but how to get the compiler to choose behavior on whether something is supported. -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

2 4