How to change the length of "\t"?

P

Peng Yu

Hi,

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";

Thanks,
Peng
 
F

Fred Zwarts

Peng Yu said:
Hi,

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";

Thanks,
Peng

'\t' is a character with the decimal value of 9 if the ASCII coding is used. It has the same size as any other character.
"\t" is an array of two characters, '\t' and 0.
If you write it to a file and make a dump, you will see it.
What a terminal or printer does when it receives this character is not a C++ topic. Consult you terminal or printer manual.
 
J

James Kanze

It is possible to change the length of "\t" to a number other than 8.
std::cout << "\t";

The length of "\t" had better be two on any conforming C++
system. This goes back to the very beginnings of C, and is so
simple and basic that I find it almost inconceivable that a
compiler would get it wrong.

The value of the two bytes on my systems are 9 and 0, which is
almost universal today on everything but mainframes. (The
standard requires the second byte to be 0. The first byte will
be 5, however, on an IBM mainframe.)

So where is your 8 coming from?
 
Z

Zeppe

Peng said:
Hi,

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";

Dear Peng,

'\t' is a character (tab), and the formatting of this character changes
according to the viewer you are using, it's not a problem of the
language. Printed on console it usually visualised with a number of
spaces that align to the next column which is divisible by 8, but this
can easily change and there is no standard or guarantee on that. If you
want properly formatted output, you'd rather rely on white spaces, that is:

cout << " hello," << endl;
cout << " world!" << endl;

Best,

Zeppe
 
P

Peng Yu

'\t' is a character with the decimal value of 9 if the ASCII coding is used. It has the same size as any other character.
"\t" is an array of two characters, '\t' and 0.
If you write it to a file and make a dump, you will see it.
What a terminal or printer does when it receives this character is not a C++ topic. Consult you terminal or printer manual.

Sorry for the confusion. I meant how to display it with other than 8
white spaces. I found the command 'less' has an option to change that
number from 8 to something else. Let me know if you have any better
solution.

Thanks,
Peng
 
L

Lionel B

Sorry for the confusion. I meant how to display it with other than 8
white spaces. I found the command 'less' has an option to change that
number from 8 to something else. Let me know if you have any better
solution.

As numerous posters have told you, that has *absolutely nothing* to do
with C++ and everything to do with how some particular program (e.g.
`less') chooses to display the '\t' character. If you want some
particular program to display '\t' differently, then consult the
documentation or some forum for that program. It is off-topic here, end
of.
 
J

James Kanze

I believe the OP meant to describe the desire to designate a
different set of positions (number of spaces) which outputting
the TAB character skips. I don't believe C++ defines that at
all, it's the characteristic of the device with which the
output is associated.

Well, he's confirmed that, but I'll admit that the idea didn't
even occur to me. Horizontal tab is a character like any other,
and how the display device reacts to it is very, very dependent.
Practically speaking, a de facto standard of one tab stop every
eight columns has established itself today, but historically, it
really was anything goes, with the print head advancing to the
next position where someone had "configured" a tab stop (and on
some printers, the configuration consisted of moving mechanical
pieces on the printer). In the early Fortran days, 7, then
every four or five, or else only 7 and 72, were common.

Today, as I said, the de facto standard is 8, and IMHO, setting
it to anything else is more or less the equivalent of defining
operator+ to do subtraction. I rather fear that I'm not widely
followed in this opinion, however, as I am constantly running
into text which expects it to be every 2, every 3 or every 4.
Pragmatically, you can more or less assume that '\t' means
display some random number of blanks. Even if you count on 8,
and program accordingly, your output will be messed up when
someone does a diff (which inserts 2 extra characters at the
start of each line) or a grep (which inserts the filename at the
start of each line). (Historically, '\t' was used in text files
as a simple form of compression. Today, for small files, it
doesn't matter, and for big files, gzip or bzip2 are a lot more
effective. And the use of '\t' instead of spaces can interfere
with the algorithms used by gzip or bzip2, and result in less
compression.)

Anyway, the correct solution if you want to position at a
specific place in the line is to output an appropriate number of
spaces (std::setw() can help here), and not to use '\t'. The
only time you should output a '\t' is when you want a tab
character in the text, say for some external program (e.g.
make, which requires tabs in some cases), or to allow the user
to indent according to his personal preferences.
 
L

Lionel B

[...]

Today, as I said, the de facto standard is 8, and IMHO, setting it to
anything else is more or less the equivalent of defining operator+ to do
subtraction. I rather fear that I'm not widely followed in this
opinion,

Certainly not by me! The first thing I do when configuring an editor for
programming (anything) is to change the displayed TAB width to 4 (I might
also convert TABs to spaces, but that's not always an option). I've
always found 8 spaces makes code less readable and takes up an
inconvenient amount of horizontal space.

[...]
 
G

Gernot Frisch

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";


I think what you want to do is to make a tab() function, that returns up to
8 space characters, depending on the current line length.

I don't know of a way to get the number of characters you have put to the
last line, which you need because:

a\tb should become "a b"
abc\td should become "abc d"
in your case.
 
M

Matthias Buelow

Lionel said:
Certainly not by me! The first thing I do when configuring an editor for
programming (anything) is to change the displayed TAB width to 4 (I might

Then everyone who has his editor or viewer at the conventional eight
spaces width will see your text garbled.
also convert TABs to spaces, but that's not always an option). I've
always found 8 spaces makes code less readable and takes up an
inconvenient amount of horizontal space.

Hint: use soft tabs, or some other indenting mechanism which doesn't
rely on changing the hardtab setting. Most editors (outside of the
Windoze world, at least) provide such a feature. For example, in vi, it
can be done by setting sw (shiftwidth), in emacs, you use indentation
styles which can define various indentation widths. If an editor can't
do such a simple thing, it isn't suitable for programming and you should
look for a different one.
 
L

Lionel B

Then everyone who has his editor or viewer at the conventional eight
spaces width will see your text garbled.

Errm... I'm not with you here. I don't see other peoples' text garbled if
I change the displayed tabwidth in my editor - I just see the same text
but with tabs taking up more or less width - so why should they see *my*
text garbled? I'm not actually changing the text at all...

The only case I can think of where garbling might be said to occur might
be where someone has formatted text - say mixing tabs and spaces - *under
the assumption* that a tab occupies 8 spaces. And that's a dumb thing to
do anyway.
 
M

Matthias Buelow

Lionel said:
I'm not actually changing the text at all...

Yes.. I meant the whitespace, obviously.
The only case I can think of where garbling might be said to occur might
be where someone has formatted text - say mixing tabs and spaces - *under
the assumption* that a tab occupies 8 spaces. And that's a dumb thing to
do anyway.

Vi does it that way per default, Emacs does it that way per default, and
most other editors I know, too, I certainly don't consider it "dumb".
It's debatable whether using only spaces might be a better idea;
however, the fact is that most source files (on Unix, at least) use
mixes of spaces and tabs, and assume a hard tab setting of 8 columns.
This isn't usually a problem, until someone comes around and changes the
tab width.
Anyways, this discussion is way OT here, sorry.
 
J

James Kanze

Today, as I said, the de facto standard is 8, and IMHO,
setting it to anything else is more or less the equivalent
of defining operator+ to do subtraction. I rather fear that
I'm not widely followed in this opinion,
Certainly not by me! The first thing I do when configuring an
editor for programming (anything) is to change the displayed
TAB width to 4 (I might also convert TABs to spaces, but
that's not always an option). I've always found 8 spaces makes
code less readable and takes up an inconvenient amount of
horizontal space.

The problem is that you don't look at text only in the editor.
If you grep for something in it, or do a diff between two
versions, then it will look funny as well.

And the position of the tab stop has nothing to do with how you
indent your code. I indent four as well. But my editor will
never output a tab character in a file I'm editing. (It also
does most of the indentation automatically.)
 
J

James Kanze

Then everyone who has his editor or viewer at the conventional
eight spaces width will see your text garbled.
Hint: use soft tabs, or some other indenting mechanism which
doesn't rely on changing the hardtab setting. Most editors
(outside of the Windoze world, at least) provide such a
feature. For example, in vi, it can be done by setting sw
(shiftwidth),

shiftwidth doesn't affect whether tabs are present or not
(although it is independent of the tab position); the option
you're thinking of is expandtab (et), which tells vim (but not
vi) to output only spaces for indentation.
in emacs, you use indentation
styles which can define various indentation widths.

And there is a configuration variable indent-tabs-mode, which if
set to nil, prevents emacs from introducing a tab character as
well.
If an editor can't do such a simple thing, it isn't suitable
for programming and you should look for a different one.

Agreed.
 
J

James Kanze

Errm... I'm not with you here. I don't see other peoples' text
garbled if I change the displayed tabwidth in my editor - I
just see the same text but with tabs taking up more or less
width - so why should they see *my* text garbled? I'm not
actually changing the text at all...
The only case I can think of where garbling might be said to
occur might be where someone has formatted text - say mixing
tabs and spaces - *under the assumption* that a tab occupies 8
spaces. And that's a dumb thing to do anyway.

Using anything other than 8 for tabstops is a dumb thing, since
that's the universal defacto standard today (and you certainly
don't look at text only in an editor). If you're using an
indentation other than 8 (and 8 is too big), then you have to
use some spaces for the indentation. (Because people are stupid
enough to set tabstops in their editor at something different
than 8, I've given up using tabs at all in text files. Just
spaces, so everyone will see the code as it was meant to be
formatted.)
 
M

Matthias Buelow

Alf said:
I'm sorry, but that's not correct. The de facto Windows standard is 4
character positions per tab stop. Tools from early eighties (e.g.
Notepad) excepted.

And once again, the Microsoft world attempts to foist a broken
quasi-standard on us... will it ever end?
 
J

Jerry Coffin

And once again, the Microsoft world attempts to foist a broken
quasi-standard on us... will it ever end?

Pardon my being blunt, but what a bunch of crap. First of all, tabs and
expansion thereof have been a broken quasi-standard since LONG before
Windows was invented. I can remember well dealing with exactly this sort
of problem when moving data on 7- and 9-track tapes from IBM to Control
Data mainframes.

Second, MS-DOS and Windows command prompts have always done pretty much
the same as UNIX and similar systems, with tabs every 8 characters and a
tab moving to the next tab stop, NOT expanding to a fixed number of
spaces.

Finally, having tab stops every 4 character cells is a least a lot less
broken than having them every 8. It's not perfect, but 8 is completely
unusable.
 
J

James Kanze

* James Kanze:
I'm sorry, but that's not correct. The de facto Windows
standard is 4 character positions per tab stop. Tools from
early eighties (e.g. Notepad) excepted.

Windows doesn't make the standard; it was established long
before windows appeared.

And a quick check on my Windows machine showed it using 8 as
well (under Windows XP). So I'm not sure what you're talking
about when you speak of 4; until your statement above, I had
assumed that it was a personal configuration of the editor.

If they did try to make it 4... Trying to change such an
established standard is almost as dumb as another systems
attempt to change the de facto standard for line endings (which
is, of course, CR,LF).
Regarding what's dumb, the *nix de facto standard of 8
character positions per tab stop is clearly dumb, since it's
impractical for anything,

Historically, I don't know where the 8 comes from; it was the de
facto standard before I got into computer programming, and that
goes back some. Before Windows or Unix.
and the lack of a standard for indicating the tab stop and
indentation settings of source code is clearly dumb (would be
a good candidate for a new C++ preprocessor directive :)).
But I'm pretty sure that folks who have not enjoyed the
benefits of working in an environment with consistent 4-tabs,
actually using tabs in source code, will not immediately grasp
why any of the abovementioned should be dumb. After all, we
manage quite fine without using tabs at all, thank you.

Yes. You shouldn't use tabs in your source code; that much is
clear. And there's no problem with an editor doing whatever it
wants with the tab key (emacs reindents the line according to
its idea of how it should be indented). The problem is when the
editor (or any other program) inserts a tab character in the
code, or displays an existing tab character as if tab stops were
anything else but 8.
Using spaces instead of tabs is a good recommendation for
cross-platform work, and it is, for example, the solution
adopted by Boost.

Not just cross platform. It comes into play anytime you do a
diff or whatever Windows equivalent of grep is. (I'll admit
that I'm lazy---rather than learn the Windows tools for such
essential tasks, I just installed a Unix tool kit. Which is far
from ideal, but since I already know it, and don't work enough
under Windows to justify learning anything else...)

Letting the editor indent however much you want (I like four,
but three or five is also acceptable) is also a good thing; just
get everyone on the project to agree. And make sure that when
the indentation gets into the files, it's as spaces, not tab
characters, or you'll run into problems downstream.
 
J

James Kanze

[...]
I agree with the rest of what you said, but...
Finally, having tab stops every 4 character cells is a least a
lot less broken than having them every 8. It's not perfect,
but 8 is completely unusable.

Could you explain please. Starting with what use you see for
tabs.

They don't occur in written text, or at least, you can't
distinguish between a tab character and so many spaces.
Historically, they ended up in files as a very primitive means
of reducing file size---and 8 apparently worked well there.
(Note that the critical position in Fortran is 72. A multiple
of 8.) Today, frankly, I don't see much use of them in files at
all, and find the best solution is to ban them. Except that
some old programs (like make) still require them. (And I agree
that for make, 4 would be better. But 8 is still quite usable.)
 
J

Jerry Coffin

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]
Could you explain please. Starting with what use you see for
tabs.

Well, almost none, quite frankly...
They don't occur in written text, or at least, you can't
distinguish between a tab character and so many spaces.
Historically, they ended up in files as a very primitive means
of reducing file size---and 8 apparently worked well there.

Not really -- 8 was used there, but never worked worth a darn, IMO.
(Note that the critical position in Fortran is 72. A multiple
of 8.)

....and therefore, also a multiple of 4.
Today, frankly, I don't see much use of them in files at
all, and find the best solution is to ban them. Except that
some old programs (like make) still require them. (And I agree
that for make, 4 would be better. But 8 is still quite usable.)

To be honest, I was thinking primarily in terms of people who still use
them for indenting code. For that purpose, I find tab stops of 8
(regardless of whether implemented using actual tab characters or by
inserting spaces) to be quite unusable -- a pointless waste of space at
best.

When I mostly wrote C, I'd have said it didn't matter much -- you should
rarely have code nested deeply enough for it to make much difference. In
C++, however, quite a bit of code is (for example) in a member function
in a class in a namespace, so you frequently end up with two or three
levels of indentation before you start writing code at all. Even a
perfectly reasonable level of indentation the code itself (e.g. 2 deep)
and your code is indented 40 spaces. Given that I normally prefer to
limit lines to no more than 72 characters, that leaves less than half
the line available for real use. More than once I've seen people
shortening identifiers to make things fit at that point, and IMO, that
fully merits being called "completely unusable".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,173
Messages
2,570,938
Members
47,475
Latest member
NovellaSce

Latest Threads

Top