Enrico Forestieri wrote: > On Fri, Nov 10, 2006 at 05:45:18PM +0100, Georg Baum wrote: >> Enrico Forestieri wrote: >> >> > I am going to shove in the attached. There's a small optimization with >> > respect to the previous version. >> >> Can you explain why you implemented two facets? I would expect only one >> (with ascii_num_put_facet as name, since it can only cope with pure >> ascii). > > Strictly speaking, only the odocstream_num_put_facet would be needed. > I used the ascii_num_put_facet in order to have a number formatted as a > string using the already existing facets for basic_string<char>::iterator > instead of rolling out my own versions.
I can understand that, but why do you not use std::num_put<char, std::basic_string<char>::iterator> directly? I really would prefer if odocstream_num_put_facet would be called ascii_num_put_facet, since that makes very clear that it can only deal with ASCII. For the same reason I would prefer to assert on fill < 0x80 instead of silently changing it to a space. I don't think that we are using a different fill character anywhere, but if somebody does that it is better to crash than to silently alter the result. Your current ascii_num_put_facet is only an implementation detail, so I'd like that to be hidden in the num_put method. > To tell you the truth, I even > considered using sprintf for that, but then I should had to appropriately > cope with the flags in the ios_base argument and take into account the > fill character. The way I did, the work is done by the stl and I have > to simply copy the result to the output wide stream. > > As regards the name, well, a number is represented by an ascii string > anyway, so I think I got the naming right, but I am open to suggestions. I don't think that numbers are always ASCII only. Other languages may have other representations that could be dealt with by an appropriate num_put_facet. Of course you are right that we don't need that. Georg
