"Iain K. Hanson" <iain.hanson@videonetworks.com> wrote in message news:1115224522.14534.633.camel@dev-ihanson.ct.uk.videonetworks.com...
On Wed, 2005-05-04 at 10:36 -0400, Rob Stewart wrote:
From: "Beman Dawes" <bdawes@acm.org>
How about this instead:
struct shallow_status_t { }; extern shallow_status_t shallow;
status_flag status(path const &); // follows status_flag status(path const &, shallow); // doesn't follow
I marginally prefer the separately named functions because behavioural differences to me say separate functions names whereas overloads imply semanticly the same but with different types.
That rationale is convincing enough for me.
(It occurred to me that including the term "symlink" is limiting since not all OSes have "symlinks" that have (at least partly) analogous concepts. That means naming the function "symlink_status" is similarly limiting.)
I think symlink is a fine name and whether an overload or separate function names the function returning info on a symlink is going to be meaningless on a platform that does not have the concept.
I'd prefer to think use of symlink_status() on a platform without symbolic linas ensuring that the code will be portable to other operating systems, and to future versions of the current operating system. As an aside, I read recently a description of the next version of Windows, and it sounded somewhat like they might be adding symbolic links. Hard to say, however, as it was a marketing rather than technical description. --Beman