Rob Stewart wrote:
From: "Peter Dimov" <pdimov@mmltd.net> Rob Stewart wrote:
From: "Peter Dimov" <pdimov@mmltd.net>
I don't view overloading for overloading's sake as improvement; there's nothing wrong with giving different names to different behaviors.
These functions do very nearly the same thing. That seems an ideal case for overloading.
This particular case is on the fence. One could think of the overloaded interface as a typesafe approximation of
status_return_flags status( path const & p, status_option_flags flags = status_option_default );
with follow_symlink being the only option flag at the moment.
OK. I'm missing your point, though.
My point was that altering behavior with response to a "flags" or "options" argument is an established idiom, and this case can be viewed as an application of that idiom, if one squints hard enough.
In general, though, excessive overloading should be avoided. My usual litmus
I agree wholeheartedly that "excessive overloading should be avoided." I don't see this as excessive overloading.
test for appropriate overloading is: can you tell what this does:
f( x, y );
without looking up the exact types of x and y.
You can never tell in C++. Is "f" a macro? What is the scope of the call? "f" is hardly a telling name, so how can one determine what f(x,y) does for any pair of arguments?
In the above, "f" is a placeholder for the actual function name.
All of those questions aside, how does this apply to the case before us?
It doesn't. It was an explanation of the general principles that guide me to look for compelling arguments in favor of overloading and reject it if there are none, rather than look for compelling arguments against overloading and reject it if there are any.