- Boost - lists.boost.org

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

Coding Guidelines for Integral Constant Expressions
by Johan Johansson 16 Apr '05

16 Apr '05

There may be an error in them. From http://www.boost.org/more/int_const_guidelines.htm: --- An integral constant expression can be one of the following: ... 2. An enumerator value. ... 9. The result of applying a binary operator to two integral constant expressions: INTEGRAL_CONSTANT1 op INTEGRAL_CONSTANT2 provided that the operator is not an assignment operator, or comma operator. --- Neither gcc (3.3.3) nor Metrowerks (don't remember version) seems to think that "enumVal1 | enumVal2" is an integral constant expression. This seems obvious in the case of operator| being overloaded, although Comeau online 4.3.3 *does* seem to swallow that without complaint, which greatly diminishes my expectations of being right and greatly adds to my confusion. However, gcc and Metrowerks seem to ban this even if operator| is not overloaded. I haven't found the standardese to motivate that yet. Someone set me straight, please! Thanks, Johan

2 1

Re: Network library: What we have until now
by Don G 16 Apr '05

16 Apr '05

Hi Iain, >> I knew we had a definition problem: handling >> 1000+ simultaneous connections would not be >> something I would label as "simple"! ;) > > With all due respect I think that you are > confusing size/scalability with complexity. I was just being complimentary, not confused. That was the day before... :) > Rather than 'guess' what a boost::function costs > why not look it up here > http://www.boost.org/doc/html/function/misc.html#id538868 Time and priority. I didn't think it would be an issue and thanks to the link you provided, I am more confident of this. >>> I hope this won't happen. There are several I/O >>> patterns in use out there. >> >> But, honestly, how many do we need? > > *All* of the ones provided by the 'C' socket API > i.e. single threaded reactive ( blocking), Single > threaded reactive ( non-blocking ), signal driven, > multi-threaded async, and multi-threaded reactive. But why stop there? How about posting to HWND's, kernel event object or IOCP as Winsock does? Hyperbole aside, the proposal I posted has no signals explicitly (though, with some thought perhaps they could be used internally) and does some hand waving about single-threaded reactive using function queues instead of manual bookkeeping. The others are supported. (though I may not be following your distinction between MT async vs. MT reactive). > And before you say again that signals are not > portable, they have been part of the libc library > on DOS and windows from MSDOS 3.0 on Lattice C, > Borland Turbo C 2.0 and MS C compilers and it is > still supported under Windows XP. Oh, those where they days :) But, I think you ended your search a bit early. Look for any of these in MSDN (SIGIO, SIGPOLL, O_ASYNC, F_SETSIG, fcntl, sigaction, siginfo) and you will only find them in the Unix Code Migration Guide and no hits for sigwait or sigwaitinfo. Oops, "fcntl.h" is a C RTL header, so you will find those hits, but the top 2 are the UCMG. What I know of the support for signal on Windows is that you can set a handler (via signal) and call it yourself (via raise). Nowhere have I seen a hint that Winsock will ever raise a signal. The issue, I think, is that while libc may support a primitive form of signals, Windows itself knows nothing about them. There are few "signals" that are sent to console applications (some in spawned threads), but that is it AFAIK. >> I can only think of one advantage of multiple styles: >> familiarity with existing practice. > > Then I'm afraid your education has been some what lacking. [ad hominem ad nausem] > Threading is greate for certain kinds of high performance > servers but can introduce a lot of complexity. ( potential > for deadlocks, races, priority inversion, starvation etc) Agreed: threads are a (sharp) double-edged sword. Queues of functions can greatly simplify this situation, however. I have written plenty of single threaded async code (using the multithreaded network library) in this way and not suffered any of the problems typically associated with being multithreaded. I also knew that I was trading some performance for that luxury. If it ever becomes necessary to measure this performance loss, I may have more to say on this. :) > Single threaded fork/exec reactive servers eliminate the > complexity of threads but add complexity if they need to > share data ( IPC ) and use heavy weight context switches. > > Both of the above, because of context switching behave > non-deterministically with regard to time. Which is why > you have signal driven I/O. > > We do not chose our architecture based on familiarity > but rather on the requirements and these models each > satisfy different forces. Even though it is my proposal, I sometimes find it difficult to keep interface separate from implementation (based on a thread pool) in my discussions on this topic. I chose to trade some user visible techniques (signals and select-like groupings of objects) for safety, simplicity and portability. Yet, signal-driven I/O may be a viable implementation path for the interfaces I proposed. I have little experience with the fine points there, but I don't see any glaring reason it cannot be done. The biggest concern is documenting what context(s) user callbacks are made. It matters to the user and needs to be clearly spelled out. Also a set of rules derived from the possible contexts needs to be articulated. I endeavored to do so based partly on the interface, but also on the particulars of the implementation I had in mind. Alternative implementations will certainly flavor these topics. Beyond all that, I suffer no delusions that the library I propose will satisfy all needs of all applications. I do believe, however, that the vast majority of applications needing networking facilities do not need to be optimized to such a degree. Apache.org is not going to drop everything and start using this (or any other) C++ library. Within the scope of the design I proposed are many avenues to increase performance. Some involve threads, but with well isolated data per connection, perhaps no locks. Again, this is implied from my implementation, and it is not clear that it should be part of the interface (though it is a useful piece of knowledge<g>). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

RE: [boost] Re: [website] Fluid layout.
by Matt Sutton 15 Apr '05

15 Apr '05

> > Hopefully the current look resolves the edge problem. > Yep. Does for me, anyway. I like the faint highlighting around the groupings on the right. Very nice... Matt Sutton

1 0