incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: question on the examples for the source/forward/backward incompatible changes
Date Wed, 28 Nov 2007 02:00:57 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Saturday, November 24, 2007 8:29 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: question on the examples for the 
>> source/forward/backward incompatible changes
>>
>> This is an interesting example because it doesn't actually 
>> break programs at compile time but rather changes their 
>> runtime behavior, something that typically is associated with 
>> binary compatibility.
> 
>   Why with binary compatibility?

Because changing the behavior of a function (or class) while
maintaining the same interface is usually considered a binary
incompatible change. E.g., changing the implementation of foo
from

     void* foo (int n) { return malloc (n * 2); }

to

     void* foo (int n) { return malloc (n); }

is a binary incompatible change. But simply adding an overload
for foo like this:

     void* foo (char) { return new char [256]; }

while binary compatible, is a source incompatible change. It
seemed like a subtle and interesting distinction to me :)

> From the current document:
> "Source compatibility also implies functional compatibility, although it
> does not necessarily imply binary compatibility."
> 
>   In this case if program already compiled this change is binary
> compatible, because the
> program don't knows about new overload of the existing function. At the
> same time this
> change is not source compatible because it's changes functionality of
> the program,
> compiled with the library with new overload function.

That's right.

Martin

> 
> 
>> Incidentally, we even have an enhancement request for this 
>> new inserter (maybe you've seen it):
>>      http://issues.apache.org/jira/browse/STDCXX-296
>>
>> But there certainly are cases where adding an overload can 
>> break programs by introducing an ambiguity where there 
>> previously was none.
>>
>> Martin


Mime
View raw message