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
