- Boost - lists.boost.org

[serialization] error in docs
by JOAQUIN LOPEZ MU?Z 19 Apr '05

19 Apr '05

On the paragraph on object tracking, the reset_object_address facility is introduced with two snippets, both of them featuring a *save* member function. I think this is incorrect, it should be a *load* member function. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Typeof is next for review -- review manager needed
by Arkadiy Vertleyb 19 Apr '05

19 Apr '05

Hi everybody, I was recently contacted by Tom Brinkman (the review wizard) and told that, since the authors of other libraries in the queue are not yet ready to start, the Typeof libraty is being moved to be the next one for the review. Peder and I will be ready starting next Monday. We are making some final touches, and I will upload the review version very soon. The most recent version is now available in the Boost sandbox file vault, http://boost-sandbox.sourceforge.net/vault/, typeof.zip. In this regard, I would like to ask if somebody would like to give us an honor of being our review manager. Here is the short description of the library: ---- The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. The emulation works by bringing the expression into the context where its type is known, using partial template specializations to encode a type as a compile-time sequence of integer numbers, moving integers one-by-one into the original context through the sizeof(), and then reconstructing and decoding the sequence into the original type. This method requires the user to register types and templates, and compiles slower than the other two, but has a benefit of being standard-compliant and rather portable. It can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. ---- Regards, Arkadiy

2 3

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

2 1

[regex] patch for Tru64
by Markus Schöpflin 19 Apr '05

19 Apr '05

Hello, attached patch has just been applied to "regex/v4/sub_match.hpp". This clears the compilation errors currently seen on Tru64 when compiling the regex_time example. Markus Index: sub_match.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/regex/v4/sub_match.hpp,v retrieving revision 1.14 diff -u -r1.14 sub_match.hpp --- sub_match.hpp 21 Jan 2005 17:22:39 -0000 1.14 +++ sub_match.hpp 19 Apr 2005 15:01:30 -0000 @@ -44,7 +44,8 @@ sub_match(BidiIterator i) : std::pair<BidiIterator, BidiIterator>(i, i), matched(false) {} #if !defined(BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS)\ && !BOOST_WORKAROUND(BOOST_MSVC, < 1310)\ - && !BOOST_WORKAROUND(__BORLANDC__, <= 0x0551) + && !BOOST_WORKAROUND(__BORLANDC__, <= 0x0551)\ + && !BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590042)) template <class T, class A> operator std::basic_string<value_type, T, A> ()const {

2 1

RE: [boost] Re: Boost to the rescue
by Martin Bonner 19 Apr '05

19 Apr '05

----Original Message---- From: Victor A. Wagner Jr. [mailto:vawjr@rudbek.com] Sent: 19 April 2005 16:03 To: boost(a)lists.boost.org Subject: Re: [boost] Re: Boost to the rescue > I've been using 7.1 since it became available, and haven't > bumped into any optimization problems, and we compile debug with > none, and about everything we can find to turn on in release. > Granted there are only 4 of us, but I don't recall any gotchas. I have. We compile "minimize size", and when bitshifting it gets things wrong. We have found this twice (the first time confirmed by Microsoft), and have had to revert to releasing the existing product with VC5 (Yes: 5 not 6. We never upgraded to VC6 because it was expensive, a resource hog, didn't seem to offer many new features, and a change to how #import work broke huge swathes of our code). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

review process
by Gennadiy Rozental 19 Apr '05

19 Apr '05

Hi, I think current approach to review managing is .. not good enough. I understand Tom do not want us delve in all gory details of what is currently going on, but absence on any information is even worse. I believe all behind the scene discussions needs to be brought to minimum. No need to wait for anything. "Show must go on". My personal interest as a review manager for one of the upcoming submissions is to have clear understanding when I need to allocate extra time. And as soon as possible either. This uncertainty is inconvenient at best. Gennadiy

1 0

[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