Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ Primer ex 6.20

Reply
Thread Tools

C++ Primer ex 6.20

 
 
Jim Langston
Guest
Posts: n/a
 
      08-08-2007
"James Kanze" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
On Aug 7, 5:32 am, "Jim Langston" <(E-Mail Removed)> wrote:

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


 
Reply With Quote
 
 
 
 
Jim Langston
Guest
Posts: n/a
 
      08-08-2007
"BobR" <(E-Mail Removed)> wrote in message
news:NZ2ui.406689$(E-Mail Removed)...
>
> arnuld <(E-Mail Removed)> wrote 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.


 
Reply With Quote
 
 
 
 
Jim Langston
Guest
Posts: n/a
 
      08-08-2007
"Jim Langston" <(E-Mail Removed)> wrote in message
news:Qh8ui.41$(E-Mail Removed)...
> "BobR" <(E-Mail Removed)> wrote in message
> news:NZ2ui.406689$(E-Mail Removed)...
>>
>> arnuld <(E-Mail Removed)> wrote 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.


 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2007
On Aug 7, 5:23 pm, joe <(E-Mail Removed)> wrote:
> On Aug 7, 9:13 am, James Kanze <(E-Mail Removed)> wrote:


> > 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2007
On Aug 7, 5:37 pm, "Victor Bazarov" <(E-Mail Removed)> wrote:
> 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2007
On Aug 7, 6:05 pm, arnuld <(E-Mail Removed)> wrote:

[...]
> 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      08-08-2007
On Aug 8, 2:36 am, "Jim Langston" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote 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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SVG primer Captain Dondo HTML 1 01-22-2006 02:08 PM
HTPC Primer, Part I - Video and Audio Silverstrand Front Page News 0 10-21-2005 01:28 PM
PC TV Tuner Primer Silverstrand Front Page News 0 10-19-2005 01:47 PM
Primer needed: Java & Windows Security Chris Java 0 04-18-2005 09:08 PM
SSL / authentication primer Richard Java 2 07-25-2003 02:08 PM



Advertisments