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 mark.g.brown@gmail.com
 designates 64.233.170.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=xSW/japAeQh1Trl9u5qbVcUhyzxDNk7TqEqpLrJGMnbmzd8VtwXkcdkWQTMcNlqN9heFWfmngJ8iNO6VHrCyy1EgMWEvBzI2hZPpw4NhpLiw08aGjwqiGT2X5tvxYYkME5IlTsDup6bMT/NzM868zxji8zoslVlLlfKnD5RnCow=
Message-ID: <47487311.7030104@gmail.com>
Date: Sat, 24 Nov 2007 11:53:05 -0700
From: Mark Brown <mark.g.brown@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text SeaMonkey/1.0.9
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>
 <47477A82.5090105@roguewave.com> <4748677D.9060809@gmail.com>
 <47486D4E.7020005@roguewave.com>
In-Reply-To: <47486D4E.7020005@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Martin Sebor wrote:
> Mark Brown wrote:
> [...]
>> Or adding overloads with different behavior to functions that are
>> a better match for calls in existing programs. For instance, if we
>> added an overload for the ostream inserter for wchar_t* that did
>> something different than print the value of the pointer it would
>> break programs that insert wchar_t pointers into narrow streams.
>> So code like this: std::cout << L"insert a pointer"; inserts the
>> address of the wide string today, but if we added the overload it
>> would write the string itself.
> 
> 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.
> 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.

True. And even adding a new function can break source if its name
happens to be the same as the name of some user-defined function.
Namespaces are supposed to help prevent this but they cannot help
with member functions. For instance, adding the member function
data() to std::vector will break a class that derives from vector
and that calls a global function called data.

--Mark