[filesystem] very minor request
Hi, I don't know if this has been discussed in the LWG but I'd like to make basic_path(const string_type& s); // (*) explicit. I'm right now working on the inspect tool, trying to cut down some of its dependencies. After eliminating boost::bind, which looks overkill to me in this case, I came upon a ironical situation: I modified the function contains_dot() to take a reference to path instead of a reference to string. The intent was to have a stricter type checking: bool contains_dot( /*std::string const& x */ path const & p) { return p.string().find( '.' ) != std::string::npos; } On the invoking code however, I forgot to remove ".string()", so I was still passing a string to it, except that the converting constructor (*) made everything compile anyway. As a result I was converting the path twice, from string and then again to string. This doesn't seem an unusual situation to me, especially when refactoring. What do you think? -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
I don't know if this has been discussed in the LWG but I'd like to make
basic_path(const string_type& s); // (*)
explicit.
Let's look at your example to see why it isn't explicit. Here is the signature: bool contains_dot( path const & p); Users will certainly expect the following to work: assert( contains_dot( "foo.bar" ) ); I maintain that they also will expect the following to work: std::string foo( "foo.bar" ); ... // much intervening code assert( contains_dot( foo ) ); I really don't think we want to force users to write: assert( contains_dot( path(foo) ) ); So the constructor can't be explicit. --Beman
On Wed, 02 Aug 2006 04:56:27 -0400, Beman Dawes <bdawes@acm.org> wrote:
I really don't think we want to force users to write:
assert( contains_dot( path(foo) ) );
Why not? Regardless of the example, I think we shouldn't blur the distinction between paths and strings, though the latter are perhaps the most common *representation* of the former. -- [ Gennaro Prota, C++ developer for hire ]
Gennaro Prota wrote:
On Wed, 02 Aug 2006 04:56:27 -0400, Beman Dawes <bdawes@acm.org> wrote:
I really don't think we want to force users to write:
assert( contains_dot( path(foo) ) );
Why not? Regardless of the example, I think we shouldn't blur the distinction between paths and strings, though the latter are perhaps the most common *representation* of the former.
That would imply the conversion from const char * should be explicit too. Users would have to write: assert( contains_dot( path("foo.bar") ) ); instead of: assert( contains_dot( "foo.bar" ) ); For simple, script-like programs that do a lot of file operations, that is asking a lot of the user. As far as I can remember, there has never been a complaint from any user regarding the converting constructors. Is there any reason other than a concern for design purity that leads you to want explicit constructors? --Beman
On Wed, 02 Aug 2006 17:21:10 -0400, Beman Dawes <bdawes@acm.org> wrote:
Gennaro Prota wrote:
Why not? Regardless of the example, I think we shouldn't blur the distinction between paths and strings, though the latter are perhaps the most common *representation* of the former.
That would imply the conversion from const char * should be explicit too. Users would have to write:
assert( contains_dot( path("foo.bar") ) );
instead of:
assert( contains_dot( "foo.bar" ) );
For simple, script-like programs that do a lot of file operations, that is asking a lot of the user.
Well, ideally multiple function calls dealing with *the same path* would use a common variable, as in path p("foo.bar"); call1( p ); ... call2( p ); etc. Also I imagine constructing from std::string or char array would be common when setting an initial directory; after that most calls would probably be to operator/() and other functions which are already string-aware: p/"subdir" would continue to work, for instance.
As far as I can remember, there has never been a complaint from any user regarding the converting constructors.
Is there any reason other than a concern for design purity that leads you to want explicit constructors?
Yes and no. My remark addressed only in part design purity, for the rest it was about a real situation where I let things happen in a way that was not intended: I didn't want a double conversion, it just triggered automatically, so to speak. This didn't cause any error or undefined behavior, but still was not intended. -- [ Gennaro Prota, C++ developer for hire ]
participants (2)
-
Beman Dawes -
Gennaro Prota