Reply to thread

Message: [QUOTE="Daniel, post: 5148080"] Inserting and extracting in a specific order doesn't fit well with internationalization, though. It should be possible to do nontrivial formatting with the standard input and output features of the language, but in practice most nontrivial formatting, e.g. formatting with 000's separators, formatting money, internationalization etc. is done by calling format methods on strings.As someone with an interest in json parsers, I note that even something as simple as the preferred json floating point output format, which is truncate trailing zeros after the decimal point, except the one immediately following the decimal point, cannot be accomplished with the floatfield support alone (that's also true for printf.) A comparison with printf and friends is probably not a great comparison, when designing << and >>, the author obviously had the C functions in mind, the limitations of floatfield are the same. >> has some disadvantages compared to the C function, ease of internationalization being one, and it's much slower! but it offers one huge advantage, overloading, which is the reason most people including myself use it. Of course overloading could have been achieved with a more sensibly designed io library. Other languages such as Java offer much better abstractions for input and output streams. A big reason incidentally why Java displaced much of C++ for data workflow server products, where byte streams in many, many different encodings have to coexist. C++ people are still struggling with getting unicode to work. Not to mention that COBOL had a better model for masked output, and that could have been considered prior art at the time. And how did they manage to make << >> so slow! << >> seems to be the counter example to the advice often heard here, don't optimize prematurely. If the original architecture is inherently slow, there are limits to what even a super optimizing compiler team can do with it. Best regards, Daniel [/QUOTE]

Verification