Re: [boost] Filesystem Library mini-review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-01-04 10:55:24

At 09:12 AM 12/18/2002, Peter Dimov wrote:
 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >>
 >> How about these member functions (in addition to what()):
 >>
 >>     int         native_error() const { return m_sys_err; }
 >>      // Note: a value of 0 implies a library (rather than system) error
 >>
 >>     error_code  error() const { return m_err; }
 >>
 >>     const string & function() const;
 >>       // name of the function throwing the exception
 >
 >Could this be char const * function() const? It seems that if you can
 >return
 >a reference to a string, you can return a char const *? Or perhaps the
 >intent was to return a string by value.
 >
 >>     const path & path1() const; // argument 1 to function; may be 
empty()
 >>     const path & path2() const; // argument 2 to function; may be 
empty()
 >
 >What would the implications be if we changed these to return 'char const 
*'
 >or 'string' to eliminate the dependency on 'path'?

At first glance eliminating the dependency on path seems like a win, but 
I'm worried about the future.

I think there is at least some chance that path can be expanded to include 
the ability to handle wide character names. Perhaps add a set of 
constructors from wide strings, and add a set of access functions which 
return wide strings. Then code which catches filesystem_error might well 
prefer the current interface, because the wide versions of the path string 
representations could be accessed if desired.

OTOH, if we changed:

   const path & path1() const;

to:

   const char * path_string1() const;

we could always later add:

   const char * path_wstring1() const;

But it seems to me we are getting into kludge land. The internal 
implementation is likely to remain a path (even if we change to a pimpl 
implementation). We are only making the interface lighter, not the 
implementation.

What do others think?

--Beman