Re: [boost] asio formal review

From: Eugene Alterman (eugalt_at_[hidden])
Date: 2005-12-13 12:15:17

"Christopher Kohlhoff" <chris_at_[hidden]> wrote in message 
news:20051213113710.76328.qmail_at_web32615.mail.mud.yahoo.com...

> The derived type should bring all public names from core_socket
> into its own public interface. Are using declarations OK in this
> case? If not, then via forwarding functions.
>
> That way existing uses of stream_socket continue to work as-is.
> Uses of stream templates would lose access to the underlying
> socket's I/O functions, as you want.

That's precisely what I've anticipated to come up next . :-)

I just want to provide an illustrating example. This is an actual situation 
I encountered while experimenting with asio that prompted me to advocate 
these changes.

I was trying to write a server that would run over a regular tcp connection 
or a secure connection depending on a run-time program option. I created an 
abstract base session class that contained all the transport-independent 
processing logic. It had a pure virtual function that I misleadingly named 
socket() returning a tcp socket to be used by the acceptor. Then I made a 
stupid mistake - instead of  also providing  virtual functions for i/o I 
started using socket() for that. You can imagine what I ended up with on the 
secure server!.

The proposed changes would have prevented me from making such a mistake.