Hi Rene, --- Rene Rivera <grafik.list@redshift-software.com> wrote:
In my continue reading and use of the code I concluded that the basic design flaw is that the underlying *socket_service classes are not available as a public interface.
I don't understand how not exposing the implementation details is a design flaw.
You might consider it an implementation detail. But depending on the context it might not be considered a detail. At minimum, in this case, I would expect to be able to choose which implementation to use. And in some situations I might want to make that choice at runtime, not just compile time. For example some would consider the std::deque<T> container behind an std::stack<T> to be an implementation detail. But I might want to use a circular_deque<T> instead, for those cases where I want to make certain memory guarantees. After all it's how we draw the abstraction line that we worry so much about in Boost. In this case I think you've drawn the line too far up preventing some alternate uses of your library.
One of the goals of asio is portability. I believe the level of abstraction I have chosen is the lowest possible that is consistent with this goal. The internal implementations are highly platform-specific. In the future, I might consider having these platform-specific implementation classes mature into some sort of secondary public interface. But since that's not one of my design goals it has a low priority. <snip>
I didn't realize I implied runtime polymorphism. I was only thinking of the simple ability to create different kinds of clients/servers based the OS signaling method. It's not possible right now since one can't instantiate in a type safe manner different datagram_socket_service variants. for example.
If I'm understanding you correctly, what you are after is a single program, where you you have some sockets using one demuxing method (say epoll) and other sockets using (say) select? Interesting. Asio does allow you to customise the implementation of things like datagram sockets. For example: class my_datagram_socket_service { ... }; typedef basic_datagram_socket< my_datagram_socket_service> datagram_socket; You are free to reuse the existing internals (or not) to do this as you see fit. But I can't imagine that this scenario would be applicable to a broad enough audience to warrant spending the time to make it convenient.
It solves the allocation problem, but not the reuse problems.
As I said, you can reuse the implementation, but the public interface you're asking for is not in the scope of asio's current design goals. Cheers, Chris