stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brown <mark.g.br...@gmail.com>
Subject Re: question on the examples for the source/forward/backward incompatible changes
Date Sat, 24 Nov 2007 18:53:05 GMT
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


Mime
View raw message