However, I think the caller might want to choose.

Why? Serious.

Sure; there's two main places in windows where front slashes don't work:

In most DOS commands
In Windows native file browsers

I actually run into this enough, that in my commercial application I provide the user with two 'Copy' options for popup menus on input and text widgets to provide copy/paste:

Copy as front slashes
Copy as back slashes

..This allows the user to take a highlighted path from execution logs, and copy/paste them into DOS windows as arguments to e.g. DIR and COPY commands and Windows file browsers. DOS tools only can handle backslashes because they use fronts as command line separators; e.g. COPY/XCOPY, MORE, TYPE, DIR, etc etc.

While the WIN32 API allows both, higher level software (DOS, native folder browsers) overloads fronts for other things, creating a conflict, and those situations might be relevant to an app's needs.

Arguably we should provide a way for fronts <-> backs for these and possibly other reasons, as users might not have std::string available (those embedded platforms that don't support STL/templates), and just because there's more than one possibility of return.

At very least we probably should /probably/ be consistent about what we return and document it, as returning a mix of slashes would I think be unexpected.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.