much text, one cout<< ?

[John Brawley]

Is this going to cause me a portability problem?
Purpose: make it easy for me to write my 'help' text block in the .cpp file,
just as I wish it to be output 'formatted-ly' to the user upon demand while
the program is running.

#include <iostream>;
using namespace std;

int main() {
cout<<"these \
lines\n\
are \
much \
longer\n\
than \
this.\n";

return 0;
}

(Or, any better suggestion, without more code?)
Thanks

 

[Victor Bazarov]

Is this going to cause me a portability problem?

It's not valid C++, so, yes, you bet.

Purpose: make it easy for me to write my 'help' text block in the
.cpp file, just as I wish it to be output 'formatted-ly' to the user
upon demand while the program is running.

#include <iostream>;
using namespace std;

int main() {
cout<<"these \
lines\n\
are \
much \
longer\n\
than \
this.\n";

return 0;
}

(Or, any better suggestion, without more code?)
Thanks

Surround every line of text with double quotes.

V

 

[Erik Wikström]

Is this going to cause me a portability problem?
Purpose: make it easy for me to write my 'help' text block in the .cpp file,
just as I wish it to be output 'formatted-ly' to the user upon demand while
the program is running.

#include <iostream>;
using namespace std;

int main() {
cout<<"these \
lines\n\
are \
much \
longer\n\
than \
this.\n";

return 0;
}

(Or, any better suggestion, without more code?)

If you have a number of string literals after each other they will be
concatenated when compiling, just write each line enclosed by double quotes:

#include <iostream>

int main()
{
std::cout <<
"Here begins a number "
"of long lines";
}


Do not forget adding newlines (\n) wherever you need one.

 

[James Kanze]

It's not valid C++, so, yes, you bet.

What's wrong with it? It's not good C++, but it looks legal to
me.

Surround every line of text with double quotes.

Which will make the code more readable (since the following
lines can be correctly indented), but won't change anything in
the meaning of the code.

 

[James Kanze]

Is this going to cause me a portability problem?
Purpose: make it easy for me to write my 'help' text block in the .cpp file,
just as I wish it to be output 'formatted-ly' to the user upon demand while
the program is running.

#include <iostream>;
using namespace std;

int main() {
cout<<"these \
lines\n\
are \
much \
longer\n\
than \
this.\n";

return 0;
}

(Or, any better suggestion, without more code?)

In general (or at least in theory), every program has a
potential portability problem. All implementations have
ressource limits, and if you exceed them, you're going to get
into trouble. As long as your string doesn't exceed the maximum
string length of the compiler, however, and there's enough room
for it in the memory in which the program runs, this should not
cause a problem.

To tell the truth, I have no idea what the maximum string length
for a compiler might be, but I have, on occasion, had strings
which represented tens of lines of output---several KB in
all---, without the slightest problem. (One would hope, of
course, that the maximum string length would only be limited by
the memory available to the compiler, but one never knows.)

 

[Kai-Uwe Bux]

In general (or at least in theory), every program has a
potential portability problem. All implementations have
ressource limits, and if you exceed them, you're going to get
into trouble. As long as your string doesn't exceed the maximum
string length of the compiler, however, and there's enough room
for it in the memory in which the program runs, this should not
cause a problem.

To tell the truth, I have no idea what the maximum string length
for a compiler might be, but I have, on occasion, had strings
which represented tens of lines of output---several KB in
all---, without the slightest problem. (One would hope, of
course, that the maximum string length would only be limited by
the memory available to the compiler, but one never knows.)

For what it's worth: the standard lists (in Annex B) some recommendations
for implementation specific quantities. The recommended lower bound for the
length of string literals is 65536 characters.


Best

Kai-Uwe Bux

 

[James Kanze]

For what it's worth: the standard lists (in Annex B) some
recommendations for implementation specific quantities. The
recommended lower bound for the length of string literals is
65536 characters.

I know. I was actually present for a lot of the discussion
about that. Given the way it came about, and the fact that it
is non-normative, I felt it probably best to not mention it.

 

[John Brawley]

Is this going to cause me a portability problem?
Purpose: make it easy for me to write my 'help' text block
in the .cpp file, just as I wish it to be output 'formatted-ly' to
the user upon demand while the program is running.

#include <iostream>;
using namespace std;

int main() {
cout<<"these \
lines\n\
are \
much \
longer\n\
than \
this.\n";

return 0;
}

Thanks Victor, James, Erik, Kai-Uwe;
I deduce:
Mine is legal (it works, no serious portability problem), but poor C++
practice. (Even though the console window of help text looks exactly like I
want it to.)
I'll think about it more but probably take your suggestions and use
doub-quotes around every line. It'll be 'uglier' to me in the .cpp file,
but
I'd just as soon do things "the right way" whenever possible.
Appreciated.
(It was unexpectedly interesting to see the first two kind helpers
disagreeing with each other... (*grin*) ...over what I feared was 'way too
simple (newbie-ignorant) a question for an actual disagreement from
experienced programmers to arise.)
Have a nice day!

 

[Martin York]

Actually your code is not valid.
A string litteral may not contain an acual new line character.

Thus the following is NOT valid C++

#include <iostream>

int main()
{
std::cout << "Plop
XXX";

}

 

[Martin York]

Oops sorry missed the \ at the end of the line.

 

[Ian Collins]

Oops sorry missed the \ at the end of the line.

And the context!

 

[Martin York]

I'll think about it more but probably take your suggestions and use
doub-quotes around every line. It'll be 'uglier' to me in the .cpp file,
but
I'd just as soon do things "the right way" whenever possible.
Appreciated.

This is a perfect example of a place where you can separate data and
code.
You don't really want the text in the source. If you move the data out
of the code into a separate file you increase readability (as it is
not ugly) you increase portability (as you can then localize the
string without changing the code (a bit of extra work required but not
much)) you reduce your probability of running into compiler specific
limits.

Personally I would do somthing like this:

1) Put the text in a seprate file:

std::ifstream text(getLocalisedFileName());
std::copy(std::istreambuf_iterator<char>(text),std::istreambuf_iterator<char>(),std:stream_iterator<char>(std::cout));

 

[James Kanze]

"John Brawley" <[email protected]> wrote in message

[...]

I'll think about it more but probably take your suggestions
and use doub-quotes around every line. It'll be 'uglier' to
me in the .cpp file, but I'd just as soon do things "the right
way" whenever possible.

I'm curious. Why uglier? Your solution doesn't allow
indentation of any but the first line---using separate string
literals (concatenated by the compiler) does.

Of course, if this is really a more or less large body of text
that you want to maintain as text, the best solution is to do
just that---maintain it as text, in a separate file. If you
still want to have it "compiled into" your program (there are
pros and contras to this), then a simple preprocessor will
convert it to a C style array. Something like:

#! /usr/bin/awk
BEGIN {
print "// Automatically generated file"
print "// DO NOT EDIT"
print ""
print "#include \"helpText.hh\""
print ""
print "char const helpText[] ="
}
{
print " \"" $0 "\""
}
END {
print ";"
}

Then create (manually) the necessary "helpText.hh" header (which
is just one line), and the work is done.

(FWIW: I'd strongly recommend this. Maintaining text in a
format that has a C++ string literal per line will be a pain,
e.g. anytime one line gets to long, and you have to reformat the
paragraph. Whereas if the file is pure text, and the editor
recognizes it as such, it will do the reformatting for you.)

 

[James Kanze]

[...]

Personally I would do somthing like this:

1) Put the text in a seprate file:

std::ifstream text(getLocalisedFileName());
std::copy(std::istreambuf_iterator<char>(text),std::istreambuf_iterator<char>(),std:stream_iterator<char>(std::cout));

Whether this is a good idea or not depends on context. It
definitly makes deployment more complicated, because you have to
deliver two files, rather than one. And you have to somehow
ensure that the program can find the second file, which isn't
necessarily trivial. Anytime you can reasonably put everything
into a executable, and just deliver that single file, it's a
definite advantage. (I've seen far too many programs where the
only message you get from help is something along the lines
"Cannot open .../help.txt". Not very helpful, really.)

Of course, it all depends. If you need a number of different
files anyway, one more isn't going to change anything, and it
does make maintaining different versions (e.g. depending on
language) slightly easier. Back in the old days, of course,
when memory was tight, you'd always use separate file, since
that way, it wasn't part of the binary imagine in memory; that
could still be a consideration today if you have very large help
files. (More likely, today, the help command will be a separate
executable, with a name something like /usr/bin/firefox or
C:/Program Files/Mozilla_Firefox/firefox.exe. In which case, of
course, you'll definitely keep the help text in a separate file.)

 

[John Brawley]

"John Brawley" <[email protected]> wrote in message

[...]

I'll think about it more but probably take your suggestions
and use doub-quotes around every line. It'll be 'uglier' to
me in the .cpp file, but I'd just as soon do things "the right
way" whenever possible.

I'm curious. Why uglier? Your solution doesn't allow
indentation of any but the first line---using separate string
literals (concatenated by the compiler) does.

(James, I replied but it's not here; it's possible I sent it to you directly
(wrong key?) If so, I apologize....
Uh, and please tell me if yuou got it; I'd have to rewrite it otherwise?)

 

[John Brawley]

(Apologies; sent wrong place; now right place: here.)

"John Brawley" <[email protected]> wrote in message

[...]

I'll think about it more but probably take your suggestions
and use doub-quotes around every line. It'll be 'uglier' to
me in the .cpp file, but I'd just as soon do things "the right
way" whenever possible.

I'm curious. Why uglier? Your solution doesn't allow
indentation of any but the first line---using separate string
literals (concatenated by the compiler) does.

Of course, if this is really a more or less large body of text
that you want to maintain as text, the best solution is to do
just that---maintain it as text, in a separate file. If you
still want to have it "compiled into" your program (there are
pros and contras to this), then a simple preprocessor will
convert it to a C style array. Something like:

#! /usr/bin/awk
BEGIN {
print "// Automatically generated file"
print "// DO NOT EDIT"
print ""
print "#include \"helpText.hh\""
print ""
print "char const helpText[] ="
}
{
print " \"" $0 "\""
}
END {
print ";"
}

Then create (manually) the necessary "helpText.hh" header (which
is just one line), and the work is done.

(FWIW: I'd strongly recommend this. Maintaining text in a
format that has a C++ string literal per line will be a pain,
e.g. anytime one line gets to long, and you have to reformat the
paragraph. Whereas if the file is pure text, and the editor
recognizes it as such, it will do the reformatting for you.)
James Kanze

Hi James (and all).
These several last additions to the thread have me a bit confused....
Let me tell you what and why, then I will put in the actual function
that outputs the help file (you may have to unscramble if Usenet
linewraps)...

The program runs forever (user manually terminates).
The user can forget what keyboard keys are used to do whatever, and I
want him/her to _need_ to remember only the 'h' key. Thus the help page
needs to be in the executable thus in memory (yes, I want to
'distribute' one .exe file and a single .txt file).

All the lines of text look to me in the .cpp file, pretty much exactly
as they do on the console screen, with either the \ (continue on the
next line) or the " " double quotes-around, so I'm not sure what the
disagreement is about....

Here's the actual function, copied out of my working .cpp file:

void tvhelp() {
cout<<"\nKeyboard control keys (case is significant):\n\n"
"1,2,3,4,5, and [shift] 1,2,3,4,5 :\n"
"decrease or increase containment sphere radius by\n"
"0.1, 0.01, 0.001, 0.0001, 0.00001\n"
"r =manual ReScan NOW!; [shift]-R =turn off automatic reScan if on\n"
"s =write snapshot (.3D; view with Graph3D.exe) and .TVR files NOW!\n"
"p =write a PovRay file NOW!\n"
"h = this help screen (any time)\n"
"q =quit (end program; write final .3D and .TVR files); \n"
"[spacebar] =get a NOW! one-line pack status report containing:\n"
"pHi: greatest, pLo: smallest, pAvg: average, overlap,\n"
"gRad: present container radius, zC: per-piont overlaps, inner loop\n"
"Any other key: \"not a valid key\", (returns to the
rogram)\n\n\n"; }

(last line broke in emailer; don't know why; "returns to the
program"...)

I call it once at startup, so the user knows it's there and how to get
back to it, then it can be returned to the console screen by hitting the
'h' key (which control is inside a switch statement with all those above
case:es also....)

User is usually in "live" control, hitting the spacebar every now and
then, to judge the state of the packing by the info displayed, so he's
'right there' anyway.

So, does this (I guess this is its 'context'?) explain what/why better?
The console screen looks exactly like that, without the \n s and the
quote characters (and the C++ codewords, etc.)
It looked exactly like that also when using the continuation backslashes
instead, except the left hand side (continuation characters preserved
the indentations not present here). Six of one, half-dozen of the
other. This is a little "uglier" to me (all those quote " characters
instead of just two...)

Peace
JB
(e-mail address removed)
Web: http://tetrahedraverse.com

 

[John Brawley]

This is a perfect example of a place where you can separate data and
code.
You don't really want the text in the source. If you move the data out
of the code into a separate file you increase readability (as it is
not ugly) you increase portability (as you can then localize the
string without changing the code (a bit of extra work required but not
much)) you reduce your probability of running into compiler specific
limits.

Personally I would do somthing like this:

1) Put the text in a seprate file:

std::ifstream text(getLocalisedFileName());

(),std:stream_iterator<char>(std::cout));

Thank you, Martin, but I _do_ want to keep the text inside the source code
(as a function() ) and compile it that way, which is easier on me (it's not
a huge program; just one 400+or- -line .cpp file), so that the user can get
it any time he needs it without leaving the program or having to print out a
reference to look at while he's using the program, and I can't forget pieces
of what's suppsoed to be in the .cpp file. (I have enough trouble just
coding; let alone having to track bits of this'n that; I don't even use a
makefile. It's just SciTE, the .cpp file, and me. (*smile*)

(And thanks to all who've assisted; for such a minor codewriting problem,
y'all have been overresponsive... (*g*))