On Wed, May 19, 2010 at 1:02 PM, Gennadiy Rozental <rogeeff@gmail.com> wrote:
Dean Michael Berris <mikhailberis <at> gmail.com> writes:
Putting everything in headers lets me, the library writer to never ever have to worry about preserving ABI because, well, there's no ABI to preserve across releases.
How having simple API with hidden implementation lead to ABI problems?
Well, because your return types might not be trivial and these returned types may have to inherit from some other types that need to be known and need to be preserved across version releases. Of course that is a corner case that might be easily avoided if you only ever returned int's or primitive data types. And then you have to run into the cost of doing a pimpl, and/or the cost of doing virtual function calls when they're really just unnecessary. I'm not even talking about performance here, just the pure necessity of it. If things can and should be done statically, there is no good reason to introduce an additional pointer or a vtable -- even if that reason is to preserve ABI compatibility, because in my head that's not a valid reason. And no, I don't think having pimpls all around will lead to ABI problems -- but it is something that I would rather avoid with just having a header-only library. Because as a library developer, I *don't* want to deal with ABI issues and just be able to release header-only libraries that just work without having to worry about preserving compatibility with earlier releases. But that might just be me. ;) -- Dean Michael Berris deanberris.com