Re: [boost] asio formal review - polymorphism and impl re-use

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-26 00:39:49

Christopher Kohlhoff wrote:
>>I would like to see the aspects of a socket that have nothing
>>to do with reading/writing better separated, as this would
>>make for a more consistent interface for other forms of I/O
>>such as pipes, message queues etc as well as files.
> 
> 
> For stream-oriented I/O, this separation is presented in the
> form of the Stream concept. This concept is implemented by
> stream_socket, ssl::stream, buffered_read_stream and so on. It
> would be implemented by a hypothetical pipe class.

Precisely. Why write it/maintain it again?

>>A very simple active object template that supports read and
>>write, but that relies on free functions or helper classes for
>>less universal operations such as bind, setting options, etc,
>>used as a base class, allows appropriate (and necessary in my
>>opinion) use of runtime polymorphism.
> 
> 
> I have to disagree on runtime polymorphism: compile-time
> polymorphism should always be the default.

A tad dogmatic. Would you like to qualify "always" at all? What do you
mean by "default" - is the default selectable at design/implementation
or compilation time?

> Runtime polymorphism
> can impose additional costs (such as virtual function calls on a
> fine-grained interface), and eliminates potential optimisations.
> This adds up considerably if there are many layers of runtime
> polymorphism involved.

Can we cut the re-education program for java programmers :-) out of this
and deal with the use case constructively, or would you prefer to ignore it?

I qualified my concerns about performance by saying they lacked actual
benchmark results, however I have now seen posts from others backing my
concerns (between the time I spent responding and gmane being my only
interface at the time I hadn't seen Caleb's results when I posted). You
are now expressing concern about virtual function overhead etc with no
measurements to back it up and no qualification of when they are "bad".
In the development of the library I referred to in my post I have
measured negligible performance impact from runtime polymorphism. A
double indirection is unlikely to be significant compared to the other
operations being performed. Users expect to be able to use eg. an
iostream of some sort without having to template every bit of code that
uses it on what sort of stream it is.

> Runtime polymorphism can be layered on top of compile-time
> polymorphism using some sort of wrapper.

Yes (see below).

> I am not certain if this is something that should be included in
> asio or not, since the appropriate place to introduce runtime
> polymorphism can vary according to the design of an application.

The appropriate place to introduce compile time polymorphism can vary too...

> What do you think? I'd be happy to add it if you think it
> generally useful.

I do think it is generally useful.

>>Short of placing a wrapper around asio to make it more
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes to the following - but there is an aspect of code re-use that it 
doesn't address.

> 
> Would the polymorphic wrapper I proposed above address these
> issues?

>>As far as I can see asio doesn't even allow interchangeable
>>use of an ssl and a tcp stream.
> As I mentioned above, asio addresses this using compile time
> polymorphism, with the Stream concept being implemented by
> stream_socket and ssl::stream. For example, both work equally
> well with free

template !

> functions like asio::async_read.

>> I'm
>>also concerned about the potential code bloat from unnecessary
>>duplication of code (not from differnt template parameters,
>>but from outright duplication in differnt templates).
> 
> 
> Can you please point these out? I'm always in favour of reducing
> code bloat.

I'm referring to the potential for bloat if eg a pipe service duplicates
much of the socket interface. I know openssl is quite weird enough to be
a special case all of its own, but I would expect many systems would be
able to share a lot of implementation across different stream-like
file/socket/device interfaces at least.

Regards
Darryl Green

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.7/214 - Release Date: 23/12/2005