- Boost - lists.boost.org

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 09:14 -0500, Edward Diener wrote: > Boris wrote: > 1) No one normally uses 1000 sockets. Be real rather than hyperbolic if you > are trying to make a point. Sorry, but that is a bad assumption. A server that I'm currently working on will have 1,000's of sockets open concurrently. Application gateways, web servers and database connection concentrators are typical of Apps that often need large numbers of sockets. /ikh

2 1

Re: [boost] Re: Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 18:02 +0300, Boris wrote: > Iain Hanson wrote: > > On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: [snip] > I don't think our opinions are very different. You agree that library users > should have some control about the implementation for a better performance. yep! > There is really a trade-off between design and performance. As we have seen > in another thread today's operating systems don't support asynchronous I/O > very well. They don't need to as long as they support threading. > In Linux asynchronous I/O would be probably best implemented > using epoll() as multiplexing is the traditional *unix way. No. The unix way is to have as many orthogonal ways of doing something as possible ;-). Because the user knows best what works well on their platform they should probably be able to select the implementation whether it uses epoll, user space threads, or kernel supported aio. > A C++ network > library which can't support efficient I/O because of its design won't be of > much use. It could be perfectly designed but it couldn't be implemented > using best available I/O APIs on different operating systems. > I don't understand what your trying to get at here. There are sufficient mechanisms to does this on all the major platforms. It is just that they happen to vary by platform. /ikh

1 0

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: > While asynchronicity in .NET is basically based on threads it is not true > for asynchronous I/O. If you built asynchronous I/O on top of an > asynchronicity library with callbacks in threads you will end up with 1000 > threads blocked in read() if you have 1000 sockets. No. This would be a configuration or implementation detail. The only requirement is that you have at least 1 thread dispatching async requests and queueing work to be dispatched. LibC AIO has an init function where the user can supply a hint regarding size of thread pool to use. I think the contract for a C++ lib should be stronger and allow the user to specify/control the size of the thread pool as well as the type of the ACT ( not just callback, but signal and polling ). /ikh

2 1

[format] conversion to string
by Vladimir Prus 01 Apr '05

01 Apr '05

Hello! While it's generally considered a bad practice to provide implicit conversions, I think it would be good to provide such a conversion for the boost::format class. Currently, I can't write: string s; s = format("%1%") % 10; and need to write s = (format("%1%") % 10).str(); Maybe it's specifics of my code, but I can count 10 such conversions in a single source file. I think that: 1. Calling .str() is rather inconvenient. 2. The 'format' class most often used inside expressions. It's not likely to be passed around to functions and so the dangers of implicit conversions are not critical. Thoughts? - Volodya

4 7

Re: Asynchronous I/O
by Don G 31 Mar '05

31 Mar '05

Hi Robert, Thanks for contributing to these discussions! I hope that with you and the others involved we can get this long overdue library off the ground. Anyway, to respond to your question: --- Robert Ramey wrote: > The question here is: > > Is aio.h interface not sufficient in some way? If not, what > facility is it missing? If it is sufficient, then just > depend on the available implementation or re-implement the > interface in the most convenient way. > > Robert Ramey IMHO, the "io" part of "aio" is the primary thing what makes it insufficient. Unless I misread the man pages, I cannot post custom events or messages with aio; it is all about I/O on file descriptors. Which brings me to the other problem. At least on Windows, a file != socket != pipe != etc (regardless of the quasi-polymorphic WaitForXXX functions). If we constrain the discussion only to sockets, then this approach could be used. Sadly, pipes are a totally different ball game. If memory serves, the CygWin folks "mapped" all such types of objects to fd's, but doing so was very heavy handed. There was no other solution to their particular problem, but that is not the case here since we can invent the interface. The first issue is what spawned to Asynchronicity thread: given a general async mechanism, I/O could be easily adapted to it. The interface could be portable, even given the diverse ways and means necessary to achieve the goal. If we are to adopt an existing interface, I believe that it should be general enough for non-I/O uses. It should also be something that could be implemented on all platforms without undue inefficiency (something a select-style interface could not do, IMO, because of the poor performance of populating fd_set's or their moral equivalent). In a previous post I showed that the async technique I am proposing could be (fairly<g>) easily used to shield the application from library worker thread issues. With a little more work (and coupling), the use of channel.async_call could be encapsulated/automated to simplify the user experience. Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

3 3

Boost policy on relying on std library implementation defined behaviour
by Jonathan Turkanis 31 Mar '05

31 Mar '05

Hi All, Is there a reason to avoid providing a uniform interface to implementation-defined standard library features? One of the most often heard complaints about the standard iostreams library is that there is no portable way to seek within a file stream using large (64-bit) offsets. Simplifying a bit, the standard library provides functions for seeking within a stream using - an offset of type streamoff, which may be 64-bits but is sometimes smaller, or - a position indicator of type streampos (usually fpos<mbstate_t>), a non-integral implementation defined type, with implicit conversions to and from streamoff. (streampos also stores a code conversion state, but I'm ignoring this) There are platforms where streamoff is inadequate to express an arbitrary seek offset, and where streampos is adequate, but only if implementation defined functionality is used. (There might be cases where neither type is adequate, but I'm ignoring this) I would like to implement functions which provide conversions between a large integral type and streampos. This will allow most uses of streampos to be hidden, with library users specifying integral types most of the time. The alternative would be: 1. provide additional concepts which require user defined filters and devices to implement functions involving streampos, AND 2. force users to deal with streampos directly, relying whatever guarantees are provided by their standard libraries. Point 1. requires complicating the iostreams library interface. Point 2. forces users to implement functions which could instead have been implemented just once by the iostreams library. What do people think? Jonathan

6 11

Re: [boost] Addition for shared_ptr
by Peter Dimov 31 Mar '05

31 Mar '05

Michael Rutman wrote: > At 1:40 PM +0300 9/20/04, Peter Dimov wrote: >> Michael Rutman wrote: >>> I'd like to propose adding a template function to shared_ptr to >>> allow the automatic testing of a shared_ptr to its raw ptr. >>> >>> The template is as simple as >>> >>> template <class T> >>> bool operator==(boost::shared_ptr<T> const & a, T * const & b) >>> { >>> return a.get() == b; >>> } >>> >>> >>> Here is the case where I need it. >>> >>> I have a vector<Foo> myFoo. >>> >>> In a method of Foo I need to see if this instance is in the vector. >>> I want to do this >>> >>> vector<Foo>::iterator iter = find( myFoo.begin(), myFoo.end(), this >>> ); >> >> This is a reasonable suggestion. It turns out that std::find _is_ >> specified in a way that allows heterogeneous comparisons, although >> this may be an oversight on the part of the committee and not a >> design decision. ;-) > > Any chance this can go in for the next release? <tilts head and ponders for a moment> Probably not, but not because it's necessarily a bad idea. I only add extensions to components already in TR1 if I'm reasonably sure that I want to (formally) propose this extension for a later version of the component (TR2, or C++next). Which in this case I'm not (yet).

1 0

Detecting static member constants on GCC
by David Abrahams 31 Mar '05

31 Mar '05

It seems GCC 3.3.3 doesn't like to do SFINAE based on the validity of T::value: int f(...); template <class T> int f(T, int(*)[T::value] = 0); int x = f(1); // error: `int' is not an aggregate type The same applies when eliminating partial specializations via SFINAE. Has anyone got an alternative approach? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[assign] MinGW list_of() set<string> problem
by Daniel Schlyder 31 Mar '05

31 Mar '05

The following used to compile: std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen"); I'm not sure why, as Boost.Assign's docs seem to say I should have had to use the to_adapter function. Anyway, I recently started getting the following error: E:/libs/boost/boost/assign/list_of.hpp: In member function `boost::assign_detail::generic_list<char[7]>::operator set<string>() const' : E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:334: error: call of overloaded `set( const boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> > & )' is ambiguous After changing my code to std::set<std::string> const virtual_control::s_unbindables_permanent = boost::assign::list_of("Escape")("PrintScreen").to_adapter(); I now get the different error E:/libs/boost/boost/assign/list_of.hpp: In member function `set< string > boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::convert_to_adapter(const set<string> *) const': E:/libs/boost/boost/assign/list_of.hpp:200: instantiated from `boost::assign_detail::converter< boost::assign_detail::generic_list<const char *> >::adapter_converter::operator set<string>() const' E:\code\cpp\dasc\wc2\lib\alex\src\virtual_control.cpp:413: instantiated from here E:/libs/boost/boost/assign/list_of.hpp:179: error: 'class set<string>' has no member named 'push' To me, this looks like an error in Boost.Assign. Am I doing something wrong? Thanks, -- Daniel Schlyder http://bitblaze.com/

2 9

[range] update on ADL hooks
by Thorsten Ottosen 31 Mar '05

31 Mar '05

Dear all, I'm going to change the ADL lookup hook of range functions. instead of the irritating void foo() { using namespace boost; begin(r); } we simply now say void foo() { boost::begin(r); } and get full ADL lookup. This changes the extension protocol to overiding these three functions: range_adl_begin() range_adl_end() range_adl_size() Any comments before I commit? -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com www.cs.aau.dk/index2.php?content=Research/bss www.boost.org www.open-std.org/JTC1/SC22/WG21/

6 56