Backward compatibility

Comments

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_b5

--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

Log in or Join to leave comments.

Article Metadata

---

Article

Created: ltomuta (08 Mar 2007)

Last edited: hamishwillee (27 Sep 2012)

Backward compatibility means compatible with earlier versions. I.e. an application built with/for version 1.0 of an SDK/system is expected to work as designed on the new version 2.0 of the same system.

Binary Compatibility

Binary compatible means that code built for an older version will run on a newer version without rebuilding.

Few examples of binary-incompatible changes:

• removing a public/protected method/member
• changing access specifiers to more restrictive
• re-ordering exported functions; new exports should be added after the old ones
• changing/adding/removing/re-ordering virtual functions
• order of data members in a class is not important, just that the sum of their size (i.e. the class size) doesn't change.

Source Compatibility

Source compatible means that the code that depends on your component can be still built without changes on a newer version of your component.

Few examples of source-incompatible changes:

• removing a public/protected method/member
• changing access specifiers to more restrictive
• changing return type of functions
• changing function arguments
• changing constness

See also

---

Forward compatibility