On 8/31/05, Christopher Kohlhoff <chris@kohlhoff.com> 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."