Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Farid_Zaripov@epam.com
 designates 217.21.63.3 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: question on the examples for the source/forward/backward
 incompatible changes
Date: Tue, 27 Nov 2007 20:46:43 +0200
Message-ID: <7BDB2168BEAEF14C98F1901FD2DE643801482FAD@epmsa009.minsk.epam.com>
In-reply-to: <47486D4E.7020005@roguewave.com>
Thread-Topic: question on the examples for the source/forward/backward
 incompatible changes
Thread-Index: Acgux+glnr+9VAuzRoybyvLlRDWx+ACXUqyg
References: <7BDB2168BEAEF14C98F1901FD2DE643801482A48@epmsa009.minsk.epam.com>
 <47477A82.5090105@roguewave.com> <4748677D.9060809@gmail.com>
 <47486D4E.7020005@roguewave.com>
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <stdcxx-dev@incubator.apache.org>

> -----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=20
> source/forward/backward incompatible changes
>=20
> This is an interesting example because it doesn't actually=20
> break programs at compile time but rather changes their=20
> runtime behavior, something that typically is associated with=20
> binary compatibility.

  Why with binary compatibility? 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.


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