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 msebor@gmail.com designates
 209.85.146.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=VzZVB+dI7/5DN0okTZJC43zWJv5tZvpsojn/kJXFn51jYKMIugrIcLvhHTMC+JEEkxeJsgrQciSair/F5GTYQRy3QNVT+EfgscnVgpFOPMH761vMcS5ME4Q0iBozw9f6ey/l2O0w5kj5gqcMeW3RStSD83MUpkZIWUYBMy7kW38=
Message-ID: <47477A82.5090105@roguewave.com>
Date: Fri, 23 Nov 2007 18:12:34 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071031)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: question on the examples for the source/forward/backward
 incompatible
 changes
References: <7BDB2168BEAEF14C98F1901FD2DE643801482A48@epmsa009.minsk.epam.com>
In-Reply-To: 
 <7BDB2168BEAEF14C98F1901FD2DE643801482A48@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Farid Zaripov wrote:
>   Whether these examples should be abstract, or based on C++ Standard
> Library
> declarations/definitions?

Examples using the C++ standard library classes or functions would
be great, but any other sort will, in my opinion, work just as well.
The point is to highlight the general kind of changes people might
easily think are compatible when in reality they're not.

> 
>   Since the source  incompatible changes involves changes in
> function/class mebmers
> prototype, or changes in global data/class data members declaration, or
> changing the
> place of the some declaration (i.e. moving the declaration from one
> header file to the another),
> but requirements of the all of this are stated in C++ Standard and,
> accordingly, any of these
> changes are impossible.

Let me give one example where this isn't true. The standard leaves
it up to each implementation to decide whether to define overloads
of certain functions or whether to make use of default function
arguments. For instance, vector::resize() can be declared in one
of two ways:

     resize(size_type, value_type = value_type());

or

     resize(size_type);
     resize(size_type, value_type);

Changing from one form to the other is detectable and might qualify
as a breaking change. First, programs that explicitly instantiate
vector on a user-defined type that's not default constructible will
compile with the first declaration but not with the second (because
the definition of the first overload must default-construct the
element). Second, programs that take the address of such functions
will not compile. The standard leaves the exact type of library
member functions unspecified so it's up to us whether we want to
go a step beyond and provide a stronger guarantee or not.

Martin