Question about boost::filesystem::path
I've just run into an interesting problem with boost::filesystem::path and thought I would raise it somewhere.
When I run the following code, compiled with MSVC7.1, on windows XP I get an exception thrown when calling some_path_function.
The exception is causes by boost::filesystem::path's implicit conversion constructor constructing a path from a string using the posix path matching rules. Obviously I can correct the problem by always using the native path checker argument, and that is fine, but the fact that this is an implicit conversion makes it hard to spot and I (and my colleagues) are not always that awake :).
So I suppose the question is a) can the default path checking function be changed in such a way that on windows platforms it validates the path using windows rules and on posix platforms using posix rules, or b) should the constructor at fault here be made explicit since it can really catch you out.
#include
Stewart Tootill wrote:
I've just run into an interesting problem with boost::filesystem::path and thought I would raise it somewhere.
When I run the following code, compiled with MSVC7.1, on windows XP I get an exception thrown when calling some_path_function.
The exception is causes by boost::filesystem::path's implicit conversion constructor constructing a path from a string using the posix path matching rules. Obviously I can correct the problem by always using the native path checker argument, and that is fine, but the fact that this is an implicit conversion makes it hard to spot and I (and my colleagues) are not always that awake :).
So I suppose the question is a) can the default path checking function be changed in such a way that on windows platforms it validates the path using windows rules and on posix platforms using posix rules, or b) should the constructor at fault here be made explicit since it can really catch you out.
Just by personal 0.02 EURO: I would stay away from proposal (a), because the primary "language" of boost::path is an abstracted path description language. That sounds very formal, but essentially that is the reason for the well-defined path grammar. Of course this grammar could have been written in a way, that has nothing to do with any currently existing path notation of any OS (at least at that moment...), but that wouldn't help either, because the "intermediate" language are character sequences, which erase this differences during compile-time. I personally use boost::path's c'tors always with some explicit checker, if I have externally provided input (UI, like some file-open-dialog), and the unchecked one only for abstract descriptions (which are much more seldom used). Concerning your proposal (b): I don't believe, that an explicit c'tor for strings would prevent any programmer to forget about the difference between native and portable path grammar, they would simply write path("bla") instead of "bla". To my opinion, the only thing that would help, would the removal of any string-based one-argument c'tor (i.e. force the user to define the grammar). Greetings from Bremen, Daniel
participants (2)
-
Daniel Krügler -
Stewart Tootill