Re: [boost] asio networking proposal

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-08-31 15:35:54

On 8/31/05, Christopher Kohlhoff <chris_at_[hidden]> wrote:
> Hi Felipe,

Hi Christopher,

> 
> The overhead is not the virtual function call itself, but all the other
> stuff that gets generated by the compiler as soon as you add a virtual
> function to a class (e.g. vtable, RTTI etc).

Now I see. But..
Does it worth rewriting virtual mechanisms? I think that boost
libraries rely a lot on compilers doing the right job and write code
that, when possible, are elegant.
I think it is a lot more readable with virtual functions. And it's not
only with win_iocp_operation that this happens I think.

> 
> Since you can very easily end up with many win_iocp_operation-derived
> classes in your application (one for each callback handler) using
> virtual functions can contribute to significant code bloat on some
> compilers (e.g. MSVC6, although with MSVC7.1 it appears to optimise
> unused RTTI away).

I can only enumerate two classes deriving from win_iocp_operation, no
matter how the client uses the normal interface of library. The two I
think are: win_iocp_demuxer_service::read_operation and
win_iocp_demuxer_service::write_operation.

> 
> By doing this little workaround, I can guarantee for all compilers that
> the overhead for each handler is limited to a single function, which is
> called through a function pointer.

AFAICS, this workaround is only effective with VC6. I'm only saying
all this because I'd like to have all libraries in boost rewriting
virtual mechanisms.

> 
> Cheers,
> Chris

Thanks Chris,
Felipe.

-- 
   Felipe Magno de Almeida
Developer from synergy and Computer Science student from State
University of Campinas(UNICAMP).
Unicamp: http://www.ic.unicamp.br
Synergy: http://www.synergy.com.br
"There is no dark side of the moon really. Matter of fact it's all dark."