"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message news:njvt925vi49uk11gclqrj23ql76hbu3sip@4ax.com...
On Sun, 25 Jun 2006 15:25:45 -0400, Beman Dawes <bdawes@acm.org> 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:
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