Re: [boost] [review] Asio formal review.

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 07:29:53

Hi Rene,

--- Rene Rivera <grafik.list_at_[hidden]> 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