C++ Primer ex 6.20

[arnuld]

it works fine. i am posting it to know your views (please remember, i am
at chapter 6, so i have not encountered stuf like Functions):

/* C++ Primer - 4/e
*
* exercise 6.20
* STATEMENT
* write a programme to rad a sequence of strings from standard
input until either the same word occurs twice in succession or all the
words have been read. use the while loop to read a word at a time. use
the break statement to terminate the loop if awords occurs twice in
succession & print that word or else print the message that no word was
repeated.
*
*/
#include <iostream>
#include <string>

int main()
{
std::string cstr, pstr;
bool same_str = false;

while(std::cin >cstr)
{
if(cstr == pstr)
{
same_str = true;
break;
}

pstr = cstr;
}
if(same_str)
{
std::cout << "\n'"
<< cstr
<< "' was repeated\n";
}
else
{
std::cout << "\nno word was repeated\n";
}

return 0;
}

--
http://arnuld.blogspot.com

[Barry]

arnuld wrote:

it works fine. i am posting it to know your views (please remember, i am
at chapter 6, so i have not encountered stuf like Functions):

So, what's the point?

[Jim Langston]

"arnuld" <ge*********@gmail.comwrote in message
news:pa****************************@gmail.com...

it works fine. i am posting it to know your views (please remember, i am
at chapter 6, so i have not encountered stuf like Functions):

/* C++ Primer - 4/e
*
* exercise 6.20
* STATEMENT
* write a programme to rad a sequence of strings from standard
input until either the same word occurs twice in succession or all the
words have been read. use the while loop to read a word at a time. use
the break statement to terminate the loop if awords occurs twice in
succession & print that word or else print the message that no word was
repeated.
*
*/

Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)

#include <iostream>
#include <string>

int main()
{
std::string cstr, pstr;
bool same_str = false;

while(! same_str && std::cin >cstr)

{
if(cstr == pstr)
same_str = true;
pstr = cstr;
}
if(same_str)
std::cout << "\n'" << cstr << "' was repeated\n";
else
std::cout << "\nno word was repeated\n";

return 0;
}

--
http://arnuld.blogspot.com

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-06 10:29, Barry wrote:

arnuld wrote:

>it works fine. i am posting it to know your views (please remember, i am
at chapter 6, so i have not encountered stuf like Functions):

So, what's the point?

Point of what?

--
Erik Wikström

[arnuld]

On Aug 6, 1:43 pm, "Jim Langston" <[e-mail]:

Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)

while(! same_str && std::cin >cstr)

thanks, i will use it :)
-- arnuld
http://arnuld.blogspot.com

[int2str]

On Aug 6, 2:04 am, arnuld <[e-mail]:

On Aug 6, 1:43 pm, "Jim Langston" <[e-mail]:
Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)
while(! same_str && std::cin >cstr)

thanks, i will use it :)

-- arnuldhttp://arnuld.blogspot.com

I'm not a fan of unnecessary state variables (same_str) which can be
handled by logic in the code instead.

You can also omit the "return 0;" in C++.

So I propose the following version of your code:

#include <iostream>
#include <string>

int main()
{
std::string cstr, pstr;

while( std::cin >cstr && pstr != cstr )
{
pstr = cstr;
cstr = "";
}

if( cstr != "" )
std::cout << "\n'" << cstr << "' was repeated\n";
else
std::cout << "\nno word was repeated\n";
}

Cheers,
Andre

[BobR]

<in*****@gmail.comwrote in message...

>
You can also omit the "return 0;" in C++.

BUT, why would you want to?

Lazy?

--
Bob R
POVrookie

[Victor Bazarov]

BobR wrote:

<in*****@gmail.comwrote in message...

>>
You can also omit the "return 0;" in C++.

BUT, why would you want to?

Lazy?

<shrugI don't understand the desire to label somebody right away
with a negative epithet. Every use of a member name in a non-static
member function _can_ be preceded by 'this->'. Do *you* do that?
I don't think so. Why? Lazy? It's unnecessary in *most* cases.

Same here. It's unnecessary to spell out "return 0;". What do you
*gain* (except more typing exercise for your hands) when you spell
it out?

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

[werasm]

Jim Langston wrote:

Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)

[snip]

while(! same_str && std::cin >cstr)

{
if(cstr == pstr)
same_str = true;
pstr = cstr;
}

This causes one unnecessary string assignment, even
though the strings already tested equal. IMO this could
be regarded as pessimizing prematurely (for the sake
of not using a break?). It also causes additional an
comparison. If you did not want to break, the least
you could have done is continue after the if( cstr == pstr ).
Matter of style: Using no braces after if is often a source
of error.

[James Kanze]

On Aug 6, 8:36 pm, "[e-mail]" <[e-mail]:

On Aug 6, 2:04 am, arnuld <[e-mail]:

On Aug 6, 1:43 pm, "Jim Langston" <[e-mail]:
Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)
while(! same_str && std::cin >cstr)

thanks, i will use it :)

I'm not a fan of unnecessary state variables (same_str) which can be
handled by logic in the code instead.

You can also omit the "return 0;" in C++.

You can, but not everything that you can do you should do. The
return is good form, and I would generally criticize a
programmer for omitting it.

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

[BobR]

Victor Bazarov <v.********@comAcast.netwrote in message...

BobR wrote:

<in*****@gmail.comwrote in message...

>
You can also omit the "return 0;" in C++.

BUT, why would you want to?

Lazy?

<shrugI don't understand the desire to label somebody right away
with a negative epithet.

Not epithetical, just a question.

Every use of a member name in a non-static
member function _can_ be preceded by 'this->'. Do *you* do that?

Sometimes, yes.

I don't think so. Why? Lazy? It's unnecessary in *most* cases.

And in other cases, it makes it clear enough that you don't need to write a
long comment on it.

>
Same here. It's unnecessary to spell out "return 0;". What do you
*gain* (except more typing exercise for your hands) when you spell
it out?

So, we should put this line in the FAQ:

"DO NOT write 'return 0;' in main()"!

<G>

It seems silly to tell a newbie not to do it.
And what about old code in books/net (often posted by newbies):

void main(){
return 0;
}

Now the compiler *should* complain!
(assume an old compiler that didn't flag the 'void'.)

--
Bob R
POVrookie

[BobR]

Jim Langston <ta*******@rocketmail.comwrote in message...

>
"arnuld" <ge*********@gmail.comwrote in message...

it works fine. i am posting it to know your views (please remember, i am
at chapter 6, so i have not encountered stuf like Functions):

/* C++ Primer - 4/e * exercise 6.20
* STATEMENT
* write a programme to rad a sequence of strings from standard
input until either the same word occurs twice in succession or all the
words have been read. use the while loop to read a word at a time. use
the break statement to terminate the loop if awords occurs twice in
succession & print that word or else print the message that no word was
repeated.
*/

Personally, I'm not in favor of the break statement when other methods can
be easily used. I would rather do (untested code)

Unfortunately, the 'break' *is in* the spec.

>

#include <iostream>
#include <string>

int main(){
std::string cstr, pstr;
bool same_str = false;

/*

while(! same_str && std::cin >cstr){

if(cstr == pstr)
same_str = true;
pstr = cstr;
}

*/
while( ! same_str && std::cin >cstr ){
same_str = ( cstr == pstr );
pstr = cstr;
// if( same_str ){ cstr += "break;"; } // for spec :-}
}
// <G>

if(same_str)
std::cout << "\n'" << cstr << "' was repeated\n";
else
std::cout << "\nno word was repeated\n";
return 0;
}

--
Bob R
POVrookie

[Jim Langston]

"werasm" <we****@gmail.comwrote in message
news:11**********************@l70g2000hse.googlegr oups.com...

>
Jim Langston wrote:

>Personally, I'm not in favor of the break statement when other methods
can
be easily used. I would rather do (untested code)

[snip]

> while(! same_str && std::cin >cstr)

{
if(cstr == pstr)
same_str = true;
pstr = cstr;
}

This causes one unnecessary string assignment, even
though the strings already tested equal. IMO this could
be regarded as pessimizing prematurely (for the sake
of not using a break?). It also causes additional an
comparison. If you did not want to break, the least
you could have done is continue after the if( cstr == pstr ).

Matter of style: Using no braces after if is often a source
of error.

RE: the matter of style. I've gone back and forth on this over the years.
I've done it so I always use brackets. I've done it so I don't use brackets
unless I have to. I've done it where I'd use brackets if it was a function
call, etc...

At this point in time I'm not using brackets when not needed and in my own
code it hasn't caused any problems of any importance (something that took me
more than a minute or two to find and fix). But then, I've read many many
lines of code in many many languages over the years in many formats.

I tend to go for the white space format, I.E.

if ( condition )
{
statements
}

rather than

if ( condition ) {
statements
}

Which may make a difference. It would be easy to miss the fact that there
is only one statement if you are not used to seeing a bracket on the
preceeding line.

[James Kanze]

On Aug 6, 10:03 pm, "Victor Bazarov" <[e-mail]:

BobR wrote:

<[e-mail] in message...

You can also omit the "return 0;" in C++.

BUT, why would you want to?

Lazy?

<shrugI don't understand the desire to label somebody right away
with a negative epithet.

There's a question mark. He's not labeling anybody. He's
asking if that is the reason (which is, IMHO, an indirect way to
ask whether there are any other reasons).

Every use of a member name in a non-static
member function _can_ be preceded by 'this->'. Do *you* do that?
I don't think so. Why? Lazy? It's unnecessary in *most* cases.

Coherence. I never use this->. I always put a return at the
end of a function which has a return value. Why should main be
an exception.

In practice, of course, I don't think I've ever written any real
code where it was just "return 0". Any real program will have
output somewhere, output can fail, and if the output fails, you
don't want to return 0. You might as well get into the habit of
writing the return, since it's going to be necessary in any
program that is actually used.

Same here. It's unnecessary to spell out "return 0;". What do you
*gain* (except more typing exercise for your hands) when you spell
it out?

Coherence. Orthogonality.

--
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 Aug 7, 5:32 am, "Jim Langston" <[e-mail]:

[Totally changing topic, but...]

I tend to go for the white space format, I.E.

if ( condition )
{
statements

}

rather than

if ( condition ) {
statements

}

You put a blank line before the closing brace. I've noticed
this a lot recently (in the past year or two?), but had never
seen it (or at least noticed it) before, and I don't do it
myself.

I'm curious as to why? Is it an intentional decision, or is it
based on some tool, or what?

Which may make a difference. It would be easy to miss the
fact that there is only one statement if you are not used to
seeing a bracket on the preceeding line.

Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.

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

[werasm]

James Kanze wrote:

Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.

Certain style issues don't concern me that much, such
as brace positions and naming conventions, as long as
consistency exists. Other style issues could lead to errors,
and I consider lack of braces one such.

For instance in...

if( condition )
doX();
doY();

doY() could easily be mistaken (by a quick reader) as
part of the condition, where in this case:

if( condition )
{ doX(); }
doY();

or variations therefore, the mistake is less possible.

Werner

[Richard]

werasm <we****@gmail.comwrites:

James Kanze wrote:

>Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.

Certain style issues don't concern me that much, such
as brace positions and naming conventions, as long as
consistency exists. Other style issues could lead to errors,
and I consider lack of braces one such.

For instance in...

if( condition )
doX();
doY();

doY() could easily be mistaken (by a quick reader) as
part of the condition, where in this case:

if( condition )
{ doX(); }
doY();

And one of the main reasons to advocate the K&R bracketing because in
your example the brackets are easily missed, especially in longer lines.

if (f){
doX();
}
doY();

leaves no room for confusion. Obviously the good tab lengths (Linux src
is 8) and indenting correctly helps eliminate any issue regardless.

>
or variations therefore, the mistake is less possible.

Werner

--

[Victor Bazarov]

Richard wrote:

[..] Obviously the good tab lengths (Linux
src is 8) [..]

The "tab length" is a setting of a text editor. How can "src" have
any "tab length"? Did you mean indentation offset in spaces? I,
personally, hate tab characters in the source.

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

[James Kanze]

On Aug 7, 1:53 pm, werasm <[e-mail]:

James Kanze wrote:

Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.

Certain style issues don't concern me that much, such
as brace positions and naming conventions, as long as
consistency exists. Other style issues could lead to errors,
and I consider lack of braces one such.

So called style issues certainly vary in importance, from simple
personal taste (indent 3 spaces or 4) to something that is
absolute (no indentation what so ever, or---and I've actually
seen it done---random indentation). I understand your point
concerning the braces; leaving them out does allow one
additional error possibility when modifying code. In practice,
however, *IF* a reasonable style is rigorously adhered to,
missing braces when needed will stick out, and so won't occur.
The importance, here, is that the code is formatting using one,
reasonable style, and that that style does make the braces (or
the absence thereof) stick out.

For instance in...

if( condition )
doX();
doY();

doY() could easily be mistaken (by a quick reader) as
part of the condition,

So don't indent like that. My editor almost won't let me; I
have to do a lot of extra work to get it like that.

where in this case:

if( condition )
{ doX(); }
doY();

or variations therefore, the mistake is less possible.

I don't know. There's still an indentation error on doY(), and
I'm not sure I'd spot the fact that doY() isn't part of the if
immediately.

I might add that while not an absolute rule, like "use
indentation", I'd tend to reject styles which have code
following an open brace or before a closing brace, on the same
line. My rule is more or less that either:

-- the opening brace is on a line by itself, so you can't miss
it, or
-- you always use braces, so you don't have to see it to know
that it's there,
and
-- the closing brace is on a line by itself, or
-- it is always the first non white space, and anything which
follows is part of the "enclosing" statement (else of an
if/else, or while of a do/while).

I currently use the second of each of these rules, but I'd have
no trouble using the first if that's what my co-workers
preferred (and IMHO, omitting the braces is only acceptable if
you use the first).

I might add that regardless of which of the above rules I use,
the opening brace of a function or a class is always on a line
by itself. (Just like in K&R:-).)

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

[Richard]

"Victor Bazarov" <v.********@comAcast.netwrites:

Richard wrote:

>[..] Obviously the good tab lengths (Linux
src is 8) [..]

The "tab length" is a setting of a text editor. How can "src" have
any "tab length"? Did you mean indentation offset in spaces? I,
personally, hate tab characters in the source.

By tab length I meant the space taken for each indent. In
Linux it is 8 spaces. It's fairly common to refer to the indent length
as the tab length. Apologies for any confusion.

[James Kanze]

On Aug 7, 2:41 pm, "Alf P. Steinbach" <[e-mail]:

* Victor Bazarov:

Richard wrote:

[..] Obviously the good tab lengths (Linux
src is 8) [..]

The "tab length" is a setting of a text editor. How can "src" have
any "tab length"? Did you mean indentation offset in spaces? I,
personally, hate tab characters in the source.

Bah. As long as you just remember that 1 tab = 3 spaces, it's
a boon to productivity. I think. <g>

Seriously, 4 spaces per tab is of course the only sane choice.

The "standard" is (and always has been) eight. (Don't ask me
why, or who decided, but it goes back long before Unix.) Of
course, most editors will give you any number of options, but
they don't help when outputting the code using other tools; if
your source code has tab characters in it, then you must expand
them to 8, or others will not see the code as you do.

Eight is, of course, a pretty poor choice for indentation. Far
too big. So you don't use tabs for indentation, but spaces (or
a mixture of tabs and spaces). Off hand, for indentation, 2 or
less is too little, and 6 or more too much. As computer
scientists, of course, we favor powers of 2, and the only power
of 2 in the acceptable range is 4, so that's what we use:-).
(But I've maintained code where the original coder used three,
and there was no problem with it. I suspect that five would
also be just as good.)

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

[werasm]

Richard wrote:

And one of the main reasons to advocate the K&R bracketing because in
your example the brackets are easily missed, especially in longer lines.

if (f){
doX();
}
doY();

This is not my bracketing style, but a style I used to prove a point.
My real style would be:

if( condition )
{
doX();
}

doY();

The point is: Presence of brackets (in any style) make error less
probable.
Personally, I don't mind most ways of bracket usage, as long as it is
present
and consistent.

W

[werasm]

werasm wrote:

Pardon,

Actually...

if( condition )
{
doX();
}

doY();

.... incase I get more comments wrt. synax/style.

>
W

[joe]

On Aug 7, 9:13 am, James Kanze <[e-mail]:

>
The "standard" is (and always has been) eight. (Don't ask me
why, or who decided, but it goes back long before Unix.) Of
course, most editors will give you any number of options, but
they don't help when outputting the code using other tools; if
your source code has tab characters in it, then you must expand
them to 8, or others will not see the code as you do.

And here I always thought it was 8 because the one true terminal for
unix was the adm3a and it used 8 characters for the tab stop. I
actually suspect, but can't prove, that eight characters per tabstop
was chosen for ttys because many of the languages used on punch cards
(such as fortran) started at the eighth character and reserved the
first 7 spaces for line numbers and comment characters.

For what it's worth, I tend to like 4 for tabs. That is probably
because I am both a programmer and old school. That is, I both like
that it is a power of 2 and I like that every two tabs matches up with
a "real" tab. :)

joe

[Victor Bazarov]

joe wrote:

[..] I
actually suspect, but can't prove, that eight characters per tabstop
was chosen for ttys because many of the languages used on punch cards
(such as fortran) started at the eighth character and reserved the
first 7 spaces for line numbers and comment characters.

It's plausible. Fortran IV has the first and the sixth character
special. So, a "regular" statement starts with the seventh, and it
is conceivable that somebody decided to give it a separate buffer
of two characters, although in those days it wasn't commonly done
(wasting bytes like that, I mean).

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

[arnuld]

On Aug 7, 1:36 pm, James Kanze <[e-mail]:

On Aug 7, 5:32 am, "Jim Langston" <[e-mail]:

I tend to go for the white space format, I.E.
if ( condition )
{
statements

}
rather than
if ( condition ) {
statements

}

You put a blank line before the closing brace. I've noticed
this a lot recently (in the past year or two?), but had never
seen it (or at least noticed it) before, and I don't do it
myself.

I'm curious as to why? Is it an intentional decision, or is it
based on some tool, or what?

i have also noticed this but i do not use it myself and have not found
the reason why programmers use this.

BTW, i have learnt 2 coding style from this group:
if ( condition )

rather than

if(condition)

&

if ( condition )
{
//...
}

rather than

if ( condition ) {
// ....
}
i have found them more readable and i never thought so earlier about
that. i will stick with them from now on and as K&R2 says: "pick a
style that suits you, then use it consistently" [page - 10]

[BobR]

arnuld <ge*********@gmail.comwrote in message...

>
i have also noticed this but i do not use it myself and have not found
the reason why programmers use this.
BTW, i have learnt 2 coding style from this group:

if ( condition )

rather than

if(condition)

&

if ( condition )
{
//...
}

rather than

if ( condition ) {
// ....
}

i have found them more readable and i never thought so earlier about
that. i will stick with them from now on and as K&R2 says: "pick a
style that suits you, then use it consistently" [page - 10]

I developed my style with influence from B. Eckel, and the style I used in
Assembler since the early '80s.

void MyFunc1(){
// ... stuff ....
return;
} // last brace indented
void MyFunc2(){
// ... stuff ....
if( blah ) callFireDept();
// or:
// if( blah )
// callFireDept(); // long comment here
if( blah2 ){
callPoliceDept();
}
return;
} // last brace indented

Compact, but still able to see where one thing ends and another begins.
In certain situations, I bend my own rules (like really long lines,
indentation gets out of hand, etc.).
[ but, you gotta do it the way the *boss* says! <G]

To each his/her own, use what helps *you*.

Newbies: Just DO NOT put *everything* against the left margin!! PLEASE.

--
Bob R
POVrookie

[Jim Langston]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...
On Aug 7, 5:32 am, "Jim Langston" <[e-mail]:

[Totally changing topic, but...]

I tend to go for the white space format, I.E.

if ( condition )
{
statements

}

rather than

if ( condition ) {
statements

}

You put a blank line before the closing brace. I've noticed
this a lot recently (in the past year or two?), but had never
seen it (or at least noticed it) before, and I don't do it
myself.

I'm curious as to why? Is it an intentional decision, or is it
based on some tool, or what?

Which may make a difference. It would be easy to miss the
fact that there is only one statement if you are not used to
seeing a bracket on the preceeding line.

Agreed. Like you, I've used different styles over time. The
important thing is that the code has an "expected" look; if you
change something, and that look isn't there, it strikes you
immediately. If the rule is "a flow control statement is
followed either by a single indented statement, or a { on a line
by itself, not indented", then adding a second statement just
doesn't look right unless you add the {.

============

It is strange, but in the message I posted, there was NOT an extra space
before the closing bracket. But you quote me with the space. I don't know
if it was your reader or not, but I look at my post and the extra space is
not there.

That is:

if ( condition )
{
statements
}

should be 4 lines. The if, left bracket, statements, right bracket. If you
see an extra line before the end bracket somethings amiss.

[Jim Langston]

"BobR" <re***********@worldnet.att.netwrote in message
news:NZ*********************@bgtnsc04-news.ops.worldnet.att.net...

>
arnuld <ge*********@gmail.comwrote in message...

>>
i have also noticed this but i do not use it myself and have not found
the reason why programmers use this.
BTW, i have learnt 2 coding style from this group:

if ( condition )

rather than

if(condition)

&

if ( condition )
{
//...
}

rather than

if ( condition ) {
// ....
}

i have found them more readable and i never thought so earlier about
that. i will stick with them from now on and as K&R2 says: "pick a
style that suits you, then use it consistently" [page - 10]

I developed my style with influence from B. Eckel, and the style I used in
Assembler since the early '80s.

void MyFunc1(){
// ... stuff ....
return;
} // last brace indented
void MyFunc2(){
// ... stuff ....
if( blah ) callFireDept();
// or:
// if( blah )
// callFireDept(); // long comment here
if( blah2 ){
callPoliceDept();
}
return;
} // last brace indented

Compact, but still able to see where one thing ends and another begins.
In certain situations, I bend my own rules (like really long lines,
indentation gets out of hand, etc.).
[ but, you gotta do it the way the *boss* says! <G]

To each his/her own, use what helps *you*.

Newbies: Just DO NOT put *everything* against the left margin!! PLEASE.

At one point I indented the bracket and got used to it. But the main reason
I changed is because the auto formatting of my compiler doesn't indent the
bracket.

[Jim Langston]

"Jim Langston" <ta*******@rocketmail.comwrote in message
news:Qh*************@newsfe03.lga...

"BobR" <re***********@worldnet.att.netwrote in message
news:NZ*********************@bgtnsc04-news.ops.worldnet.att.net...

>>
arnuld <ge*********@gmail.comwrote in message...

>>>
i have also noticed this but i do not use it myself and have not found
the reason why programmers use this.
BTW, i have learnt 2 coding style from this group:

if ( condition )

rather than

if(condition)

&

if ( condition )
{
//...
}

rather than

if ( condition ) {
// ....
}

i have found them more readable and i never thought so earlier about
that. i will stick with them from now on and as K&R2 says: "pick a
style that suits you, then use it consistently" [page - 10]

I developed my style with influence from B. Eckel, and the style I used
in
Assembler since the early '80s.

void MyFunc1(){
// ... stuff ....
return;
} // last brace indented
void MyFunc2(){
// ... stuff ....
if( blah ) callFireDept();
// or:
// if( blah )
// callFireDept(); // long comment here
if( blah2 ){
callPoliceDept();
}
return;
} // last brace indented

Compact, but still able to see where one thing ends and another begins.
In certain situations, I bend my own rules (like really long lines,
indentation gets out of hand, etc.).
[ but, you gotta do it the way the *boss* says! <G]

To each his/her own, use what helps *you*.

Newbies: Just DO NOT put *everything* against the left margin!! PLEASE.

At one point I indented the bracket and got used to it. But the main
reason I changed is because the auto formatting of my compiler doesn't
indent the bracket.

Of course I meant IDE and not compiler.

[James Kanze]

On Aug 7, 5:23 pm, joe <[e-mail]:

On Aug 7, 9:13 am, James Kanze <[e-mail]:

The "standard" is (and always has been) eight. (Don't ask me
why, or who decided, but it goes back long before Unix.) Of
course, most editors will give you any number of options, but
they don't help when outputting the code using other tools; if
your source code has tab characters in it, then you must expand
them to 8, or others will not see the code as you do.

And here I always thought it was 8 because the one true terminal for
unix was the adm3a and it used 8 characters for the tab stop.

As I said, it goes back long before Unix. I first saw it in
Univac transmission protocol around 1975, and the protocol was
considered very outdated even then.

I
actually suspect, but can't prove, that eight characters per tabstop
was chosen for ttys because many of the languages used on punch cards
(such as fortran) started at the eighth character and reserved the
first 7 spaces for line numbers and comment characters.

The relationship with Fortran might have something to do with
it, except that in Fortran (at least, the Fortran of the 1970's
and before), it would have been seven (as you point out).

For what it's worth, I tend to like 4 for tabs. That is probably
because I am both a programmer and old school. That is, I both like
that it is a power of 2 and I like that every two tabs matches up with
a "real" tab. :)

You mean you like 4 as a shift width. That's what I use, too.

In practice, changing tab stops from eight just isn't possible.
There's too much legacy software and equipment which has 8 built
in, and too much modern stuff which is built with 8 built in to
conform with the legacy equipment. Even most of Windows uses 8.
(The problem, of course, is that you don't just view your code
in the editor. You print it, you grep for things in it, you
diff it... And unless you can force all of your toolset to use
the non-standard tabstop, you're stuck.)

--
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 Aug 7, 5:37 pm, "Victor Bazarov" <[e-mail]:

joe wrote:

[..] I
actually suspect, but can't prove, that eight characters per tabstop
was chosen for ttys because many of the languages used on punch cards
(such as fortran) started at the eighth character and reserved the
first 7 spaces for line numbers and comment characters.

It's plausible. Fortran IV has the first and the sixth character
special. So, a "regular" statement starts with the seventh, and it
is conceivable that somebody decided to give it a separate buffer
of two characters, although in those days it wasn't commonly done
(wasting bytes like that, I mean).

Wasting bytes wasn't commonly done, but program input was on 80
column punched cards---every line had exactly 80 characters in
it, like it or not. And the Fortran compilers I knew ignored
the last 8 (there comes that multiple again), so that you could
put sequence numbers in them, so that the deck could be
automatically resorted when you dropped it on the floor.

It's interesting to note that Cobol apparently followed
Fortran's example, with the first 7 columns being special. It
also distinguished an Area A (columns 8-11) and an Area B
(columns 12-72). None of which (except for the 72) reinforces
the 8 column tabs.

Some of the early assemblers I used did, however, treating
columns 1-8 as a label, 9-16 as a mnemonic, and 17 and up as the
arguments to the instruction.

--
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 Aug 7, 6:05 pm, arnuld <[e-mail]:

[...]

BTW, i have learnt 2 coding style from this group:

if ( condition )

rather than

if(condition)

That's a different issue: white space in a line. If you work in
Germany, you'll soon adapt to the second; if you learned
programming in France, the first will seem more natural. The
use of white space is at least partially influenced by local
typographical conventions; the conventions for French use
considerably more white space than those for most other
languages, and those for German somewhat less. The result is
that when I worked in Germany, many of my collegues felt ill at
ease with my style (and I with theirs); we finally wrote an
"unjames" emacs script which removed the extra spaces I put in.

One point worth mentionning is that the parentheses really have
three different roles in C/C++: they are used for grouping, as a
function call operator, or as a fundamental grammatic part of
some statements. I vary my spacing according to use:

x * (y + z) ; // grouping.
f( y + z ) ; // function call.
if ( y == z ) // part of statement.

Basically, spaces outside for grouping, spaces inside for a
function call (but with the ( tightly bound to the function
name), and spaces both inside and outside for part of a
statement.

This isn't, however, something that I would consider essential,
or that I would fight to have, and I have no problem with the
fact that my German collegues wouldn't have used a single space
in any of the examples above (except maybe before the comment).

--
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 Aug 8, 2:36 am, "Jim Langston" <[e-mail]:

"James Kanze" <[e-mail] in message

[...]

It is strange, but in the message I posted, there was NOT an
extra space before the closing bracket. But you quote me with
the space. I don't know if it was your reader or not, but I
look at my post and the extra space is not there.

That is:

if ( condition )
{
statements

}

should be 4 lines. The if, left bracket, statements, right
bracket. If you see an extra line before the end bracket
somethings amiss.

Google again? That would explain why I see it a lot now (that
I'm using Google as a news reader), and never saw it before
(when I used Gnus, or for a very short time, Thunderbird).

I generally delete it when quoting a posting; I made an
exception this time, since it was the point of my posting.

A quick check with Google showed that my code shows up without
this extra blank line. However, I always indent the code in the
message (to set it off from the rest of the message), so the }
is never in the first column. Maybe that's what it takes to
trigger the Google thing (or whatever it is that's causing it).

Anyway, if it wasn't there to start with, then obviously, it's
not some new convention that's suddenly taking everything by
storm, so there's no problem. I'll just ignore it when I see
it, and continue to delete it when replying.

(I do wish Google would get Google news working correctly,
though. As it is, it crashes Firefox several times a week,
although I've never had Firefox crash on any other page. I
installed a debug version of Firefox, and caught their pages,
and there were so many violations of the HTML standard that I
didn't know where to start.)

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