Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-08-02 17:53:42


On Wed, 02 Aug 2006 17:21:10 -0400, Beman Dawes <bdawes_at_[hidden]>
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 ]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk