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."