Re: [boost] [system] system_error first draft

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-29 11:05:13

"Gennaro Prota" <gennaro_prota_at_[hidden]> wrote in message 
news:njvt925vi49uk11gclqrj23ql76hbu3sip_at_4ax.com...
> On Sun, 25 Jun 2006 15:25:45 -0400, Beman Dawes <bdawes_at_[hidden]>
> wrote:

>>> Here are my "off the top of my head" remarks:
>>>
>>> * something I've remembered of when seeing the names "system_error",
>>> "error_code": why not "file_system"? (maybe this was already discussed
>>> in the filesystem library review, but I don't recall)
>
> I'm still curious about that (since filesystem was introduced in
> boost, actually).

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 
some examples.

> 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 seems to me (please correct me if I'm wrong) that this refers to
> the type actually used by the operating system, not to an integer type
> providing a mapping to numbers. Well, it could even by in turn a
> mapping but I don't see why casting in stone that it must be an
> integer. Though I don't know of any system which doesn't use numbers
> for that, I still think other types are perfectly reasonable.
>
> You know very well that if I return 0 from main, or call exit(0) it's
> the implementation responsibility to translate 0 to the
> implementation-defined form to indicate successful completion. Plan
> 9's exit() actually returns a string :) Then a POSIX compatibility
> environment (APE) is available that implements exit(int) -i.e.
> provides the mapping required by the C standard. This is just an
> example to show that _under the hood_ of the C implementation things
> can actually be different and require a mapping. Does the sentence
> above want what is under the hood or what the C or C++ implementation
> exposes?

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.

> My preferred name, FWIW, is still native_system_error[_type].

Seems too wordy to me.

>>> * please, don't "hardcode" the usage of std::string and std::wstring;
>>
>>When dealing directly with the operating system, it is hard to see how
>>to avoid that. Please be a bit more specific, and suggest alternatives.
>
> I didn't mean hardcoding character literals and such (not that I've
> noticed that in your code). I meant not using
> basic_string/string/wstring at all, because that creates unnecessary
> coupling with the string library and is a less flexible and generic<>
> approach than iostreams. I've thought a lot about this, and the more
> time elapses the more I get convinced. Let's consider, for instance,
> the case of std::bitset<>. What if I want my bitset represented as
>
>  ttftt    [t=true, f=false]
>
> instead of
>
>  11011
>
> And why not
>
>  xx0xx
>
> ? Of course to_string() cannot do that, unless one wants to add a
> pletora of extra parameters. The stream approach instead is locale
> aware and allows any kind of special formatting. And it is highly
> customizable. As soon as I can, I'll provide a little helper class to
> aid in customizing input and output of dynamic_bitset as indicated
> above. My example about ipv4 should make the point even clearer: in
> general there's no unique way to represent an object as a sequence of
> characters, and what we actually want when doing conversion to string
> is *formatting*. A sequence of characters is just a special form of
> textual representation.
>
> BTW, once inserters and extractors work correctly you can use
> lexical_cast<> for simple, raw, text conversion needs.
>
> With the iostream approach you have a clear separation between a) the
> class which contains the data b) the textual representation of those
> data c) a generic name, operator <<, or operator >> to connect them
> and convert to and from character representations.

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 noticing this is happening everywhere in the standard, including
>>> TR1, TR2 and one of the library issues about std::bitset<>; as James
>>> Kanze made me notice, there's no conceptual reason why strings and
>>> std::bitsets (or system_error, of fstreams) should know about each
>>> other: if one wants the "textual representation" of an object the
>>> idiom to use is operator<<, which is also a standard "name" suitable
>>> for generic programming; obtaining the textual representation is a
>>> matter of formatting and there's no reason why one should have e.g.
>>> to_string() rather than to_ber_encoding() or to_xml(). Not to speak of
>>> the fact that a conversion to string may require a locale object,
>>> which you automatically get if using a stream.
>>>
>>> Just to make an example: supposing one want to implement
>>> ipv4::to_string(), what should be done with octets whose value is less
>>> than 100 or less than 10?
>>>
>>> a) 192.168.0.10
>>> b) 192.168.0.010
>>> c) 192.168.000.010
>>> ....
>>>
>>> As you see, this is formatting.
>>>
>>> This is a Java design error that C++ should not repeat (think also of
>>> Java's hashCode() -that's not different from to_string(), actually; a
>>> class shouldn't know about strings more than it knows about hash
>>> codes)
>>
>>That is beyond the scope of anything I can deal with here. You need to
>>write a paper for the committee, identifying specific places in the
>>standard (or TR1/TR2) where you think that is happening, and where
>>possible suggest solutions to the problems you identify.
>
> Would a DR be suitable? I was specifically alluding, for instance to
> lib DR 434:
>
> <http://google.com/group/comp.std.c++/browse_thread/thread/188ddd204ebd67da/739035f50ae29ab8?#739035f50ae29ab8>
>
> and to
>
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1475.html#15>

It seems to me that a full paper, including the specific working paper 
changes you are suggesting would be more likely to succeed than a simple DR.

>>> * many constructors are not explicit; is that intentional?
>>
>>I'm not sure which constructors you are looking at. The only converting
>>constructor I see is already explicit.
>
> I was again looking at the paper, not at your code. I'm sure you
> istinctively used explicit where it made sense.

Please indicate the specific constructors. It is certainly possible that 
some that should be explicit aren't, and need to be changed.

Thanks,

--Beman