How to change the length of "\t"?

[Peng Yu]

Hi,

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

std::cout << "\t";

Thanks,
Peng

[Fred Zwarts]

"Peng Yu" <Pe*******@gmail.comwrote in message news:ad**********************************@59g2000h sb.googlegroups.com...

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.

[James Kanze]

On Jul 14, 7:24 am, Peng Yu <[e-mail]:

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?

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Zeppe]

Peng Yu wrote:

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

[Pete Becker]

On 2008-07-14 01:24:19 -0400, Peng Yu <Pe*******@gmail.comsaid:

Hi,

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

std::cout << "\t";

Putting '\t' into an output stream simply writes a tab character. It's
up to whatever is interpreting the stream to handle the tab. If you
write to a file and load that file into a text editor, the tab will be
expanded to whatever width your text editor is set for. If you display
the file on your terminal, the tab will be expanded to whatever width
your terminal is set for. There's no direct way to control either of
those from the program that writes the file.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Peng Yu]

On Jul 14, 2:23 am, "Fred Zwarts" <[e-mail]:

"Peng Yu" <[e-mail] in messagenews:ad**********************************@5 9g2000hsb.googlegroups.com...

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.

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

[Victor Bazarov]

James Kanze wrote:

On Jul 14, 7:24 am, Peng Yu <[e-mail]:

>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?

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.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Lionel B]

On Mon, 14 Jul 2008 10:14:15 -0700, Peng Yu wrote:

On Jul 14, 2:23 am, "Fred Zwarts" <[e-mail]:

>"Peng Yu" <[e-mail] in
messagenews:ad461c8f-4117-4681-

ba***************@59g2000hsb.googlegroups.com...

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.

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.

--
Lionel B

[James Kanze]

On Jul 14, 10:22 pm, Victor Bazarov <[e-mail]:

James Kanze wrote:

On Jul 14, 7:24 am, Peng Yu <[e-mail]:

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?

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Lionel B]

On Tue, 15 Jul 2008 01:42:37 -0700, James Kanze wrote:

On Jul 14, 10:22 pm, Victor Bazarov <[e-mail]:

>James Kanze wrote:

On Jul 14, 7:24 am, Peng Yu <[e-mail]:

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

[...]

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.

[...]

--
Lionel B

[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.

[Matthias Buelow]

Lionel B wrote:

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.

[Lionel B]

On Tue, 15 Jul 2008 16:16:28 +0200, Matthias Buelow wrote:

Lionel B wrote:

>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.

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.

--
Lionel B

[Matthias Buelow]

Lionel B wrote:

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.

[James Kanze]

On Jul 15, 10:55 am, Lionel B <[e-mail]:

On Tue, 15 Jul 2008 01:42:37 -0700, James Kanze wrote:

On Jul 14, 10:22 pm, Victor Bazarov <[e-mail]:

James Kanze wrote:
On Jul 14, 7:24 am, Peng Yu <[e-mail]:

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

[...]

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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 15, 4:16 pm, Matthias Buelow <[e-mail]:

Lionel B wrote:

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),

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 15, 4:54 pm, Lionel B <[e-mail]:

On Tue, 15 Jul 2008 16:16:28 +0200, Matthias Buelow wrote:

Lionel B wrote:

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.

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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Matthias Buelow]

Alf P. Steinbach wrote:

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?

[Jerry Coffin]

In article <6e************@mid.dfncis.de>, mk*@incubus.de says...

Alf P. Steinbach wrote:

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?

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 15, 7:01 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

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).

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.

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.)

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 15, 8:12 pm, Jerry Coffin <[e-mail]:

In article <[e-mail]>, [e-mail] says...

[...]
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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <e9f92aeb-08bd-44bc-aeda-
4a**********@f36g2000hsa.googlegroups.com>, ja*********@gmail.com
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".

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 15, 9:50 pm, Jerry Coffin <[e-mail]:

In article <e9f92aeb-08bd-44bc-aeda-
[e-mail]>, [e-mail]
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.

"worked" is relative. When your files are copies of Fortran
programs, on cards, with a serial number starting in column 72,
it could reduce the file size by half.

Of course, it's no where near as effective as gzip.

(Note that the critical position in Fortran is 72. A multiple
of 8.)

...and therefore, also a multiple of 4.

Yes, but when skipping from the end of the actual text to this
position, you only need half as many tab characters if they are
eight.

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.

Tabs don't work here, regardless of the tab stop. What happens
when you look at the output of diff, or grep?

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".

Which raises the question: what should you indent, when. I
don't find myself indenting more in C++ than in C. If anything,
less, because C++ seems to lend itself to better encapsulation,
and smaller, simpler functions. But then, I don't indent for
the namespaces, and I don't define member functions in the
classes.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <b1cc8b8e-2bfc-4e18-b3e4-97a1e4a4e305@
2g2000hsn.googlegroups.com>, ja*********@gmail.com says...

[ ... using tabs ]

"worked" is relative. When your files are copies of Fortran
programs, on cards, with a serial number starting in column 72,
it could reduce the file size by half.

Of course, it's no where near as effective as gzip.

Even an incredibly simple RLE should work quite nicely for this...

[ ... ]

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.

Tabs don't work here, regardless of the tab stop. What happens
when you look at the output of diff, or grep?

Oh, you're better off without tabs at all, no doubt about that. The
obnoxion is reduced (slightly) when they're four-stop instead of eight-
stop tabs though.

[ ... ]

Which raises the question: what should you indent, when. I
don't find myself indenting more in C++ than in C. If anything,
less, because C++ seems to lend itself to better encapsulation,
and smaller, simpler functions. But then, I don't indent for
the namespaces, and I don't define member functions in the
classes.

Hmm...I usually indent for namespaces, though I'll admit I don't feel
strongly about it. I frequently write member function definitions inside
of the class definition at first, and move them into separate files only
when/if I see a reason to do so.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 15, 11:17 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

On Jul 15, 7:01 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

>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).

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 is of course the common practice for Windows that sets that
Windows de-facto standard; maintaining anything else is just
silly.

it was established long before windows appeared.

Well, that olde "standard" was tab size 8 or 10 (!), for printers.

That's true. If you go back far enough, 10 was in widespread
use as well. But practically speaking, before Windows or Unix,
all I've ever seen on computers was either 8, or fully
configurable. And before computers, it didn't matter, because
of course, what you got was always spaces; tab was just a
special key, but whether you typed so many spaces, or used the
tab key, made no difference in the document.

And a quick check on my Windows machine showed it using 8 as
well (under Windows XP).

Dunno what you checked but obviously the Wrong Thing. ;-)

I created a file with a tab character in it, and viewed it (with
the "type" command---which is the most basic Windows you can
get, I think). The tab caused the text to be indented 8 spaces.

I just rechecked on my machine here: all of the programs which
are available for editing or displaying text seem to use 8:
"type" (from the command line), Notepad, Wordpad.

If there *is* a standard of 4, it seems to be limited to Visual
Studios. Although in the version which is installed here, it's
completely configurable: I can specify both the tab size and the
indent size, and specify that I want it to use spaces for
indentation. In sum, what I'd expect from any program text
editor. The default isn't really useful, but that's pretty much
the case for ever editor I've ever seen.

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.

No, it isn't. Nearly all Microsoft code uses tab size 4. So
do nearly all Windows programmer's editors, and reportedly
that's also the case on the Mac.

All of my code uses an indentation of 4, too. But the files
don't contain a tab character.

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).

He he. Everybody knows it's just CR. Nobody'd be fool enough
to use anything but a Mac.

:-). Everyone except ASCII, of course.

Actually, there were two widespread practices before Unix:
CR,LF, and LF,CR. According to ASCII, both should give the same
results. (I've never tried LF,CR on either Unix or Windows,
though.)

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.

Wikipedia, which as we all know is the final arbiter of such
questions, the highest authority[1], says "it is unclear why
the 8-character horizontal size was chosen [for printers], as
5 characters, half inch in a typical printer at that time [no
reference or timeframe given], was much more popular at that
time as a paragraph indentation. It may have been chosen to
match early Fortran conventions for where the statement text
started after the line number and continuation character. Or
it may have been chosen as the smallest size that would fit
numbers typically printed in a table."

Well, I seem to remember the 10 you mentioned as the default on
typewriters, back then. And since computer scientists insist on
everything being a power of 2, 8 is the closest power of 2.

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.

Only for cross-platform code. For Windows programming you'd
have a very hard time if you didn't tackle tabs, since MS's
code uses them. And since you have to tackle them anyway, it
would be silly to give up the benefits (yes, there are).

Who looks at MS's code:-)? More generally, I've seen code from
many different sources, and a lot does use tabs. But not always
the same: I've seen 2, 3, 4 and 8. Worse, I've seen code where
parts were obviously written using one tab setting, and other
parts using a different tab setting; you had to change the
configuration of your editor depending on which function, or in
a couple of cases, which part of the function, you wanted to
display correctly.

Under Windows... What do the Windows equivalents of grep and
diff do with tabs, when they display?

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.

On *nix. In Windows (and presumably on the Mac) the problem is
when an editor displays existing tab characters as if tab
stops were anything else but 4. Makes havoc of the existing
code you have to relate to.

Doesn't that depend on what existing code you're talking about.
Obviously, if you've been using tab stops to indent, you don't
want to change the editor configuration until you've untabified
them. Of course, if you've done it right to begin with, this
isn't a problem.

If you're dealing with an external library which is so poorly
documented you have to look at the sources, then this depends on
the library. But what Microsoft may or may not do isn't an
issue here, since Microsoft's libraries (at least those I've
looked at) are very well documented.

>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.)

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...)

Not sure what the imagined problem would be.

Tools like diff and grep output lines from your code with some
additional characters in front of them. Which messes up any
indentation using tabs.

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.

Yes, yes, for cross-platform code, certainly.

Since there's no hope of ever convincing *nix folks to give up
the stupid 8 positions per tab stop convention, and adopt the
much more rational 4. <g>

It's not really a question of Unix. The convention was too well
established even before Unix came along for it to be possible to
change it.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Pascal J. Bourguignon]

James Kanze <ja*********@gmail.comwrites:

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).

>He he. Everybody knows it's just CR. Nobody'd be fool enough
to use anything but a Mac.

:-). Everyone except ASCII, of course.

Actually, there were two widespread practices before Unix:
CR,LF, and LF,CR. According to ASCII, both should give the same
results. (I've never tried LF,CR on either Unix or Windows,
though.)

They would give the same result on a glass tty, but not on a normal
teletype. There, if you send LF, and then CR, the first characters of
the following lines would be printed in the middle of th eline,
because CR takes more time to move the carriage from the right side to
the left side, than LF takes time to move up the paper. That's why
you should always use CR-LF, and not LF-CR, and when you're on a unix
system, convert LF to CR-LF, and when you are on a MacOS system,
convert CR to CR-LF.

>Since there's no hope of ever convincing *nix folks to give up
the stupid 8 positions per tab stop convention, and adopt the
much more rational 4. <g>

It's not really a question of Unix. The convention was too well
established even before Unix came along for it to be possible to
change it.

The best thing to do is to ban the TAB control code in your text
files. Always use spaces to indent or align columns. Any good editor
(eg. emacs) will have an option to do so.
--
__Pascal Bourguignon__