Boost logo

Boost :

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


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