April 2005 - Boost - lists.boost.org

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

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

15 Apr '05

Hi Caleb, On 4/12/05, Don G wrote: >> I've posted a zip with an HTML file and an HPP >> file that describes an abstract way to interact >> with the network. > > Overall it looks pretty nice. Thanks. :) And thanks for taking the time to look at the proposal. > A few observations: > * port_t should be unsigned short, not unsigned int That is, of course, true of TCP/IP :) > * timeout constructors are inconsistent. One takes > seconds + microseconds and one takes milliseconds, > at least according to the names of the arguments. Yeah, that was one of the adjustments I tried to make as I boost-ified the code. The Windows way is millisecs, but Unix is microsecs. To do microsecs, I think we would have to use uint64's. That would be fine by me, but I wasn't sure how widely supported it is. I know that for Solaris (SunPro), gcc, MSVC, CodeWarrior, uint64 is good. Of course, a timespec doesn't use uint64. La de da... :) > * I wouldn't call the type you pass to the > network::new_{local,broadcast,loopback,}_address > method a "url". It isn't one. But it is, at least from what the description in RFC 2396. You can pass this: http://user:pswd@www.boost.org:8080/foo?x=42 and it would create an address object given that description. The resolved (physical) address would be something like: http://user:pswd@66.35.250.210:8080/foo?x=42 > Perhaps "address_specifier" would be better? I can > imagine some sort of "stream factory" class with > pluggable protocols (e.g. http, https, ftp, etc) that > would take fully qualified URLs to create new > streams, but in this case you're dealing with at most > a hostname and port. Well, the semantics of such things quickly become non-streams. The intention of the scheme ("http") is to establish a port by means of name lookup. In the end, yes the URL is resolved to address/port. If an HTTP library was built on top, it would do no transformation before passing its URL to new_address(). Hence, the type "url". > I'd contend that in general, an operating system supplied > multiplexing facility will scale better than one that uses > a thread to handle each connection. Absolutely. The code I have in mind uses a thread pool and connections are managed by as few a number of threads as necessary. On Windows, each I/O thread can handle 64-ish connections. On Unix, it is much higher. By default, I create one I/O thread per processor and divvy up the connections. > Without some sort of multiplexing facility, how do > you know when a channel is ready for I/O? It seems that > your proposal is to use a pool of threads to handle > async/non-blocking operations, but I don't see any > interfaces defined to control or manage these > operations. Is that just TBD? I have contemplated just how a user would want to interact with the thread pool behind the scenes, but, it is ideally an issue of minimal concern. Of course, for advanced users it could be something that needs to be tweaked. In that sense, there is a TBD aspect. I just have yet to see a good abstraction/mechanism for doing this. > Clearly Windows select and WFMO are not as scalable > as UNIX select/poll/etc, In one sense WFMO could be better (it would not be constantly repopulating fd_sets), but select or IOCP (I/O Completion Ports) are it AFAIK. And IOCP is NT only (for those who care). > but I'd contend that if one is writing a serious > networking application for Windows, you are going to > make use of *both* of these approaches (>1 instance > of WFMO/select and thread pooling). > In some cases, you may want to do this on UNIX too. If one could do everything async, there should be no reason for another thread pool. That would become important only if some connection(s) had to do work that would prevent other connections from progressing fairly (for example, by making blocking calls). > I think the point I am trying to make is that there > isn't necessarily one right answer. Pools of threads > are good for some things, and I/O multiplexing > facilities are good for some things. And in some > cases, taken both together they are a good thing as > well. The threads in this pool are only doing I/O multiplexing, so I'm not sure I understand your concern. The kind of thread pool in my implementation is just to have roughly the minimum number of threads compared to connections based on multiplexing limits. Another kind of thread pool would be one/two per connection to handle blocking activity. The blocking methods in the proposal could be used when that was the right answer. Or did I miss your point here? For best possible performance, one would want everything to be async and handled directly in the I/O thread. That would eliminate undesirable context switches. Since a given connection has all its callbacks made from one thread (though that thread can change over time), it wouldn't even need a lock as long as side effects were confined. I guess what I should do is write lots more in the HTML file :) There are many areas left unclear that probably lead to confusion. Again, thanks for the very thoughtful response! Best regards, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 6

Re: [boost] Re: Boost to the rescue
by Iain Hanson 15 Apr '05

15 Apr '05

On Fri, 2005-04-15 at 09:05 -0700, Robert Ramey wrote: > My experience in this regard is surprising to me. > > I'm amazed to discover that in only ONE single case have any of the > programmers, managers, etc ever even heard of boost. This group even > includes an ex head of the computer science department at a top tier > university !!! Sadly this is what I would expect. However, I have been surprised by the number of companies in London ( U.K. ) That have heard of boost. Mostly in the International banking sector. The most popular library by far has to be smart_ptrs. > When I first came upon boost, I was agog at the possibilities it opened up. > The utiliy and power of the whole was blindingly obvious to to me. As I get > older, I feel more and more disconnected from the rest of to programming > world. > I know what you mean. Many programmers are still stuck at the C++ is a better C stage and very few over here seem to understand or use design patterns :-(. /ikh

2 1