- Boost - lists.boost.org

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

[wesite] Version history page
by Rene Rivera 15 Apr '05

15 Apr '05

I added the version history page that Daryle created, as a "Version History" link under the "Support" section. It has what would be a full version of the same style. With the footer having the license, etc info. http://redshift-software.com/~grafik/boost/index.htm Or you can look at the page directly.. http://redshift-software.com/~grafik/boost/more/version_history.html -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

4 4

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

15 Apr '05

> > I like it at the right. I don't see any reason why it can't > be in the > > right. Could you give us a link to a W3C reference that says > > navigation bars should be in the left? > > While I don't know of any clear recommendation to put a > navigation bar not on the right side in my opinion it > violates Jakob Nielsen's rule "Do the same as everyone else" > (see #10 of "Ten Good Deeds in Web Design" at > http://www.useit.com/alertbox/991003.html) There have been > some links posted to websites that have the navigation on the > right side. However I would rather follow the mainstream. > Look at all the explorer-style windows in your operating > system: Navigation is always on the top and on the left. > If you really want to make an exception and put the > navigation bar on the right side you need a strong reason to > come up with something unusual. > Out of curiosity, have you experimented with the look of full justification for the text? At least for sentences that span multiple lines. I not a web designer, and like most other suggestions this is purely subjective, but I wonder if a subtly sharper edge on the right might further instruct one's eye to perform a carriage return/line feed? Kind of like a newspaper. Matt Sutton www.padtinc.com

2 1

Debug Version of Project cannot be compiled with boost 1.32.0 and STLPort4.6.2..(boost\config\auto_link.hpp)
by Manish Mangal 15 Apr '05

15 Apr '05

Hi I am using boost 1.32.0 libraries along with STLPort4.6.2 on .Net2003 VC7.1. The release version of the Project compiles and runs successfully, but the Debug version gives the following error: warning: STLPort debug versions are built with /D_STLP_DEBUG=1 c:\SourceLibrary\Boost\boost_1_32_0\boost\config\auto_link.hpp(170) : fatal error C1189: #error : "Build options aren't compatible with pre-built libraries" I have included _STLP_DEBUG in the C++ Preprocessor settings for the Debug Version.. Can anyone help me?? Thanks in advance. Manish Mangal Stratagen Systems 1-425.821.8454 ext. 136

1 0

FYI: old laptop
by Michael Glassford 15 Apr '05

15 Apr '05

I had the old laptop turned on for about an hour, not using it, when I got a black screen with this error: "Memory write/read failure at 0FFF0000, read FF10FF00 expecting FF10FF10 Memory address line failure at 0FF0000, read FF10FF10 expecting 00000000 Strike the F1 key to continue, F2 to run the setup utility" I hit F1 and it restarted and gave me a similar error. I'm trying it right now with the other DIMM. Maybe it doesn't like me anymore :) Mike

1 1