[v3] system_error, round one

[Benjamin Kosnik]

> - You have to use strerror_r() if available since some strings are 
> dynamically created.
> 
> - why has this class no explicit association with a locale?  It should 
> have.  strerror() and strerror_r() provide translated strings based on 
> the global locale
> 
> - if such a locale is added as for many other classes, then use 
> strerror_l() which is available in glibc and will be available in all 
> future POSIX systems.

Yes. There seems to be some intent to use locale bits, but no actual 
thought as to what the interface should look like.

> - you shouldn't hardcode the highest error number.  If you really need 
> that information use the _sys_nerr variable which most Unix systems 
> provide.

OK, thanks. I see sys_nerr, _sys_nerr in bits/sys_errlist.h, but no way 
to get at this info via a functional interface. Is this correct? I guess 
I can just deal with this at configure time.

One of the things I was wondering (besides all the XXX comments in the 
posted source...) was if I would have to create this as a GNU/generic 
type of thing, like the rest of locale. It seems like this is where this 
is all heading.

I am wondering if it may make more sense to just implement a revised 
version of this spec, since it seems pretty weak at the moment, and then 
  shoot back those implementation differences in paper form to the LWG 
pre-Toronto.

For the traits stuff, Howard nicely added rationale bits in gray under 
the impacted parts of the proposal. I see no similar thing for the 
system_error proposal, even though the differences between the revisions 
is quite substantial. Is there any place where the rationale for the 
evolution of this code was tracked?

In the future I would like very much if associated utility bits from big 
proposals get pulled out and submitted on their own. (Like unique_ptr 
for the rvalue bits, and system_error for the filesystem bits.)

The attached patch is unchanged, but just updated from the partial merge 
of Friday.

best,
benjamin


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p.20070515
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20070515/d48bd9bc/attachment.ksh>