Re: [Boost-users] Question about boost::filesystem::path

From: Daniel Krügler (dsp_at_[hidden])
Date: 2005-11-25 02:32:35

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