Beman,
Thanks for the clarifications - I thought I had followed the whole thread
but I had misunderstood and thought the thrust was to create a new path
representation -
on 1/6/03 1:51 PM, Beman Dawes at [EMAIL PROTECTED] wrote:
> The syntax, semantics, and about everything else about paths that
At 02:35 PM 1/5/2003, Sean Parent wrote:
>on 1/5/03 10:21 AM, Beman Dawes at [EMAIL PROTECTED] wrote:
>
>> I had a conversation with Bill Plauger, Howard Hinnant, and several
other
>> library implementors at the last C++ committee meeting, and we agreed
on
>> a possible approach to the conversio
on 1/5/03 10:21 AM, Beman Dawes at [EMAIL PROTECTED] wrote:
> I had a conversation with Bill Plauger, Howard Hinnant, and several other
> library implementors at the last C++ committee meeting, and we agreed on a
> possible approach to the conversion problem. Conversions between wide and
> narrow
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 10:02 AM 1/5/2003, Peter Dimov wrote:
>
> >That's an excellent point, and I'm glad that wide paths aren't
completely
> >out of the question!
>
> I had a conversation with Bill Plauger, Howard Hinnant, and several other
> library implementors at the las
At 10:02 AM 1/5/2003, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>>
>> 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 hand
From: "Beman Dawes" <[EMAIL PROTECTED]>
>
> 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.
That's an excellent poin
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
>>
>> e
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; }
>
>
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 11:50 AM 12/17/2002, Peter Dimov wrote:
>
> >std::cerr << translate_text(ex.error_str()) << std::endl;
>
> Um... Rather than fatten the interface to filesystem_exception further,
the
> code->string translation could be provided as a free function. That
At 11:50 AM 12/17/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>> At 10:18 AM 12/17/2002, Peter Dimov wrote:
>>
>> >The main problem is that I don't really know the answer. I can tell
you
>> >what doesn't work, but I don't know yet what works. :-)
>>
>> How about these memb
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 10:18 AM 12/17/2002, Peter Dimov wrote:
>
> >The main problem is that I don't really know the answer. I can tell you
> >what doesn't work, but I don't know yet what works. :-)
>
> How about these member functions (in addition to what()):
>
> int
At 10:18 AM 12/17/2002, Peter Dimov wrote:
>The main problem is that I don't really know the answer. I can tell you
>what doesn't work, but I don't know yet what works. :-)
How about these member functions (in addition to what()):
int native_error() const { return m_sys_err; }
//
At 12:42 PM 12/16/2002, Peter Dimov wrote:
>> I think that we also need to consider the problem of translating a
>> filesystem_error to a localized error message.
>
>In particular, consider this example of a what() string:
>
>File system error: move_file(): nonexistent, something_else: The system
>
From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Peter Dimov wrote:
> >>I think that we also need to consider the problem of translating a
> >>filesystem_error to a localized error message.
[...]
>
> Seems like there is quite a few alternatives:
>
> 1. Perform localization at the point where exception i
Peter Dimov wrote:
I think that we also need to consider the problem of translating a
filesystem_error to a localized error message.
In particular, consider this example of a what() string:
File system error: move_file(): nonexistent, something_else: The system
cannot find the file specified.
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Another comment.
I notice that the
"
symbol is not allowed in paths, (as you says previously). But
'
is allowed. Should it?
- Volodya
On Monday, December 16, 2002, at 06:41 PM, Beman Dawes wrote:
At 12:12 PM 12/16/2002, Glen Knowles wrote:
>I think what he might be asking for is something like:
>
>make /my/full/path relative to /my/base/dir produces ../../full/path
Ah... Thanks...
The practical problem is determining if two
> I think that we also need to consider the problem of translating a
> filesystem_error to a localized error message.
In particular, consider this example of a what() string:
File system error: move_file(): nonexistent, something_else: The system
cannot find the file specified.
generated by
At 12:12 PM 12/16/2002, Glen Knowles wrote:
>From: Beman Dawes [mailto:[EMAIL PROTECTED]]
>
>> > While doing so one missing function
>> >came to my mind (or did I just overlook it). It came to my mind that
>> >some time in the future I might want to create a relative path, given
a
>> >"complete"
At 11:58 AM 12/16/2002, David Abrahams wrote:
>Beman Dawes <[EMAIL PROTECTED]> writes:
>
>> At 03:05 AM 12/16/2002, Vladimir Prus wrote:
>>
>> >Beman Dawes wrote:
>> >> A large number of changes to the Filesystem Library have been
>> committed >> to the CVS main trunk.
>> >
>> >Hi Beman,
>> >
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 08:35 AM 12/16/2002, Peter Dimov wrote:
>
> >To clarify: the current situation requires the filesystem library to
> >interpret system-specific error codes. Adopting the POSIX values would
> >eliminate that need on some important platforms, with no dow
Title: RE: [boost] Filesystem Library mini-review
From: Beman Dawes [mailto:[EMAIL PROTECTED]]
> > While doing so one missing function
> >came to my mind (or did I just overlook it). It came to my mind that
> >some time in the future I might want to create a rela
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 03:05 AM 12/16/2002, Vladimir Prus wrote:
>
> >Beman Dawes wrote:
> >> A large number of changes to the Filesystem Library have been
> committed >> to the CVS main trunk.
> >
> >Hi Beman,
> >
> >I've some comments:
> >
> >1. The name 'root_direc
At 12:34 PM 12/13/2002, Kevin Lynch wrote:
>Iain K.Hanson wrote:
>>> We already have a standard
>>>portable
>>>error
>>> >scheme. Why reinvent the wheel? Will we do any better?
>>>
>>>We might. The POSIX errno scheme doesn't seem all that strong to me.
>>
>>
>> Agreed. I've given a fair ammount of
At 08:35 AM 12/16/2002, Peter Dimov wrote:
>To clarify: the current situation requires the filesystem library to
>interpret system-specific error codes. Adopting the POSIX values would
>eliminate that need on some important platforms, with no downsides.
Just to be sure that I understand your prop
At 06:56 AM 12/16/2002, Matthias Troyer wrote:
>
>Beman Dawes wrote:
>> A large number of changes to the Filesystem Library have been committed
>> to the CVS main trunk.
>
>Hi Beman,
>
>In a couple of hours I changed all our codes that depend on
>boost::filesystem. Although I did not perform a thro
At 03:05 AM 12/16/2002, Vladimir Prus wrote:
>Beman Dawes wrote:
>> A large number of changes to the Filesystem Library have been committed
>> to the CVS main trunk.
>
>Hi Beman,
>
>I've some comments:
>
>1. The name 'root_directory' is confusing for me. 'directory' implies
>you can stick an
From: "Peter Dimov" <[EMAIL PROTECTED]>
I am replying to my own post in order to clarify some points.
> From: "Beman Dawes" <[EMAIL PROTECTED]>
> > Would you see any value in providing aliases with names that map more
> > closely to the POSIX names?
> >
> > For example, instead of:
> >
> >
Beman Dawes wrote:
A large number of changes to the Filesystem Library have been committed
to the CVS main trunk.
Hi Beman,
In a couple of hours I changed all our codes that depend on
boost::filesystem. Although I did not perform a through review, I had
no problem using the library. I found
Beman Dawes wrote:
> A large number of changes to the Filesystem Library have been committed
> to the CVS main trunk.
Hi Beman,
I've some comments:
1. The name 'root_directory' is confusing for me. 'directory' implies
you can stick anywhere dir there, whilie only "/" is allowed.
Unfortu
Iain K.Hanson wrote:
We already have a standard
portable
error
>scheme. Why reinvent the wheel? Will we do any better?
We might. The POSIX errno scheme doesn't seem all that strong to me.
Agreed. I've given a fair ammount of though to this over the past year
( whilst working on sockets). The
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Beman Dawes
> Sent: 13 December 2002 15:31
> To: Boost mailing list; Boost mailing list
> Subject: Re: [boost] Filesystem Library mini-review
>
>
> At 08:19 AM 12
From: "Beman Dawes" <[EMAIL PROTECTED]>
> At 08:19 AM 12/13/2002, Peter Dimov wrote:
>
> >From: "Beman Dawes" <[EMAIL PROTECTED]>
> >>
> >> Part of the problem is that there is no guarantee that the macros will
> be
> >> available in .
> >
> >Yes, that's true in theory, but in practice, is th
At 08:19 AM 12/13/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>>
>> Part of the problem is that there is no guarantee that the macros will
be
>> available in .
>
>Yes, that's true in theory, but in practice, is there a platform that
>doesn't have the macros in ?
It is messi
From: "Beman Dawes" <[EMAIL PROTECTED]>
>
> Part of the problem is that there is no guarantee that the macros will be
> available in .
Yes, that's true in theory, but in practice, is there a platform that
doesn't have the macros in ?
Note that there are two issues here. First, whether the portabl
At 04:19 PM 12/12/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>>
>> The alternative I considered was to try to map the system specific code
>> into a POSIX errno code. However, the macros seemed messy for C++.
>
>POSIX errno codes were what I meant, yes. On a POSIX implementa
From: "Beman Dawes" <[EMAIL PROTECTED]>
>
> The alternative I considered was to try to map the system specific code
> into a POSIX errno code. However, the macros seemed messy for C++.
POSIX errno codes were what I meant, yes. On a POSIX implementation there
would be no mapping. On Win32, you can
At 02:14 PM 12/12/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>> The exception class has been given additional functionality to provide
a
>> portable error code. Etc, etc.
>
>Q: have you considered using standard errno codes as the portable error
>code?
If I understand your
From: "Beman Dawes" <[EMAIL PROTECTED]>
> The exception class has been given additional functionality to provide a
> portable error code. Etc, etc.
Q: have you considered using standard errno codes as the portable error
code?
___
Unsubscribe & other cha
A large number of changes to the Filesystem Library have been committed to
the CVS main trunk.
These changes close most of the issues which came up during the formal
review. Issues still outstanding are listed in the "Do-list" which is part
of the documentation.
While the core design of the li
40 matches
Mail list logo
