Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > compiler switch to indicate "end of function"?

Reply
Thread Tools

compiler switch to indicate "end of function"?

 
 
Dr Nick
Guest
Posts: n/a
 
      05-11-2011
Ben Pfaff <(E-Mail Removed)> writes:

> Ian Collins <(E-Mail Removed)> writes:
>
>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>> Ian Collins<(E-Mail Removed)> writes:
>>>
>>>> Displays have improved beyond recognition in the last 20 years and
>>>> coding styles should adapt to suit.
>>>
>>> Displays have started shrinking vertically, though. Most new
>>> screens are 16:9 instead of the former standard 4:3. That's
>>> fewer lines of code displayed vertically for a given amount of
>>> screen area.

>>
>> Below 24" yes (with a few exceptions). But decent sized (24" 16:10
>> and above) still have plenty of vertical pixels.

>
> It's hard on me, though, because I prefer small laptops. My
> previous 12" laptop with a 4:3 screen more easily accommodated
> lots of code than my current 13.3" laptop with a 16:9 screen.
>
> At this rate, my next laptop will have a 2:1 screen.


And if you use the newer Microsoft products they put a "ribbon" across
the top 2/3 of the page, leaving your writing your documents through a
letterbox.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
 
 
 
Michael Press
Guest
Posts: n/a
 
      05-11-2011
In article <(E-Mail Removed)>,
Datesfat Chicks <(E-Mail Removed)> wrote:

> On Tue, 10 May 2011 10:30:18 -0700, Ben Pfaff <(E-Mail Removed)>
> wrote:
>
> >David Mathog <(E-Mail Removed)> writes:
> >
> >> Sometimes when editing a source file a close brace is accidentally
> >> deleted, and when that happens, at least with gcc, the error messages
> >> are not very helpful in locating the error. Error messages are
> >> generated from code below it, although not necessarily very near to
> >> it, going on sometimes to the end of the file, thousands of lines
> >> later.

> >
> >If you have an auto-indenting editor, just tell it to re-indent
> >the whole file and look for the spot where the left margin shifts
> >rightward a tab stop. It's usually obvious.
> >
> >If you are using a version-control system (and if not, why not?),
> >look at the diff against the last checked-in version. If it's
> >indeed a file with thousands of lines, probably the actual
> >changes are much smaller and you may be able to easily pick out
> >where you deleted a closing brace.

>
> To the OP: I use "cvs" with "ViewVC". There is a lot of truth to
> Ben's assertion that a version control system helps. You might also
> try "svn".
>
> Shamefully, I once had to go a step further (but not with gcc).
> Unknown to me, I had typed a control sequence and my favorite text
> editor put a non-printing invisible character in my source file.
>
> I got so frustrated that I did a "diff" (as Ben suggested), which
> didn't seem to show a problem.
>
> So I deleted my "sandbox" copy, checked out the last revision again,
> then manually reapplied the changes shown by the diff one at a time.
>
> >Try using another compiler or C parser. GCC is excessively
> >forgiving because it allows nested function definitions; other
> >compilers will give an error at the first nested function
> >definition, since they don't have that extension.

>
> Whoa! I learned something new.
>
> I have not seen nested functions since Pascal. I did not know that
> any C compiler implemented those. Interesting.
>
> In case you're young enough not to remember Pascal:
>
> http://en.wikipedia.org/wiki/Pascal_...mming_language)
>
> http://en.wikipedia.org/wiki/Turbo_pascal
>
> http://en.wikipedia.org/wiki/Nested_function
>
> Those links bring back memories ...


I totally ignored Pascal. It is one of those plague
viruses that escaped from the laboratory. Happily,
and not by chance, I am immune to such blandishments.

--
Michael Press
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      05-11-2011
On 05/11/11 06:10 PM, Dr Nick wrote:
> Ben Pfaff<(E-Mail Removed)> writes:
>
>> Ian Collins<(E-Mail Removed)> writes:
>>
>>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>>> Ian Collins<(E-Mail Removed)> writes:
>>>>
>>>>> Displays have improved beyond recognition in the last 20 years and
>>>>> coding styles should adapt to suit.
>>>>
>>>> Displays have started shrinking vertically, though. Most new
>>>> screens are 16:9 instead of the former standard 4:3. That's
>>>> fewer lines of code displayed vertically for a given amount of
>>>> screen area.
>>>
>>> Below 24" yes (with a few exceptions). But decent sized (24" 16:10
>>> and above) still have plenty of vertical pixels.

>>
>> It's hard on me, though, because I prefer small laptops. My
>> previous 12" laptop with a 4:3 screen more easily accommodated
>> lots of code than my current 13.3" laptop with a 16:9 screen.
>>
>> At this rate, my next laptop will have a 2:1 screen.

>
> And if you use the newer Microsoft products they put a "ribbon" across
> the top 2/3 of the page, leaving your writing your documents through a
> letterbox.


There's a very simple solution to that. Choice.

--
Ian Collins
 
Reply With Quote
 
luser- -droog
Guest
Posts: n/a
 
      05-11-2011
On May 10, 4:22*pm, Seebs <(E-Mail Removed)> wrote:
> On 2011-05-10, Kleuskes & Moos <(E-Mail Removed)> wrote:
>
> > * * {
> > * * * /* Some comment */
> > * * * including one too few "{" and "}"
> > * * }
> > I'm sure you'll make a lot less errors. Braces are so important in
> > determining the structure of a C program, they deserve their own line.

>
> This is not 1TBS. *Therefore it's wrong.
>
> Here's the thing: *Brace styles are all viable. *Any of them will work.
> But it's VERY useful to have everyone use the same style.
>
> There is no way to pick a standard except by appeal to authority. *Therefore,
> use the brace style from K&R. *That's the closest we'll ever have to a
> proper authority.
>
> > And don't try to tell me that whitespace costs money, since that's
> > only valid on paper.

>
> It's not money, it's visual real estate. *I can only see so many lines
> at a time. *Seeing a few more lines of code at a time is a pretty noticeable
> payoff.
>


Strongly agree. I do most of my work on 9-inch notebook screen.
To get more than 25 or so lines, I'd have to make the font smaller
and harder to read.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-11-2011
Jonathan Leffler <(E-Mail Removed)> writes:
> On 5/10/11 2:22 PM, Seebs wrote:

[...]
>> There is no way to pick a standard except by appeal to authority.
>> Therefore, use the brace style from K&R. That's the closest
>> we'll ever have to a proper authority.

>
> 1TBS as found in K&R 1st and 2nd Edn has the opening brace of a function
> on a line on its own, left justified. Inside a function, yes, the
> braces are at the end of a line after the condition or loop or whatever.
> But the function braces are both flush left.


I think that's because old-style function definitions had (ok, still
have) the parameter declarations between the function name and the
opening '{':

int main()
int argc;
char **argv;
{
/* ... */
}

With prototypes, there's less reason for this exception. I sometimes
put the opening brace for a function definition at the end of the
line, depending on my mood (and, of course, on whatever coding
standards I'm working under):

int main(int argc, char **argv) {
/* ... */
}

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Dr Nick
Guest
Posts: n/a
 
      05-11-2011
Ian Collins <(E-Mail Removed)> writes:

> On 05/11/11 06:10 PM, Dr Nick wrote:
>> Ben Pfaff<(E-Mail Removed)> writes:
>>
>>> Ian Collins<(E-Mail Removed)> writes:
>>>
>>>> On 05/11/11 04:09 PM, Ben Pfaff wrote:
>>>>> Ian Collins<(E-Mail Removed)> writes:
>>>>>
>>>>>> Displays have improved beyond recognition in the last 20 years and
>>>>>> coding styles should adapt to suit.
>>>>>
>>>>> Displays have started shrinking vertically, though. Most new
>>>>> screens are 16:9 instead of the former standard 4:3. That's
>>>>> fewer lines of code displayed vertically for a given amount of
>>>>> screen area.
>>>>
>>>> Below 24" yes (with a few exceptions). But decent sized (24" 16:10
>>>> and above) still have plenty of vertical pixels.
>>>
>>> It's hard on me, though, because I prefer small laptops. My
>>> previous 12" laptop with a 4:3 screen more easily accommodated
>>> lots of code than my current 13.3" laptop with a 16:9 screen.
>>>
>>> At this rate, my next laptop will have a 2:1 screen.

>>
>> And if you use the newer Microsoft products they put a "ribbon" across
>> the top 2/3 of the page, leaving your writing your documents through a
>> letterbox.

>
> There's a very simple solution to that. Choice.


Home is a MS free zone. But I don't really want to change my job.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
 
Reply With Quote
 
Michael Press
Guest
Posts: n/a
 
      05-11-2011
In article <(E-Mail Removed)>,
Datesfat Chicks <(E-Mail Removed)> wrote:

> On Tue, 10 May 2011 23:32:43 -0700, Michael Press <(E-Mail Removed)>
> wrote:
> >>
> >> I have not seen nested functions since Pascal. I did not know that
> >> any C compiler implemented those. Interesting.
> >>
> >> In case you're young enough not to remember Pascal:
> >>
> >> http://en.wikipedia.org/wiki/Pascal_...mming_language)
> >>
> >> http://en.wikipedia.org/wiki/Turbo_pascal
> >>
> >> http://en.wikipedia.org/wiki/Nested_function
> >>
> >> Those links bring back memories ...

> >
> >I totally ignored Pascal. It is one of those plague
> >viruses that escaped from the laboratory. Happily,
> >and not by chance, I am immune to such blandishments.

>
> I didn't fully have that option. It was required for a programming
> class I was taking at the university.
>
> There was a time when Turbo Pascal was dominant.


Then the universities wised up. It is a theory based
system; and that should have given everyone a clue.
Another great idea gone to ruin.

--
Michael Press
 
Reply With Quote
 
David Mathog
Guest
Posts: n/a
 
      05-12-2011
On May 10, 5:34*pm, Keith Thompson <(E-Mail Removed)> wrote:
>
> My only quibble is that I'd put a space in front of the opening '{'.
>


Why do you favor that form over the "spaceless" variant?

The (long story) background for the first post is that once upon a
time I used to use:

if(condition)do_something();

but when "do_something" was too long wrote it as

if(condition)
do_something();

which, in nested code when the condition and do_something lines were
long enough that the right side wasn't normally visible, sometimes led
me to think this was:

if(condition){
do_something();}


so that another line could be added within the conditional
if(condition){
do_something_first();
do_something();}

when it was actually

if(condition)
do_something_first();
do_something();

which is not at all the same thing. Other times the confusion was:

if(long_condition)actual_do_something_off_right_si de();
looks_like_conditional_but_not_do_something();

I'm not saying this happened even once a week, but it happened often
enough that I changed my style to avoid both of those, instead always
putting braces on the expression following an if:

if(condition){ do_something(); }

But it turns out that while this eliminates the preceding issue, it is
relatively easy for an errant key stroke to nip off the closing brace
since it is the last character on the line, leading to the issue that
started this thread. Particularly hard to see in long lines where the
closing brace is often off the right of the screen. As others have
noted, one can reduce the frequency of this issue by using the form:

if(condition)
{
do_something();
}

which is fine in low density code, but is on the losing end of the
readability tradeoff (in my opinion) in code that more closely
resembles a table, like this:

if(condition1){ a=1; b=2; c=3; /*more terms*/ }
else if(condition2){ a=1; b=0; c=3; /*more terms*/ }
else if(condition3){ a=1; b=2; c=0; /*more terms*/ }
/*etc.*/

Regards,

David Mathog
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-12-2011
David Mathog <(E-Mail Removed)> writes:
> On May 10, 5:34*pm, Keith Thompson <(E-Mail Removed)> wrote:
>>
>> My only quibble is that I'd put a space in front of the opening '{'.
>>

>
> Why do you favor that form over the "spaceless" variant?


To be clear we're talking about

if(condition){
...
}

vs.

if (condition) {
...
}

(I also added a space between "if" and "("). I just find the latter
form significantly easier to read. Too many consecutive puncuation
characters tend to blend together visually. The space preceding the
"{" makes it easier to see. It doesn't (IMHO) need to be on a line
by itself, but it does need to stand out.

And I like a space after the "if" partly because the spaceless
version looks too much like a function call. It may also be partly
because, before learning C, I used a language (ok, it was Pascal)
that didn't use parentheses for if statements, and not having some
white space after "if" is a bit jarring.

And it's how K&R do it.

I don't suggest that my opinion is right and yours is wrong; it's
largely a matter of personal taste, K&R precedent, and my own
failing visual acuity.

> The (long story) background for the first post is that once upon a
> time I used to use:
>
> if(condition)do_something();
>
> but when "do_something" was too long wrote it as
>
> if(condition)
> do_something();
>
> which, in nested code when the condition and do_something lines were
> long enough that the right side wasn't normally visible, sometimes led
> me to think this was:
>
> if(condition){
> do_something();}
>
>
> so that another line could be added within the conditional
> if(condition){
> do_something_first();
> do_something();}
>
> when it was actually
>
> if(condition)
> do_something_first();
> do_something();
>
> which is not at all the same thing.


In my own style, and in every common style I've seen, a closing brace is
always on a line by itself. The only exception to this is the use, in
some styles (not mine), of "} else {".

> Other times the confusion was:
>
> if(long_condition)actual_do_something_off_right_si de();
> looks_like_conditional_but_not_do_something();
>
> I'm not saying this happened even once a week, but it happened often
> enough that I changed my style to avoid both of those, instead always
> putting braces on the expression following an if:
>
> if(condition){ do_something(); }


Personally, I almost always use braces for if, for, while, et al (a
habit I picked up from Perl, which requires them, but I think it's a
good idea regardless). I'll only omit the braces if the whole thing
fits on a single line *and* is clearer that way, so I'd write:

if (condition) do_something();

I'll violate my usual rules and write things on one line if there
are several consecutive similar statements, and aligning the code
vertically makes it easier to read:

if (condition1) do_something(1);
if (condition2) do_something(2);
if (condition3) do_something(3);

> But it turns out that while this eliminates the preceding issue, it is
> relatively easy for an errant key stroke to nip off the closing brace
> since it is the last character on the line, leading to the issue that
> started this thread. Particularly hard to see in long lines where the
> closing brace is often off the right of the screen. As others have
> noted, one can reduce the frequency of this issue by using the form:
>
> if(condition)
> {
> do_something();
> }
>
> which is fine in low density code, but is on the losing end of the
> readability tradeoff (in my opinion) in code that more closely
> resembles a table, like this:
>
> if(condition1){ a=1; b=2; c=3; /*more terms*/ }
> else if(condition2){ a=1; b=0; c=3; /*more terms*/ }
> else if(condition3){ a=1; b=2; c=0; /*more terms*/ }
> /*etc.*/


There I would have aligned the "{"s, and possibly the conditions:

if (condition1) { a=1; b=2; c=3; /*more terms*/ }
else if (condition2) { a=1; b=0; c=3; /*more terms*/ }
else if (condition3) { a=1; b=2; c=0; /*more terms*/ }

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Michael Press
Guest
Posts: n/a
 
      05-12-2011
In article <(E-Mail Removed)>,
Kenneth Brody <(E-Mail Removed)> wrote:

> On 5/12/2011 11:44 AM, David Mathog wrote:
> [...]
> > which is not at all the same thing. Other times the confusion was:
> >
> > if(long_condition)actual_do_something_off_right_si de();
> > looks_like_conditional_but_not_do_something();

> [...]
>
> Or worse, and harder to spot;
>
> for(foo;bar;baz);
> not_part_of_the_for_loop();


Hence for(tom; dick; harry) { }

--
Michael Press
 
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
How to add a underscore to indicate users what is the shorcut key of Button? ABC ASP .Net 1 04-22-2006 11:44 AM
validation - indicate invalid field Niclas ASP .Net 1 04-02-2006 04:31 PM
Can you still indicate to distribute files locally in ASP.Net 2.0 =?Utf-8?B?Sm9obiBCYWlsZXk=?= ASP .Net 0 06-15-2005 11:19 PM
LibXML UTF8 - Input is not proper UTF-8, indicate encoding ! Vlajko Knezic Perl 1 03-06-2005 08:53 AM
Can someone indicate me the following Newsgroups, please? Miguel Dias Moura ASP .Net 0 05-24-2004 03:18 PM



Advertisments