This page was last modified 20:55, 22 August 2007.

From Forum Nokia Wiki

I have a few questions/comments regarding binary compatibility (BC). I'd like to hear your opinion about my findings and, if necessary, we should adjust the list according to the end result:

• It's not necessarily true that we break BC if we remove a public/protected method ==> it's only if that method is exported (or virtual). Thus, the first sentence in the current form is not always true for BC, but it is always true for SC (source compatibility).
• Hence the second point is not as accurate as it could be, either. We can change access specifiers without breaking BC as long as those methods (or even members?) are not exported.
• Finally, as to the last point under BC: according to my experience we CAN change data members (remove old ones, add new ones, change type of current ones - assuming that they're all private) without breaking BC as long as the class is instantiated with NewL(C). The point here is that we shall not expose a public constructor to clients. What is the difference between instantiating an object via a public constructor or via a NewL(C) function?

1:
CSomeObject* obj = new (ELeave) CSomeObject;
 
2:
CSomeObject* obj = CSomeObject::NewL();

In the first case, new (ELeave) works so that the compiler calculates the size of the object in question in order to allocate enough space. The point here is that this calculation takes place during compiling my code. If there will be any changes to the internal data representation of CSomeObject in the future so that the size also changes, then my code will allocate a memory area with a different size than required.

As opposed to the second version, where I delegate the task of size calculation to happen in the DLL. So that whenever there's a change, they re-compile their code and I don't even need to be aware of it as long as other BC criteria is kept.

I'm not sure if I could explain this point as much as I wanted to, more importantly, I hope that I'm right. But, please, disprove it! :)

Tote

--Stichbury 20:55, 22 August 2007 (UTC) Hi Tote

I agree that we probably need to amend the list. The topic is a complex one and it's hard to address simply - this has probably oversimplified the issue so, although a useful rule of thumb, isn't totally accurate. I would be inclined to limit this discussion to backward/forward compatibility *only* and create separate pages (if they don't exist already) which discuss source compatibility and binary compatibility, then another which addresses what can be changed without breaking one or the other. It's a huge topic which has been addressed in various books and presentations - to do justice it will need someone to research it thoroughly, so maybe just do the split for now and leave some stubs? They may already be there...

Another thing to consider is that issues of SC and BC often only affect those companies like Symbian and Nokia that put a ROM out and then can't change it. Smaller developers can release DLLs withing SIS packages and, as long as they consider versioning, can get away with making changes more easily and not breaking things.

Jo