stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
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 [] On Behalf Of Martin Sebor
>> Sent: Saturday, November 24, 2007 8:29 PM
>> To:
>> 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

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


     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.


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

View raw message