 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
peter_k
Guest
|
 Posted: Sat Nov 26, 2005 3:07 pm Post subject: Text labels... |
 |
|
Hi
I was programming a lot in C
When i wanted to make text label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
But this method works only when i use stdio functions... Now i have
started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display few
variables in one line)?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Alec Ross
Guest
|
| Posted: Sun Nov 27, 2005 4:03 am Post subject: Re: Text labels... |
|
|
In article <1132957160.304033.216360 (AT) g14g2000cwa (DOT) googlegroups.com>,
peter_k <asm3 (AT) o2 (DOT) pl> writes
| Quote: | Hi
I was programming a lot in C
When i wanted to make text label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
But this method works only when i use stdio functions... Now i have
started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display few
variables in one line)?
|
#include <iostream>
#include <string>
int main()
{
const std::string result_label("Result of the program = ");
int result; // for example
// ...
result = 42;
std::cout << result_label << result
// more similar variable entries, if required
<< std::endl; // newline, if wanted
}
--
Alec Ross
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Sun Nov 27, 2005 5:49 pm Post subject: Re: Text labels... |
|
|
peter_k wrote:
| Quote: | Hi
I was programming a lot in C
When i wanted to make text label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
But this method works only when i use stdio functions... Now i have
started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display few
variables in one line)?
|
I suggest you consider using a C++ replacement of printf like
boost.format ([url]http://boost.org/libs/format/doc/format.html)[/url]. With that
library, you code would become:
#define MY_PROGRAM_RESULTS
boost::format("Result of the program = %dn")
std::cout << MY_PROGRAM_RESULTS % result;
HTH,
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
peter steiner
Guest
|
| Posted: Sun Nov 27, 2005 9:57 pm Post subject: Re: Text labels... |
|
|
peter_k wrote:
| Quote: | Hi
I was programming a lot in C
When i wanted to make text label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
But this method works only when i use stdio functions... Now i have
started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display few
variables in one line)?
|
the above example translates directly into streams:
#define MY_PROGRAM_RESULTS "Result of the program = "
std::cout << MY_PROGRAM_RESULTS << result << std::endl;
if i understand you correctly, you are trying to define format strings
with more than one variable:
#define MORE_COMPLICATED_FORMAT_STR = "%d plus %d equals %dn"
printf(MORE_COMPLICATED_FORMAT_STR, 5, 5, 10);
as ostream objects require the variables to be streamed between text
literals you cannot easily forward define the above constant without
resorting to more macro expansion.
the following would work...
#define MORE_COMPLICATED_FORMAT_STR(v1, v2, v3) v1 << " plus " << v2 <<
" equals " << v3 << std::endl;
std::cout << MORE_COMPLICATED_FORMAT_STR(5, 5, 10);
.... but feels pretty awkward.
i prefer the C++ variant of printf in boost::format to streams in
printing formatted text, which provides printf like format strings in a
typesafe manner.
with this you could still forward declare a format constant:
#define MORE_COMPLICATED_FORMAT_STR = "%d plus %d equals %dn"
std::cout << boost::format(MORE_COMPLICATED_FORMAT_STR) % 5 % 5 % 10 <<
std::endl;
or better:
const boost::format MORE_COMPLICATED_FORMAT("%d plus %d equals %dn");
std::cout << boost::format(MORE_COMPLICATED_FORMAT) % 5 % 5 % 5 <<
std::endl;
see http://boost.org/libs/format/
-- peter
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Greg Herlihy
Guest
|
| Posted: Mon Nov 28, 2005 8:25 am Post subject: Re: Text labels... |
|
|
peter_k wrote:
| Quote: | Hi
I was programming a lot in C
When i wanted to make text label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
But this method works only when i use stdio functions... Now i have
started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display few
variables in one line)?
|
The text labels themselves should be declared as constants.
const char kProgramResultsStr[] = "Result of the program =";
And the string to display could be assembled in place:
std::cout << kProgramResultsStr << " " << result << std::endl;
Or as an alternative, a series of template functions could assemble the
string from a list of parameters:
#include
using std::cout;
using std::endl;
template <class T1>
inline void PrintLine(T1 t1)
{
cout << t1 << endl;
}
template
inline void PrintLine(T1 t1, T2 t2)
{
cout << t1 << " " << t2 << endl;
}
template
inline void PrintLine(T1 t1, T2 t2, T3 t3)
{
cout << t1 << " " << t2 << " " << t3 << endl;
}
And so forth, for however many parameters are likely to be passed. Here
is an example of PrintLine in use:
const char kProgramResultsStr[] = "Program result is:";
int main()
{
...
PrintLine( kProgramResultsStr, 13);
}
Output:
Program result is 13
In general, it is a good idea to replace C style macros with C++
constants and inline functions wherever it is possible to do so.
Greg
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Mon Nov 28, 2005 4:25 pm Post subject: Re: Text labels... |
|
|
peter_k wrote:
| Quote: | I was programming a lot in C When i wanted to make text label
i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
|
Why? This seems like extra maintenance work, for no advantage.
| Quote: | But this method works only when i use stdio functions... Now i
have started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display
few variables in one line)?
|
I'm not sure what you mean be "store text labels". In C++,
you'd simply write:
output << "Result of the program = " << result << std::endl ;
It has it's drawbacks, but it's still a good deal more readable
and maintainable than printf.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu (See
Guest
|
| Posted: Tue Nov 29, 2005 10:26 am Post subject: Re: Text labels... |
|
|
kanze wrote:
| Quote: | peter_k wrote:
I was programming a lot in C When i wanted to make text label
i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
Why? This seems like extra maintenance work, for no advantage.
|
The obvious advantage is that now code and data can be separated from
presentation, a very desirable feature in any application, and a must in
applications that supports skinning or internationalization.
| Quote: | But this method works only when i use stdio functions... Now i
have started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display
few variables in one line)?
I'm not sure what you mean be "store text labels". In C++,
you'd simply write:
output << "Result of the program = " << result << std::endl ;
It has it's drawbacks, but it's still a good deal more readable
and maintainable than printf.
|
Yuck. Readable? Maintainable? Bump the number of variables a bit and
let's talk then.
If I could turn the time back I'd strive to make sure the C++ streams
were better designed. As things stand now, C++ makes two offers when it
comes to formatted I/O - one that's as dangerous as an loose Great Dane
in a porcelain boutique, and one that's as ugly, inefficient, and
impractical as a worn-out rental car.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Peter Kümmel
Guest
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Wed Nov 30, 2005 11:49 am Post subject: Re: Text labels... |
|
|
Andrei Alexandrescu (See Website For Email) wrote:
| Quote: | kanze wrote:
peter_k wrote:
I was programming a lot in C When i wanted to make text
label i was using something like:
#define MY_PROGRAM_RESULTS "Result of the program = %dn"
printf(MY_PROGRAM_RESULTS, result);
Why? This seems like extra maintenance work, for no
advantage.
The obvious advantage is that now code and data can be
separated from presentation, a very desirable feature in any
application, and a must in applications that supports skinning
or internationalization.
|
I am questioning the wisdom of putting it in #define's.
More generally, I wonder about putting it in a separate file, as
text. I'm not too sure about skinning, but it doesn't really
work for internationalization; there are too many subtle
differences between the way languages work. For handling
different languages, at least if you are trying to achieve
idiomatic expression in each language, you really need a
separate dynamic object for each language, handling the
grammatical differences.
| Quote: | But this method works only when i use stdio functions... Now
i have started using iostream cout<< and cin>> functions...
In what way should i store text labels (if i want to display
few variables in one line)?
I'm not sure what you mean be "store text labels". In C++,
you'd simply write:
output << "Result of the program = " << result << std::endl ;
It has it's drawbacks, but it's still a good deal more
readable and maintainable than printf.
Yuck. Readable? Maintainable? Bump the number of variables a
bit and let's talk then.
|
Require any special formatting, and let's talk.
Putting the formatting information in the text string is *not* a
good idea. How many times have you had to track down wierd
errors in only one linguistic version, simply because the
translator had accidentally changed a %d into a %s. (And that's
the nice case, because you'd normally get a core dump
immediately.)
| Quote: | If I could turn the time back I'd strive to make sure the C++
streams were better designed.
|
Just about everything can be improved; C++ streams are no
exception. (There's also the fact that no one solution will
ever be best for everything.) C++ streams have one advantage
over most other solutions I've seen: they separate the
formatting of the individual parameters (which should depend on
the semantics of the parameter, and not the text) from the text.
Correctly used, they also support logical mark-up, with
manipulators like "currency" or "percentage", rather than
specifying the physical mark-up (e.g. precision) in each output
statement.
Those are important advantages. I'd like to see the actual text
in one block, but that's less important. When
internationalization is considered, I'm not even sure how
possible it is -- when you're trying to match number, gender,
case and class for nouns, adjectives, and verbs, almost every
word becomes a parameter, and every parameter would be a
conditional expression or a function call. With a printf-like
format, you end up with "%s %s %s %s %s" as the format.
| Quote: | As things stand now, C++ makes two offers when it comes to
formatted I/O - one that's as dangerous as an loose Great Dane
in a porcelain boutique, and one that's as ugly, inefficient,
and impractical as a worn-out rental car.
|
Well, Boost has a boost::format. If they'd just do something
about using '%' for insertion, it would seem to provide a good
answer; I believe that it *does* support manipulators, for
example, and allows positional specifications without the
mysterious format specifiers that no one understands. (I like
using a named function for insertion of parameters, but your
suggestion of operator()() sounds like a good compromize, for
those who find named functions too heavy.)
In the past, I also implemented something similar -- my
implementation actually supported everything in C90 printf, plus
the Open System positional parameter specifiers. (At the time,
I'd just come from C, and printf seemed natural. Just shows you
how much C deforms.) It's still in my source tree, but I refuse
to do any further work on it, *because* for simple things, the
standard C++ iostream is quite sufficient, and for more
complicated things, like using logical markup, it is superior.
The one place something along the lines of printf formatting is
good is for formatting tables, where you want to align columns.
And there, something like Basic's PRINT USING is even better; in
fact, when I have to format tables, I first write out the
formats in a PRINT USING format, and then convert them to
whatever I'm using.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu (See
Guest
|
| Posted: Thu Dec 01, 2005 3:04 am Post subject: Re: Text labels... |
|
|
kanze wrote:
| Quote: | Andrei Alexandrescu (See Website For Email) wrote:
The obvious advantage is that now code and data can be
separated from presentation, a very desirable feature in any
application, and a must in applications that supports skinning
or internationalization.
I am questioning the wisdom of putting it in #define's.
|
Fine; would const char[] make a difference?
| Quote: | More generally, I wonder about putting it in a separate file, as
text. I'm not too sure about skinning, but it doesn't really
work for internationalization; there are too many subtle
differences between the way languages work. For handling
different languages, at least if you are trying to achieve
idiomatic expression in each language, you really need a
separate dynamic object for each language, handling the
grammatical differences.
|
It has worked systematically well (after, of course, you add positional
parameters which are a must) for a large number of successful applications.
| Quote: | I'm not sure what you mean be "store text labels". In C++,
you'd simply write:
output << "Result of the program = " << result << std::endl ;
It has it's drawbacks, but it's still a good deal more
readable and maintainable than printf.
Yuck. Readable? Maintainable? Bump the number of variables a
bit and let's talk then.
Require any special formatting, and let's talk.
|
The naive customization mechanism allowed by iostreams by overloading
the shift operators does very little to overcome iostreams' huge
shortcomings. Honest, I haven't seen code that takes iostreams seriously
except in cutesy articles or book sections intended for beginners.
| Quote: | Putting the formatting information in the text string is *not* a
good idea.
|
That's what a great formatting engine (www.stringtemplate.org) does,
according to a best-award-nominated paper at WW2004
([url]http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)[/url].
| Quote: | How many times have you had to track down wierd
errors in only one linguistic version, simply because the
translator had accidentally changed a %d into a %s. (And that's
the nice case, because you'd normally get a core dump
immediately.)
|
That is a problem inherent with printf's safety, which I did mention as
a major disadvantage, not with the general idea of separating formatting
from data and code. C++'s I/O streams are a major step back because they
teach - with cute examples - beginners how to do things exactly wrong.
Worse, they've also had a solid argument going for them: "look! printf
is so unsafe! we can do it so safely!"
Same thing happened to C's macros, which are so bad, they unjustly
compromised the idea of macros in general.
| Quote: | If I could turn the time back I'd strive to make sure the C++
streams were better designed.
Just about everything can be improved; C++ streams are no
exception. (There's also the fact that no one solution will
ever be best for everything.)
|
Of course everything can; your statement brings nothing new to the table
as it's a truism. What I'm saying is that iostreams so bad, that if I
could go back to the past, I'd spend time designing iostreams instead of
chasing college girls. I mean, iostreams are *THAT BAD*.  )
| Quote: | C++ streams have one advantage
over most other solutions I've seen: they separate the
formatting of the individual parameters (which should depend on
the semantics of the parameter, and not the text) from the text.
Correctly used, they also support logical mark-up, with
manipulators like "currency" or "percentage", rather than
specifying the physical mark-up (e.g. precision) in each output
statement.
|
C++ streams were also terribly exception-unsafe last time I checked,
meaning that if you set some flags and then threw an exception, the
flags would undesirably persist.
Anyway, to substantiate the advantage you mention, could you please
bring a few concrete examples (including mock-up code) that we can discuss?
| Quote: | Those are important advantages. I'd like to see the actual text
in one block, but that's less important. When
internationalization is considered, I'm not even sure how
possible it is -- when you're trying to match number, gender,
case and class for nouns, adjectives, and verbs, almost every
word becomes a parameter, and every parameter would be a
conditional expression or a function call. With a printf-like
format, you end up with "%s %s %s %s %s" as the format.
|
It has been done successfully. What you're saying sounds like, "the
general problem sounds quite complicated. Therefore I'll go for a
non-solution that is so obviously wrong, and that dismisses any attempt
at a solution so vigorously, it sidesteps the entire issue."
| Quote: | As things stand now, C++ makes two offers when it comes to
formatted I/O - one that's as dangerous as an loose Great Dane
in a porcelain boutique, and one that's as ugly, inefficient,
and impractical as a worn-out rental car.
Well, Boost has a boost::format. If they'd just do something
about using '%' for insertion, it would seem to provide a good
answer; I believe that it *does* support manipulators, for
example, and allows positional specifications without the
mysterious format specifiers that no one understands.
|
I have to insert a comment here. Without exception, at *every* shop I've
ever been to, there was one thing that nobody had problems with, and
that was: format strings. People didn't understand references,
templates, classes, virtual functions, and of course iostream
manipulators, but really *everybody* knows format strings. I've been
*laughed* at in New York City back in 1998 when I mentioned "the arcane
formatting strings that nobody understands" in a meeting. Since then
I've been more cautions when asking about the subject, and indeed:
people seem to be very apt at understanding format strings. I don't know
why. They seem to be less inclined to understand iostream manipulators.
I don't know why.
| Quote: | (I like
using a named function for insertion of parameters, but your
suggestion of operator()() sounds like a good compromize, for
those who find named functions too heavy.)
|
Such a solution should have been in the standard, sigh.
| Quote: | In the past, I also implemented something similar -- my
implementation actually supported everything in C90 printf, plus
the Open System positional parameter specifiers. (At the time,
I'd just come from C, and printf seemed natural. Just shows you
how much C deforms.)
|
It might also show how much iostreams deform ).
| Quote: | It's still in my source tree, but I refuse
to do any further work on it, *because* for simple things, the
standard C++ iostream is quite sufficient, and for more
complicated things, like using logical markup, it is superior.
|
Please explain the "logical markup" thing, thanks.
My current belief is that iostreams stand there as a scar on the
otherwise nice C++ landscape, close in ugliness to two-phase lookup,
export, and "<" and ">" as nested parens.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Thu Dec 01, 2005 4:32 pm Post subject: Re: Text labels... |
|
|
Andrei Alexandrescu (See Website For Email) wrote:
| Quote: | kanze wrote:
Andrei Alexandrescu (See Website For Email) wrote:
The obvious advantage is that now code and data can be
separated from presentation, a very desirable feature in any
application, and a must in applications that supports
skinning or internationalization.
I am questioning the wisdom of putting it in #define's.
Fine; would const char[] make a difference?
|
It's a maintenance nightmare as soon as you separate the text
from the place where it is being used.
| Quote: | More generally, I wonder about putting it in a separate
file, as text. I'm not too sure about skinning, but it
doesn't really work for internationalization; there are too
many subtle differences between the way languages work. For
handling different languages, at least if you are trying to
achieve idiomatic expression in each language, you really
need a separate dynamic object for each language, handling
the grammatical differences.
It has worked systematically well (after, of course, you add
positional parameters which are a must) for a large number of
successful applications.
|
Well, I've yet to see an application which works really well
anywhere but in the locale where it was developped in. I find
that I (and most of my collegues) have to turn the local
messages off, because the French is incomprehensible to a
Frenchman.
It's largely a question of quality, I think. You can only get
to a certain level using printf strings with positional
parameters. I've used it in the past, and we've managed to
create messages that were acceptable, but nothing more. *And*
we were developping in parallel in the two languages involved
(German and English, at the time) -- we'd consider the
formulation of the message in both languages at the start, and
were not trying to translate existing text.
| Quote: | I'm not sure what you mean be "store text labels". In C++,
you'd simply write:
output << "Result of the program = " << result << std::endl ;
It has it's drawbacks, but it's still a good deal more
readable and maintainable than printf.
Yuck. Readable? Maintainable? Bump the number of variables a
bit and let's talk then.
Require any special formatting, and let's talk.
The naive customization mechanism allowed by iostreams by
overloading the shift operators does very little to overcome
iostreams' huge shortcomings. Honest, I haven't seen code
that takes iostreams seriously except in cutesy articles or
book sections intended for beginners.
|
I use it for some extremely complex jobs.
| Quote: | Putting the formatting information in the text string is
*not* a good idea.
That's what a great formatting engine (www.stringtemplate.org)
does, according to a best-award-nominated paper at WW2004
([url]http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf)[/url].
|
The context is slightly different. I can see presentation
managed by templates. But even then: encoding in the text
string the fact that the code uses a double to store the value
is a good idea?
| Quote: | How many times have you had to track down wierd errors in
only one linguistic version, simply because the translator
had accidentally changed a %d into a %s. (And that's the
nice case, because you'd normally get a core dump
immediately.)
That is a problem inherent with printf's safety, which I did
mention as a major disadvantage, not with the general idea of
separating formatting from data and code. C++'s I/O streams
are a major step back because they teach - with cute examples
- beginners how to do things exactly wrong. Worse, they've
also had a solid argument going for them: "look! printf is so
unsafe! we can do it so safely!"
|
Yes. There are (officially) only two solutions, and one isn't
really usable in serious code:-).
I doubt that iostream's are the definitive ultimate solution,
but I'd like to see some concrete alternatives. Which don't
encode the internal data type in the format string. Which
provide for encoding things like the precision outside of the
text as well -- how much precision is significant depends on the
algorithm, not the skin.
| Quote: | Same thing happened to C's macros, which are so bad, they
unjustly compromised the idea of macros in general.
|
I think there's a name for that -- creating something especially
bad so that your solution will look good. For a long time, I
was convinced that MS-DOS was a product of some Unix fans, who
needed something which would make primitive Unix look good.
In this case, printf preceded iostream, so you can't accuse the
iostream supporters of creating it just to make iostream seem
good.
I will agree with you that there are problems with the basic IO
stream idiom. While the formatting information doesn't belong
in the text stream, there are more than a few contexts where it
is desirable to have the text as a single block. At the
extreme, of course, for large scale output like web pages and
graphic applications, we want the entire presentation in a
single block -- a template, in sum. IOstream (and printf) are
only appropriate for streaming output (and streaming output is
becoming less and less important).
| Quote: | If I could turn the time back I'd strive to make sure the
C++ streams were better designed.
Just about everything can be improved; C++ streams are no
exception. (There's also the fact that no one solution will
ever be best for everything.)
Of course everything can; your statement brings nothing new to
the table as it's a truism.
|
But it is simply a generalization of your statement. If I were
defining C++ today (without the restrictions of backward
compatibility), I'd certainly try to define something better
than iostreams. I'd also try to define a better declaration
syntax, and more readable meta-programming facilities, and...
It's a truist that if I/you could turn the time back, I/you
would strive to make sure that X were better designed. For
practically all X.
| Quote: | What I'm saying is that iostreams so bad, that if I could go
back to the past, I'd spend time designing iostreams instead
of chasing college girls.
|
Now I wonder about you:-).
| Quote: | I mean, iostreams are *THAT BAD*. )
|
The C++ declaration syntax is much worse. All of the undefined
behavior we have at the drop of a hat is much worse.
The classical iostream addressed a simple problem. They are
perhaps a little more complex that is needed for that problem,
but they get the job done. It's clear that if the problem they
address is not your problem, then they aren't a good solution.
As they are the only "safe" IO in C++, they do get used for a
lot of things they weren't designed for, and that can end up
being a problem.
| Quote: | C++ streams have one advantage over most other solutions
I've seen: they separate the formatting of the individual
parameters (which should depend on the semantics of the
parameter, and not the text) from the text. Correctly used,
they also support logical mark-up, with manipulators like
"currency" or "percentage", rather than specifying the
physical mark-up (e.g. precision) in each output statement.
C++ streams were also terribly exception-unsafe last time I
checked, meaning that if you set some flags and then threw an
exception, the flags would undesirably persist.
|
I guess you don't use them the way I do. Which is strange; I
was sure that you'd heard of RAII. My manipulators restore the
flags at the end of the full expression. Or whenever an
exception is raised.
| Quote: | Anyway, to substantiate the advantage you mention, could you
please bring a few concrete examples (including mock-up code)
that we can discuss?
|
That would require more work than I've time for right now (and
probably more space than the moderators would like in a single
posting). But do you really question the advantages of logical
mark-up rather than physical? I thought that it was an
acknowledged fact that logical mark-up was preferrable. If
you're writing a Web page, you don't say that you want to indent
the next paragraph 1.3cm; you say that it is class="x", and
somewhere in a separate style sheet, you define that paragraphs
of class "x" are indented 1.3cm. Iostream manipulators,
correctly used, are exactly like class tags in HTML.
| Quote: | Those are important advantages. I'd like to see the actual
text in one block, but that's less important. When
internationalization is considered, I'm not even sure how
possible it is -- when you're trying to match number,
gender, case and class for nouns, adjectives, and verbs,
almost every word becomes a parameter, and every parameter
would be a conditional expression or a function call. With
a printf-like format, you end up with "%s %s %s %s %s" as
the format.
It has been done successfully. What you're saying sounds
like, "the general problem sounds quite complicated.
Therefore I'll go for a non-solution that is so obviously
wrong, and that dismisses any attempt at a solution so
vigorously, it sidesteps the entire issue."
|
What I'm saying is that the general problem *is* very
complicated. It's a problem I'm intimely familiar with; I work
in multilingual environments most of the time. And as I said
before, the internationalization efforts of most products are a
joke. (The few exceptions do make extensive use of DLL's.)
What I'm really trying to say with my intentionally provocative
statements, though, is that the problem really isn't well
defined, and that there may be several different problems
involved, requiring different solutions. And that for some
problems, iostream is a very good solution. And that you can't
say even that much for printf.
What I would like to see is a more precise definition of the
exact problem (or problems). And not just another "adaption" of
printf. I've got an adaption of printf which works quite well.
For an adaption of printf -- it fully supports *all* of the
formatting options of printf, and offers extensions to make it
simple for user defined types to define their own formatting
options. I first wrote it well over ten years ago, when I
thought that printf formatting was cool. It's been quite some
time since I've used it, however -- in the uses I have, either
iostream's does the job better, or (all too frequently) neither
does an acceptable job, and I have to write something special.
| Quote: | As things stand now, C++ makes two offers when it comes to
formatted I/O - one that's as dangerous as an loose Great
Dane in a porcelain boutique, and one that's as ugly,
inefficient, and impractical as a worn-out rental car.
Well, Boost has a boost::format. If they'd just do
something about using '%' for insertion, it would seem to
provide a good answer; I believe that it *does* support
manipulators, for example, and allows positional
specifications without the mysterious format specifiers that
no one understands.
I have to insert a comment here. Without exception, at *every*
shop I've ever been to, there was one thing that nobody had
problems with, and that was: format strings. People didn't
understand references, templates, classes, virtual functions,
and of course iostream manipulators, but really *everybody*
knows format strings.
|
Sounds like they have extensive experience with C .
| Quote: | I've been *laughed* at in New York City back in 1998 when I
mentioned "the arcane formatting strings that nobody
understands" in a meeting. Since then I've been more cautions
when asking about the subject, and indeed: people seem to be
very apt at understanding format strings. I don't know why.
They seem to be less inclined to understand iostream
manipulators. I don't know why.
|
I've encountered this in certain milieu as well. It doesn't
seem true for the younger programmers I encounter, but a lot of
people seem to have the printf formatters so much in their blood
that they don't realize just how arcane they are. And
arbitrary: why can you format an unsigned in hex, but not a
signed?
| Quote: | (I like using a named function for insertion of parameters,
but your suggestion of operator()() sounds like a good
compromize, for those who find named functions too heavy.)
Such a solution should have been in the standard, sigh.
|
It certainly would have been better than <<.
| Quote: | In the past, I also implemented something similar -- my
implementation actually supported everything in C90 printf,
plus the Open System positional parameter specifiers. (At
the time, I'd just come from C, and printf seemed natural.
Just shows you how much C deforms.)
It might also show how much iostreams deform ).
|
Today, you mean. I'll admit that, in hindsight, the amount of
experience I had with printf had deformed me some. Which
probably means that I now have a similar deformation vis-a-vis
iostreams.
There is one difference, however. My use of printf was exactly
like that of my collegues. We all had the documentation on
line, and looked up exactly what the different flags meant
whenever we wanted something other than a trivial %d or %f. In
the case of iostream, on the other hand, the interface is far
more open -- you derive from streambuf for somethings, write a
custom manipulator for others, etc. None of which is on a
simple man page, and I constat that most of my collegues don't
know how to use it correctly.
| Quote: | It's still in my source tree, but I refuse to do any further
work on it, *because* for simple things, the standard C++
iostream is quite sufficient, and for more complicated
things, like using logical markup, it is superior.
Please explain the "logical markup" thing, thanks.
|
Logical markup involves specifying what a particular part of
text is; how it is formatted is specified elsewhere, either by
the tool or a style sheet, or whatever. Physical markup
involves specifying immediately in the text what the layout is
to look like. As I mentionned before, it's like specifying `
class="x">', as opposed to `<p
style="font-variant=small-caps">'. Or using LaTeX instead of
TeX. With IO Streams, its using custom manipulators like
currency or percent, e.g.:
output << currency << amount
<< " (" << percent << 100*amount/base << ")n" ;
as opposed to:
output << fixed << setprecision( 2 ) << amount
<< " (" << fixed << setprecision( 1 ) <<
100*amount/base << "%)n" ;
Where the important issue isn't that you've typed a lot less,
but that you've expressed what was wanted (currency, percent),
rather than how to do it. How to do it is then isolated in a
single class or function (the manipulator), and is defined
globally for the entire program. Inflation means that you no
longer want to show the cents? You modify the currency
manipulator, and you don't go rummaging through the entire
program trying to find which setprecision(2) (or which "%.2f")
refer to currency.
When comparing printf and iostream, I think it is important to
consider that printf is designed to be used as is, with the user
specifying physical formatting, where as iostream is designed to
provide a low-level tool kit which allows the user to define his
own logical markup. If you're not defining logical mark-up,
you're misusing iostream.
| Quote: | My current belief is that iostreams stand there as a scar on
the otherwise nice C++ landscape, close in ugliness to
two-phase lookup, export, and "<" and ">" as nested parens.
|
My belief is that C++ isn't really very beautiful to begin with.
Just eminently useful and effective in getting the job done.
| Quote: | From that point of view, iostream fits in nicely.
|
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
