Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #76408 > unrolled thread

Program to print the longest line

Back to article view | Back to comp.lang.c

Contents

  Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 08:10 -0800
    Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-18 08:49 -0800
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 09:03 -0800
      Re: Program to print the longest line Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 09:04 -0800
        Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-18 09:24 -0800
    Re: Program to print the longest line Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 17:42 +0000
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 10:49 -0800
        Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:55 -0500
          Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 11:01 -0800
            Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-18 14:19 -0500
              Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 21:50 -0800
                Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-19 06:39 -0500
                  Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-19 05:07 -0800
                    Re: Program to print the longest line James Kuyper <jameskuyper@verizon.net> - 2015-11-19 10:12 -0500
                      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-19 07:49 -0800
        Re: Program to print the longest line Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 19:08 +0000
      Re: Program to print the longest line Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-18 14:54 -0500
        Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 23:36 -0800
          Re: Program to print the longest line Keith Thompson <kst-u@mib.org> - 2015-11-19 21:15 -0800
            Re: Program to print the longest line Geoff <geoff@invalid.invalid> - 2015-11-19 21:29 -0800
            Re: Program to print the longest line David Brown <david.brown@hesbynett.no> - 2015-11-20 11:00 +0100
              Re: Program to print the longest line glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 15:13 +0000
              Re: Program to print the longest line supercat@casperkitty.com - 2015-11-20 11:29 -0800
              Re: Program to print the longest line Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 12:51 -0800
                Re: Program to print the longest line Philip Lantz <prl@canterey.us> - 2015-11-24 01:59 -0800
                  Re: Program to print the longest line Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 13:34 -0800
    Re: Program to print the longest line John Gordon <gordon@panix.com> - 2015-11-18 18:10 +0000
      Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 10:53 -0800
        Re: Program to print the longest line Barry Schwarz <schwarzb@dqel.com> - 2015-11-18 13:55 -0800
          Re: Program to print the longest line Alla _ <modelling.data@gmail.com> - 2015-11-18 23:32 -0800
    Re: Program to print the longest line Barry Schwarz <schwarzb@dqel.com> - 2015-11-18 11:58 -0800

Page 2 of 2 — ← Prev page 1 [2]

#76609

On 20/11/15 06:15, Keith Thompson wrote:
> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>>>>
>>>> int getline(char line[], int maxline);
>>>
>>> FWIW, K&R1 page 26 gives
>>>   getline(s, lim)
>>>   char s[];
>>>   int lim;
>>>   {
>>>    ...
>>>
>>> It looks here like _Alla is trying to rewrite K&R2 code to match
>>> something the equivalent K&R1 code.
>>>
>> <snip>
>>
>> No ) I was trying to follow the rules I have learned - prototypes 
>> and function definitions should have consistent names of variables;
>> this is the only reason why (and what) I have dared to changed in this
>> program.
>> Keith has explained my mistake, and now I know, but will follow the 
>> "rule" of being consistent; I believe it adds up to readability of any
>> code, and to beauty of it. 
> 
> I just checked my copy of K&R2.  It does indeed use different parameter
> names in the declaration and in the definition.  I have no idea why; I
> can't think of any good reason for it -- but as I've said it's perfectly
> legal.  (It might have been useful as a way to illustrate that very
> point, but there's no explicit mention of it.)
> 

It would seem strange that they would want to illustrate it as a point.
 In my opinion, the ability to use different parameter names is a flaw,
not a feature - I can't think of any conceivable use for it.  (I can
accept that it is a convenience to compiler writers that don't have to
check the names, and that it is a convenience to programmers who don't
have functions declared in headers properly.)

[toc] | [prev] | [next] | [standalone]

#76639

David Brown <david.brown@hesbynett.no> wrote:
> On 20/11/15 06:15, Keith Thompson wrote:

(snip on variable names in function prototypes)

>> I just checked my copy of K&R2.  It does indeed use different parameter
>> names in the declaration and in the definition.  I have no idea why; I
>> can't think of any good reason for it -- but as I've said it's perfectly
>> legal.  (It might have been useful as a way to illustrate that very
>> point, but there's no explicit mention of it.)
 
> It would seem strange that they would want to illustrate it as a point.
> In my opinion, the ability to use different parameter names is a flaw,
> not a feature - I can't think of any conceivable use for it.  (I can
> accept that it is a convenience to compiler writers that don't have to
> check the names, and that it is a convenience to programmers who don't
> have functions declared in headers properly.)

If they are in different files, the compiler won't see them
at the same time. 

If the names are nmemonic, it is probably nice to have them match,
though.

-- glen

[toc] | [prev] | [next] | [standalone]

#76661

On Friday, November 20, 2015 at 4:01:06 AM UTC-6, David Brown wrote:
>  In my opinion, the ability to use different parameter names is a flaw,
> not a feature - I can't think of any conceivable use for it.

It may at times be useful with function pointers, in cases where a function
receives a callback and one or two void* arguments which are simply passed
through to the callback.  In the function-pointer-type definition, it may
make sense to call such pointers "extra1" and "extra2" (using names that
match the parameters of the function which will use the callback) but
the definitions of the functions invoked through the pointer might benefit
from using names which describe the purpose of the passed-in pointers, or
else use names like "dummy1" and "dummy2" if they are not used for anything.

[toc] | [prev] | [next] | [standalone]

#76669

David Brown <david.brown@hesbynett.no> writes:

> On 20/11/15 06:15, Keith Thompson wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>> <snip>
>>>
>>>>> int getline(char line[], int maxline);
>>>>
>>>> FWIW, K&R1 page 26 gives
>>>>   getline(s, lim)
>>>>   char s[];
>>>>   int lim;
>>>>   {
>>>>    ...
>>>>
>>>> It looks here like _Alla is trying to rewrite K&R2 code to match
>>>> something the equivalent K&R1 code.
>>>
>>> <snip>
>>>
>>> No ) I was trying to follow the rules I have learned - prototypes
>>> and function definitions should have consistent names of variables;
>>> this is the only reason why (and what) I have dared to changed in
>>> this program.

>>> Keith has explained my mistake, and now I know, but will follow
>>> the "rule" of being consistent;  I believe it adds up to
>>> readability of any code, and to beauty of it.
>>
>> I just checked my copy of K&R2.  It does indeed use different
>> parameter names in the declaration and in the definition.  I have
>> no idea why;  I can't think of any good reason for it -- but as
>> I've said it's perfectly legal.  (It might have been useful as a
>> way to illustrate that very point, but there's no explicit
>> mention of it.)
>
> It would seem strange that they would want to illustrate it as a
> point.  In my opinion, the ability to use different parameter
> names is a flaw, not a feature - I can't think of any conceivable
> use for it.  [...]

There is an obvious one - choose a longer and more descriptive
name for the interface, and a shorter (but still adequately
descriptive) name for the implementation.  I've been trying out
this technique recently (in another language, not C, but the idea
is the same), and find the results quite good.

[toc] | [prev] | [next] | [standalone]

#77068

Tim Rentsch wrote:
> David Brown writes:
> > Keith Thompson wrote:
> >> Alla _ writes:
> >>>
> >>>>> int getline(char line[], int maxline);
> >>>>
> >>>> FWIW, K&R1 page 26 gives
> >>>>   getline(s, lim)
> >>>>   char s[];
> >>>>   int lim;
> >>>>   {
> >>>>    ...
> >>>>
> >>>> It looks here like _Alla is trying to rewrite K&R2 code to match
> >>>> something the equivalent K&R1 code.
> >>>
> >>> No ) I was trying to follow the rules I have learned - prototypes
> >>> and function definitions should have consistent names of variables;
> >>> this is the only reason why (and what) I have dared to changed in
> >>> this program.
> 
> >>> Keith has explained my mistake, and now I know, but will follow
> >>> the "rule" of being consistent;  I believe it adds up to
> >>> readability of any code, and to beauty of it.
> >>
> >> I just checked my copy of K&R2.  It does indeed use different
> >> parameter names in the declaration and in the definition.  I have
> >> no idea why;  I can't think of any good reason for it -- but as
> >> I've said it's perfectly legal.  (It might have been useful as a
> >> way to illustrate that very point, but there's no explicit
> >> mention of it.)
> >
> > It would seem strange that they would want to illustrate it as a
> > point.  In my opinion, the ability to use different parameter
> > names is a flaw, not a feature - I can't think of any conceivable
> > use for it.  [...]
> 
> There is an obvious one - choose a longer and more descriptive
> name for the interface, and a shorter (but still adequately
> descriptive) name for the implementation.  I've been trying out
> this technique recently (in another language, not C, but the idea
> is the same), and find the results quite good.

I agree. As another example, I on occasion do something like this:

In the header:
extern int some_descriptive_function_name(void *buf);

In the source file:
extern int some_descriptive_function_name(void *arg)
{
    unsigned char *buf = (unsigned char *)arg;
    // Use buf.
}

(I could probably come up with better names for the example, or dig
up a real example, but it's 2:00 AM; I think you get the idea.)

[toc] | [prev] | [next] | [standalone]

#77282

Philip Lantz <prl@canterey.us> writes:

> Tim Rentsch wrote:
>> David Brown writes:
>>> Keith Thompson wrote:
>>>> Alla _ writes:
>>>>>
>>>>>>> int getline(char line[], int maxline);
>>>>>>
>>>>>> FWIW, K&R1 page 26 gives
>>>>>>   getline(s, lim)
>>>>>>   char s[];
>>>>>>   int lim;
>>>>>>   {
>>>>>>    ...
>>>>>>
>>>>>> It looks here like _Alla is trying to rewrite K&R2 code to match
>>>>>> something the equivalent K&R1 code.
>>>>>
>>>>> No ) I was trying to follow the rules I have learned - prototypes
>>>>> and function definitions should have consistent names of variables;
>>>>> this is the only reason why (and what) I have dared to changed in
>>>>> this program.
>>>>>
>>>>> Keith has explained my mistake, and now I know, but will follow
>>>>> the "rule" of being consistent;  I believe it adds up to
>>>>> readability of any code, and to beauty of it.
>>>>
>>>> I just checked my copy of K&R2.  It does indeed use different
>>>> parameter names in the declaration and in the definition.  I have
>>>> no idea why;  I can't think of any good reason for it -- but as
>>>> I've said it's perfectly legal.  (It might have been useful as a
>>>> way to illustrate that very point, but there's no explicit
>>>> mention of it.)
>>>
>>> It would seem strange that they would want to illustrate it as a
>>> point.  In my opinion, the ability to use different parameter
>>> names is a flaw, not a feature - I can't think of any conceivable
>>> use for it.  [...]
>>
>> There is an obvious one - choose a longer and more descriptive
>> name for the interface, and a shorter (but still adequately
>> descriptive) name for the implementation.  I've been trying out
>> this technique recently (in another language, not C, but the idea
>> is the same), and find the results quite good.
>
> I agree.  As another example, I on occasion do something like this:
>
> In the header:
> extern int some_descriptive_function_name(void *buf);
>
> In the source file:
> extern int some_descriptive_function_name(void *arg)
> {
>     unsigned char *buf = (unsigned char *)arg;
>     // Use buf.
> }
>
> (I could probably come up with better names for the example, or dig
> up a real example, but it's 2:00 AM;  I think you get the idea.)

Ah ha.  Good example.

[toc] | [prev] | [next] | [standalone]

#76433

In <8a605c3e-2e2d-456f-bcf4-f23bf4c40bc2@googlegroups.com> Alla _ <modelling.data@gmail.com> writes:

> int getline (char s[], int lim);
> // this is how this line looked before I changed it:
> int getline{char line[], int maxline); 

Is that really how it looked?  The "{" is likely your typo.  Please do not
type code in from memory.

Typos aside, the only difference between those two prototypes is in
the names of the arguments, which does not matter here.

Since you are including stdio.h, you may be conflicting with a library
function also named getline().  Please consider renaming this function.
(This may the root of your problem, although if so, I'm puzzled why you
did not receive a compilation error.)

> Do I understand correctly the following:

> 1) although the array "line" has yet nothing in it, when the array name 
> "line" is passed into getline() function, the function receives an
> address to the first character of the array; hence the function "knows" where 
> to store its input; therefore,  an empty array is passed to the function, 
> or to be more precise, the address of an empty array to be filled in by

That's correct, with the exception that "line" is not empty.  You haven't
stored anything meaningful in it yet, but that's not the same.

> If yes, then it's not clear to me. Getline() returns only one i, hence
> len is always equal to that i (the condition of no input is never even 
> checked), and is always bigger than 0. How does the loop ever terminate? 

No, len is not always bigger than zero.  If the function is called after
end of input has already been reached, the string is immediately
null-terminated at zero length, and zero is returned.

> And, I don't see any update of the while loop; what is the base for iteration?

The loop continues executing as long as getline() returns a nonzero value.

> // I am flummoxed by this condition:

> i < lim - 1 && (c = getchar()) != EOF && c != '\n'

> = until i is less then MAXLINE AND the EOF is not valid AND ENTER has not
> been hit. 

> Shouldn't || OR be instead of && as in:

> i < lim - 1 && c != '\n' || (c = getchar()) != EOF 

No, it should not be OR.  If written this way, the loop would never
terminate, because no matter what value c has, it would necessarily be
unequal to \n or unequal to EOF.  (If c is \n then it's unequal to
EOF; if it's EOF then it's unequal to \n; and any other value is unequal
to both.)

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#76437

On Wednesday, November 18, 2015 at 10:11:13 PM UTC+4, John Gordon wrote:
> In <8a605c3e-2e2d-456f-bcf4-f23bf4c40bc2@googlegroups.com> Alla _ <modelling.data@gmail.com> writes:
> 
> > int getline (char s[], int lim);
> > // this is how this line looked before I changed it:
> > int getline{char line[], int maxline); 
> 
> Is that really how it looked?  The "{" is likely your typo.  Please do not
> type code in from memory.
> 
Yes, my bad, and I missed it, and, even more, have just repeated that
typo. When I quote the code here, I usually look at it and type it in from the 
book or online source. But to practice, I try to type the code from 
memory when I create files for my own use. 

[toc] | [prev] | [next] | [standalone]

#76462

On Wed, 18 Nov 2015 10:53:04 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>Yes, my bad, and I missed it, and, even more, have just repeated that
>typo. When I quote the code here, I usually look at it and type it in from the 
>book or online source. But to practice, I try to type the code from 
>memory when I create files for my own use. 

Memory works much differently for things you understand compared to
things you are just learning.  Since you are asking fundamental
questions, it is obvious your understanding is incomplete.  Make life
easy on yourself (and us) and use every reference you have as much as
possible.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#76492

On Thursday, November 19, 2015 at 1:55:34 AM UTC+4, Barry Schwarz wrote:
> On Wed, 18 Nov 2015 10:53:04 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
> >Yes, my bad, and I missed it, and, even more, have just repeated that
> >typo. When I quote the code here, I usually look at it and type it in from the 
> >book or online source. But to practice, I try to type the code from 
> >memory when I create files for my own use. 
> 
> Memory works much differently for things you understand compared to
> things you are just learning.  Since you are asking fundamental
> questions, it is obvious your understanding is incomplete.  Make life
> easy on yourself (and us) and use every reference you have as much as
> possible.
> 
Thank you. I will do my best not cause this type of troubles anymore. 
Referring to you previous post, yes, it is from page 29 but 2nd edition. 
I read it on my kindle cloud. 

[toc] | [prev] | [next] | [standalone]

#76453

On Wed, 18 Nov 2015 08:10:12 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>Hello!
>
>I am doing my best to understand each program presented in the book
>I study now. I get surprise after surprise :) I didn't think, though, that
>I am at such a low level of knowledge :)
>
>Please, find my questions within the body of the program.
>To discern my comments from the ones coming with the program,
>I surround my ones with //  //.

This program is from K&R page 29.  Your previous thread was about
exercise 1.10 on page 20.  You are racing ahead faster than your
understanding.  Since you have fundamental misunderstandings about the
earlier program, you should not be moving on until they are resolved. 
Slow down.  The object of the exercise is not to finish quickly but to
achieve a firm understanding.  If you build a house without a solid
foundation, it will not stand.  In programming, the basic concepts are
that foundation

-- 
Remove del for email

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web