Hi Thorsten, --- Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
1. I hate cryptic short names like
dgram_socket. recv
why not write datagram and receive? (the other short names seems ok and quite standard)
Ok, fair enough :)
Looking at the Daytime1 example, I wounder why
2. asio::ipv4::host host; host_resolver.get_host_by_name(host, argv[1]);
is not written
asio::ipv4::host host = host_resolver.host_by_name(argv[1]);
Basically for consistency with the rest of the library, in particular: - Consistency with a future asynchronous version of the same function. As a rule, in async versions of the functions complex structures or buffers need to be passed as arguments, andthe only difference between the sync and async functions is the callback handler, i.e.: void operation(parameters); template <typename Handler> void async_operation(parameters, Handler handler); - Consistency with other functions that take a complex structure argument (where those functions might need to be member templates and deduce the argument type, e.g. socket.get_local_endpoint).
3. why is everything public in a host?
Only because the host represented data without behaviour, but if a class with member functions is preferred I can do it that way.
4. why does both the stream_socket and the socket_connector need to know about the demuxer? Can't the socket_connector ask the stream_socket for its demuxer (I want to simplify usage if possible)
This may be moot if asio is changed to use connect/async_connect functions on the socket itself. What do you think of that change? However I originally had it this way so that you can have a pool of demuxers (e.g. one demuxer per CPU) and "load balance" your objects across them. So you might have one demuxer where all connections are performed, but once the connection is established the socket is run on a different demuxer.
5. can't socket.recv() use something more highlevel than void* and size_t arguments? Why not std::vector<char> ? (The same applies to all the interface functions)
As others have commented, vector<char> can introduce a performance hit due to default construction of the elements. Also, some applications need to send data structures directly, to avoid additional copies. So I'd prefer to keep the operations on the socket class itself using void*. However, IMHO the place for supporting high level types is in non-member functions like asio::send and asio::recv. E.g. template <typename SyncStream, typename InputIterator, typename Handler> size_t send_range( SyncStream& s, InputIterator begin, InputIterator end, size_t* total_bytes_sent = 0); template <typename AsyncStream, typename InputIterator, typename Handler> void async_send_range( AsyncStream& s, InputIterator begin, InputIterator end, Handler handler); I believe that it's in these sorts of functions that asio offers the most extensibility. Would it be useful to add functions like this to the library itself, and what form should they take? Cheers, Chris