On sábado, 23 de novembro de 2013 14:31:42, Yoonsoo Kim wrote: > I don't think so because a virtual member function is translated into an > index to vtable at compile-time in C++ according to my knowledge. It breaks > BC in Java where a virtual member function name is translated into the real > function call at run-time. Due to this difference, Java and C++ has pros and > cons in their polymorphism implementations. Please, let me know if I'm > wrong.
Changing the name but not the parameters of a virtual C++ function is binary compatible, but *source* incompatible. It means old code will fail to compile since it won't be able to find the function that it tried to. This would be useful if you were to replace a virtual function that users are calling with a front-end non-virtual wrapper, which then calls the virtual. Existing code would continue calling the virtual, new code would call the non- virtual front-end. However, note that code that derived from this class and overrode the function will need to be adapted anyway. If you do nothing, the derived classes will be breaking binary compatibility by adding a new virtual when they get recompiled. As a C++ expert, I recommend you do not do this. Doing that should be left to people who really know what they're doing, and only under exigent circumstances. > > For further reading I recommend quite comprehensive document > > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++. > > It's an effect of many years of experience of developing libraries with > > BC in mind. > > I've read it before but will read it again for updates. This article is > pretty famous in C++ programming community, isn't it? And you've got its author here (me). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
