From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2006-07-05 12:59:21
apologies for the very late reply. I postponed it and then always
>AFAICR, the question never came up. I can't remember why I started calling
>it filesystem rather than file_system, but suspect I was influenced by other
>material I read at the time. Try googling for "filesystem", and you can see
Seen. Both forms are common; at the moment, though, Google's search
results for "file system" (in quotes) are almost twice as much those
for filesystem (about 60,000,000 vs. 30,000,000). Any hope for it to
>> That said, the wording at the url you provide still perplexes me:
>> Type system_error_type [now sysno_t] is the implementation-defined
>> type used by the operating system to report error codes.
>It is whatever the operating system's API uses to report errors. If there is
>a layer between the C++ program and the operating system, like cygwin, it is
>what that middle layer's API exposes.
Ok. So the wording needs some tweak (I know it is difficult to do in
standardese, sorry for that).
>> My preferred name, FWIW, is still native_system_error[_type].
>Seems too wordy to me.
Now that you told about middle layers being considered, what about
"system_api_error"? Or should it necessarily have _t/_type at the end?
>I'm not seeing how this applies to class error code (which does not use
>strings at all), unless you are suggesting that stream inserters and
>extractors be provided.
I'm a bit lost in all the renaming we have done so far :) Anyhow, at
the url you provided:
the class system_error has the following constructor:
system_error(const std::string & what_arg, error_code ec);
>>>> [snipped suggestion to file a full paper]
>>>I'm not sure which constructors you are looking at. The only converting
>>>constructor I see is already explicit.
As I said I was only looking at the online document; there
is not declared explicit.
-- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk