Hi, --- RocWood <rocwood@21cn.com> wrote:

Yet I still have a little complain that "header files only" makes the compile process slower and slower with the functions of asio grow more and more.

In the longer term I plan to support a separate library (possibly an optional one) that keeps system headers away from application code (i.e. to prevent the namespace pollution that system headers sometimes introduce). However this is not currently a high priority for me as it doesn't affect asio's API. In terms of compile times, my testing indicates that, on Windows with MSVC, windows.h and friends are responsible for at most 30% of the compile time. The rest comes from asio + standard library headers, and the fact that it uses templates extensively. In 0.3.4 I do now test that every public asio header file can compile on its own, so you can probably gain some improvement in compile time by only including the headers that you need, rather than the catch-all asio.hpp.

Furthermore, I guess that it use static class member initialization for win32 socket WSAStartup, which seems to be a potential occasion for users to make a bug(just guess, not sure) while more than one c++ source files include asio headers.

This should be ok, as it's a static member of a class *template*. In cases where multiple definitions cannot be avoided (e.g. multiple DLLs using asio) the multiple initialisations of winsock should still work just fine (although there may be a memory leak per definition).

Would you please consider a header+source version with clean and simple header files ?

I do understand the desire for short, clean header files :) However the main problem is that to do that I would have to abandon any hope of supporting older compilers like MSVC6. At the moment I believe that a large and still useful subset of asio will work for MSVC6, but MSVC6 does require that you put member template function definitions inside the class definition. I'm not ready to give up on it completely... yet ;) Cheers, Chris

Hi Beman, --- Beman Dawes <bdawes@acm.org> wrote:

There are still some void *'s in the public interface. The io_control

helpers have data() members returning void *'s, for example.

Any chance of wringing out the non-memory management void *'s before a submission? I know it sounds picky, but a lot of C++ programmers object strongly to void * in public interfaces for anything except the rawest of raw memory management.

Hmm, I'm not sure. Here are the current uses of void* and their rationales: * buffer() and buffers() - so that arbitrary application data structures can be sent without an additional buffer copy. * const_buffer::data() and mutable_data::data() - to get a pointer to pass to OS functions like send and recv. * IO_Control_Command::data() - to get a pointer to pass to OS functions like ioctl or WSAIOCtl. * Socket_Option::data() - to get a pointer to be pass to OS functions like setsocketopt and getsockopt. The last 3 are similar, in that they involve getting a pointer to be passed to a low-level OS function. (Note that the Endpoint concept has a similar thing, except that it returns an implementation-defined type rather than void*.) I don't want to preclude user-defined IO_Control_Command or Socket_Option types, so there has to be *some* way of getting a pointer to the data in the public interface. However I'd be very happy to change it if there's a better way of accomplishing the same thing.

I also wonder if the interface could be thinned without reducing functionality. For example, could buffer() and buffers() be folded into one function, or at least overloads with the same name.

I had considered making the mutable_buffer/const_buffer classes also implement the Mutable_Buffers/Const_Buffers concepts, but i found it was confusing as to whether the begin()/end() functions applied to the underlying memory. What about this for an idea: - Remove the buffer() functions. - Rename buffers() to buffer(). - Have a specialisation for const_buffer<1> that supports conversion to const_buffer. - Have a specialisation for mutable_buffer<1> that supports conversion to mutable_buffer and const_buffer. Then to send a single buffer you could write: sock.write(buffer(data, size)); and still use the chaining to send multiple buffers: sock.write(buffer(data1, size1)(data2, size2)); The conversion to the individual buffer classes should still let you write: std::vector<const_buffer> bufs; bufs.push_back(buffer(data1, size1)); bufs.push_back(buffer(data2, size2)); sock.write(bufs);' or: const_buffers<2> bufs = { buffer(data1, size1), buffer(data2, size2) }; sock.write(bufs);

Likewise, could the 12 free read/write functions be reduced to 2 names (presumably read/write) or 4 names (presumably read, async_read, write, async_write) via folding and/or overloading?. Am I the only one who feels the large number of names makes the interface appear more complex than it really is?

No you're not, especially after I've had to type async_read_at_least_n many times ;) Reducing to 4 names might be feasible. One thing I realised recently is that, in terms of behaviour, read() and read_n() are just special cases of read_at_least_n(). The same obviously applies to write*() and the async equivalents. Could something be done by extending the Mutable_Buffers/Const_Buffers concepts to have a desired_minimum_transfer() member function? Bad name, I know, but it would return the minimum number of bytes to read or write from the list of buffers. It would have to be optional so that containers like std::vector can still meet the concept requirements. It would probably have a default of 0, i.e. same semantics as current asio::read() or asio::write(). You could then write: read(sock, bufs); // Same as existing read() read(sock, all_of(bufs)); // Same as read_n() read(sock, at_least(bufs, 42)); // Same as read_at_least_n(). I'm ready to take guidance here :) Cheers, Chris

Hi Beman, Just addressing the void* buffers issue for now... --- Beman Dawes <bdawes@acm.org> wrote:

Where did this idea come from that the only way to avoid an additional copy is to use a void *?

It's not just avoiding a copy, it's avoiding a copy *and* allowing arbitrary data structures to be sent. IMHO an important use case for C++ and networking is being able to do things like: struct message { int a; double b; int c_size; char c[0]; }; message* m = ...; sock.write(buffers(m, sizeof(message) + m->c_size)); Additionally, we must consider the fact that socket operations are byte-oriented and that they can, and usually do, result in fewer bytes being transferred than was requested. If we do not allow an interface that can address arbitrary memory, what happens in a situation like this: double values[100]; size_t bytes_read = read(sock, buffers(values)); // bytes_read == 17, what now?

Think about the iterator interfaces to Standard Library algorithms. They traffic nicely in pointers, yet not a buffer copy or void * to be seen.

So instead of:

... foo( void * data, size_t size);

something like:

template <class RandomAccessIterator> ... foo( RandomAccessIterator first, RandomAccessIterator last );

The RandomAccessIterator concept, as an example, is not strict enough for a networking use case, Unlike STL algorithms, we must consider that the underlying OS primitives deal in contiguous memory with a granularity of bytes. So, I firmly believe that a representation of raw memory is essential. The mutable_buffer and const_buffer classes are trying to provide a "safe" representation of this concept. They already address the issue of buffer overrun protection. And I do feel that the buffers classes (i.e. address & size) represent the restricted concept of a contiguous memory range better than iterators. If the issue here is preventing violations of type safety then how about I make conversion into a mutable_buffer/const_buffer a (for the most part) one-way operation. Or put another way, the buffer is in a sense typeless. That is, it is relatively easy to create a buffer object that represents some memory, but harder to go back the other way. In practice this means removing the void* data() member function from the buffer classes, and replacing it with a template <class T> T data_cast(...) as you suggest (although I might call it buffer_cast). The asio internals will use buffer_cast<void*>(buf) to obtain the pointer to be passed to send() or recv(). The buffer(void*, size_t) overload would be retained however, but since this is a conversion *to* a "typeless" buffer, I don't see this is a type safety violation in itself. You would have to use buffer_cast to violate type safety now. Cheers, Chris