And furthermore this was in response to iostream working with std::string. The gist of it being, it's incomplete, non-orthogonal, and non-obvious in many areas.
Well, we all know how timely and completely compiler vendors are with respect to implementing the C++ standard. And the standard actually has to be published first, so that doesn't change the situation now or in the past.the second of which I agree with but will be fixed in the next standard
I guess it is once you've gotten used to it.(and is super trivial)
It demonstrates that the writers decided to pick and choose which standard types can be combined with other standard types using the standard operators.and the third of which doesn't make sense (are you saying streams are worse than printf because they only work with string?).
It's all right though, since you can create a template operator<< to print out all the maps and vectors and such like as you want. And so can I. But let's not try and integrate our code into one program afterwards.
Printing them out and using them to format stuff. That's unobvious.In addition, you complain about more trivial stuff like the extra effort needed to use some streams in unobvious ways
Once again, C++ gets a pass because C does the same thing., even though you have to jump through the same (or much more difficult) hoops with the printf style solution.
C++'s templates are such an unmitigated stream of crap, that it's really irrelevant how well this part of the language works with them compared to that one. And if you're talking about how you can say cout << my_imaginary_number_instance, why can't you write a function that takes a pointer to your object and uses printf.And yet, you failed to address the reason given for streams being better than C style i/o, which is that they work much better with generic code.
They're safer. Who cares. First of all, type safety isn't going to give you any performance benefits since I/O tends to be bound by... I/O.(They are also often safer.)
And secondly, am I to believe that the compiler will help catch errors? Well why don't you try diagnosing a run-time printf() error, versus a compile-time iostream error (and all the hundreds of overloaded << operators the compiler will spew out).[/quote]
printf("0x%08x\n", x)" to the equivalent "std::cout << std::hex << std::setfill('0') << std::setw(8) << x << std::dec << std::endl." I think I can almost see the variable I'm trying to print. (and I sure hope cout was in decimal mode before that). Domain-specific languages FTL.
Also, you might try some translation of your program's messages into another language sometime, particularly one that differs in its SVO order. Pretty easy to change a format string with an external tool, not so easy to reorder the linguistic puzzle.
If you would like more information, refer to the C++ FQA Lite and the section "Input/output via <iostream> and <cstdio>"
In fact, that's how Qt, a C++ toolkit, approaches this. And word is there is something similar available if you want to "boost" your programs.