Friends from Skills Matter has put video with lecture about Interface Versioning in C++ given by Steve Love last Thursday. The lecture was organised by London chapater of ACCU.
Generally, Steve addressed problems of the DLL Hell and ABI compatibility proposing a not-so-simple, but applicable and usable solution for number of most common problems. Along the video, slides are also available, so it should be easy to grasp the idea.
I’ve received copy of Steve’s code and I’m preparing a few more tests which I hope to describe in details and post here soon.
Actually this is quite bad idea how to implement such abi issues. It is better to use pimpl ideom. So you provide normal and not virtual functions in API and resolve the rest of it in implementations so adding new functionality would not break ABI.
This is the method Qt adopted it and I use it in CppCMS as well. It is much better then running with virtual functions around.
Are you addressing any specifics of the solution presented by Steve, or generally claiming pimpl is better than virtual functions?
As far as I can tell based on what you’ve said, these solutions are just different.
Perhaps you have described your solution somewhere? I’d love to learn about from motivation to solution :-)
First link is actually KDE policy, very good source:
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
The second one is CppCMS policy: http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_coding_standards#Keeping+backward+compatible+ABI
The reasoning is quite simple:
1. It allows creation of objects on stack and relate to them in simplest possible way.
2. Adding pimpl or d-pointer allows to extend class in future while if it is well designed it allows to keep most of members withing class and probably not even require to have real pointer and implementation.
3. You can preserve real copy and assign semantics of C++ objects and not be restricted to using pointers.
See as example this cookie class: http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/trunk/cppcms/http_cookie.h?revision=1464&view=markup
The “d” pointer is actually not in use, so cookie can be handled very simply, copied and so on as usual object.
I can easily extend this class with new member function add new class members and handle it transparently while from outside it looks like an ordinary class.
That is why pimpl approach or even better “d-pointer” approach is superior.
Now there is one case where you do need to use what was suggested – public abstract classes (a.k.a interfaces) that user expects to implement. You should be very careful in such case.
Artyom,
Thanks. I have heard about the d-pointer techniques in KDE, though I’m not KDE dev/user. I will learn more about it and compare the approaches.
In the meantime, I’m basically interested in this simple DLL-oriented question:
I have my.dll version 1.0 with class X (or interface, does not matter, you know what I mean) exported. I add new method to X and release my.dll version 2.0. Can I drop in my.dll version 2.0 on client’s machine without rebuilding my.dll client software? Do you guarantee KDE’s solution allows that?
Answer to this question is crucial for comparison of these methods.
If the new member function (methods not in C++) is not virtual, yes, you can just drop the old DLL and use the new one without any problem.
If this member function is virtual then… it depends if it implements something defined in parent class or totally new virtual function. If it is new then you can’t, if it implements something in parent you can.