At 09:12 AM 12/18/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>>
>> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to