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

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

Issues with setting variables to true or false: how does the compiler understands it

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

Contents

  Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 02:17 -0700
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 03:29 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 03:38 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 04:30 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-24 12:04 +0000
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 04:59 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 14:28 +0100
        Re: Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 07:26 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:06 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it James Kuyper <jameskuyper@verizon.net> - 2015-10-24 11:56 -0400
      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:02 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 15:45 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 16:28 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 16:44 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:34 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:30 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 20:33 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 11:16 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-28 15:12 -0400
                Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 12:18 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:51 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:38 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 05:34 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-28 14:08 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 06:14 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:50 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 15:08 -0700
                  Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 22:47 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 18:35 -0500
                      Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:12 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-29 01:35 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 21:12 -0500
                          Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 19:52 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:01 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 03:47 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-24 09:54 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:13 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:50 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 04:04 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-25 08:32 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:19 +0000
        Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 11:30 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:56 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 20:59 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-25 21:49 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 08:10 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-26 16:05 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 00:34 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:04 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 18:16 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:33 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:08 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 11:22 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 11:35 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:00 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:59 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 07:55 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:06 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-26 10:56 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:14 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 17:09 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-26 23:39 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 12:31 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 12:45 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:41 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 19:43 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 19:47 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 13:20 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:28 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:54 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 07:51 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 16:46 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 10:52 -0700
                          Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 18:51 +0000
                            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 12:17 -0700
                              Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 19:34 +0000
                                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:10 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 13:41 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 23:11 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 19:02 -0700
                                      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-28 07:09 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 11:27 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 12:27 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:18 -0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#73776

On 25/10/15 15:32, Barry Schwarz wrote:

<snip>

> While the goal of the program was JSON output, your questions did not
> address that aspect at all.

I thought the goal was to help Alla to learn C?

> Your questions showed a misunderstanding
> of some fundamental aspects of programming in C,

That is to be expected in someone new to C.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73777

On Sunday, October 25, 2015 at 7:32:52 PM UTC+4, Barry Schwarz wrote:
> On Sun, 25 Oct 2015 04:04:50 -0700 (PDT), Alla _
> <modelling.data@gmail.com> wrote:
> 
> >Thank you Everyone for your help. 
> >To be honest, I didn't read articles 
> >containing profound discussions on JSON,
> >because this is too early for me. 
> >Thank you for clearing the topic on
> >these shortcuts.
> 
> While the goal of the program was JSON output, your questions did not
> address that aspect at all.  Your questions showed a misunderstanding
> of some fundamental aspects of programming in C, particularly looping,
> if statements, and the difference between events that occur at compile
> time versus execution time.
> 
> -- 
> Remove del for email

True. Doing my best to solve this ) 
Still hope for the day when fundamentals
settle down in my mind. 

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

#73781

On 25/10/15 18:30, Alla _ wrote:

<snip>

> True. Doing my best to solve this )
> Still hope for the day when fundamentals
> settle down in my mind.

You have already covered enough features of the language to enable you 
to write some quite powerful programs. There's still much to learn, but 
this might be a good time to take stock of what you have learned so far, 
and spend a couple of weeks just writing programs, rather than trying to 
learn new features.

For example:

Write a program that displays only the first n lines of its input.

Write a program that displays only the /last/ n lines of its input. 
(Harder.)

Write a program that displays only the leftmost n characters of each 
input line.

Write a program that displays only the rightmost n characters of each 
input line. (Harder!)

Write a program that displays only characters in columns x to y of each 
input line.

Write a program that displays every other character of its input (either 
the 1st, 3rd, 5th, 7th etc or the 2nd, 4th, 6th, 8th etc at the user's 
discretion).

Write a program that displays every input line /backwards/.

Write a program that displays input lines only if they contain a search 
string entered by the user.

Write a program that displays input lines only if they do not contain a 
search string entered by the user.

Write a program that displays all possible arrangements of the notes of 
the C major scale (C D E F G A B), using each note once only (except C 
which you use twice) that begin and end on C.

Write a program to create a Web page, using the first line of input as 
the title text and the remainder as a body paragraph. (Use the W3C 
online checker to ensure that the resulting HTML is 100% correct.)

Write a program to play out the Monty Hall scenario a million times and 
find out for yourself whether you should switch doors.

Write a program that calculates the likelihood that the attacker will 
win a Risk battle, for all possible attacker and defender army sizes 
from 1 to 20.

Write a program to determine the probability of landing on "Go to Jail" 
in one trip around the Monopoly board.

Write a program that plays a decent game of Pontoon - i.e. actually 
assesses the relative merits of sticking, buying another card, or 
twisting, and decides accordingly.

ALL of these programs could be written using just the features of C that 
you have already encountered. None of them is terribly difficult. Each 
of them will help you to consolidate what you already know about C 
before you push on to learn any more new features.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73820

On Sunday, October 25, 2015 at 10:56:57 PM UTC+4, Richard Heathfield wrote:
> On 25/10/15 18:30, Alla _ wrote:
> 
> <snip>
> 
> > True. Doing my best to solve this )
> > Still hope for the day when fundamentals
> > settle down in my mind.
> 
> You have already covered enough features of the language to enable you 
> to write some quite powerful programs. There's still much to learn, but 
> this might be a good time to take stock of what you have learned so far, 
> and spend a couple of weeks just writing programs, rather than trying to 
> learn new features.
> 
> For example:
> 
> Write a program that displays only the first n lines of its input.
> 
> Write a program that displays only the /last/ n lines of its input. 
> (Harder.)
> 
> Write a program that displays only the leftmost n characters of each 
> input line.
> 
> Write a program that displays only the rightmost n characters of each 
> input line. (Harder!)
> 
> Write a program that displays only characters in columns x to y of each 
> input line.
> 
> Write a program that displays every other character of its input (either 
> the 1st, 3rd, 5th, 7th etc or the 2nd, 4th, 6th, 8th etc at the user's 
> discretion).
> 
> Write a program that displays every input line /backwards/.
> 
> Write a program that displays input lines only if they contain a search 
> string entered by the user.
> 
> Write a program that displays input lines only if they do not contain a 
> search string entered by the user.
> 
> Write a program that displays all possible arrangements of the notes of 
> the C major scale (C D E F G A B), using each note once only (except C 
> which you use twice) that begin and end on C.
> 
> Write a program to create a Web page, using the first line of input as 
> the title text and the remainder as a body paragraph. (Use the W3C 
> online checker to ensure that the resulting HTML is 100% correct.)
> 
> Write a program to play out the Monty Hall scenario a million times and 
> find out for yourself whether you should switch doors.
> 
> Write a program that calculates the likelihood that the attacker will 
> win a Risk battle, for all possible attacker and defender army sizes 
> from 1 to 20.
> 
> Write a program to determine the probability of landing on "Go to Jail" 
> in one trip around the Monopoly board.
> 
> Write a program that plays a decent game of Pontoon - i.e. actually 
> assesses the relative merits of sticking, buying another card, or 
> twisting, and decides accordingly.
> 
> ALL of these programs could be written using just the features of C that 
> you have already encountered. None of them is terribly difficult. Each 
> of them will help you to consolidate what you already know about C 
> before you push on to learn any more new features.
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

Richard, thank you very much! 
This is interesting and very helpful.
Yes, I will do that. I also now try to write
some programs suggested by the course and 
the book (the book is much more troublesome, 
I am skipping a lot there until later). 
Will be posting questions. 

I agree with all that's been said by everyone
helping me here about my fast and unproductive pace,
and that it doesn't make sense learning
advanced features until I firmly understand
what I have already learned.

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

#73821

On Sunday, October 25, 2015 at 10:59:49 PM UTC-5, Alla _ wrote:
> On Sunday, October 25, 2015 at 10:56:57 PM UTC+4, Richard Heathfield wrote:
> > On 25/10/15 18:30, Alla _ wrote:
> > 
> > <snip>
> > 
> > > True. Doing my best to solve this )
> > > Still hope for the day when fundamentals
> > > settle down in my mind.
> > 
> > You have already covered enough features of the language to enable you 
> > to write some quite powerful programs. There's still much to learn, but 
> > this might be a good time to take stock of what you have learned so far, 
> > and spend a couple of weeks just writing programs, rather than trying to 
> > learn new features.
> > 
> > For example:
> > 
(...)
> 
> Richard, thank you very much! 
> This is interesting and very helpful.
> Yes, I will do that. I also now try to write
> some programs suggested by the course and 
> the book (the book is much more troublesome, 
> I am skipping a lot there until later). 
> Will be posting questions. 
> 
> I agree with all that's been said by everyone
> helping me here about my fast and unproductive pace,
> and that it doesn't make sense learning
> advanced features until I firmly understand
> what I have already learned.


Many of Richard's exercises require you to process input.  It is quite difficult to process input using C.  Suggest you postpone those for now.

- Anand

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

#73828

On 26/10/15 04:49, Anand Hariharan wrote:

<snip>

> Many of Richard's exercises require you to process input.  It is quite difficult to process input using C.

It isn't as hard as you make out. And there is only a very limited 
amount one can do /without/ processing input. After all, the whole 
/point/ of a program is to turn input into output!

 > Suggest you postpone those for now.

Then make some better suggestions for practice programs, ones that don't 
involve processing input.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73918

On Monday, October 26, 2015 at 3:11:17 AM UTC-5, Richard Heathfield wrote:
> On 26/10/15 04:49, Anand Hariharan wrote:
> 
> <snip>
> 
> > Many of Richard's exercises require you to process input.  It is quite difficult to process input using C.
> 
> It isn't as hard as you make out.

I'd say it is.  I'd say there are people whom YOU consider as experts (I am NOT including me as one of them) who would say it is.

How long did you take to write your freadline (or fgetline or read-indefintely-long-line) library?  It would take me several hours to write one on my own and even when I declare "I'm done", not only would it still have warts, I would suspect it could fail in obscure cases and/or suspect it could potentially leak.  Such is the beast that is C.


> And there is only a very limited 
> amount one can do /without/ processing input. After all, the whole 
> /point/ of a program is to turn input into output!
> 

The 'input' could be hard-coded into the program.  I'd get a beginner to write loops correctly first. Focus on overall program design and logic.

Ben Bacarisse made a point similar to mine elsethread and you received it quite warmly.  Either he made his point much better than I (likely, since he made it clear he was referring to *interactive* input) or it matters to you as to who makes the statement.


>  > Suggest you postpone those for now.
> 
> Then make some better suggestions for practice programs, ones that don't 
> involve processing input.
> 

I said *Many* of your exercises, not /All/ of them.  Of the ones you proposed , I'd suggest these to OP (sorry can't get Google to quote individual lines):

<quote>
Write a program that displays all possible arrangements of the notes of
the C major scale (C D E F G A B), using each note once only (except C
which you use twice) that begin and end on C.

Write a program to create a Web page, using the first line of input as
the title text and the remainder as a body paragraph. (Use the W3C
online checker to ensure that the resulting HTML is 100% correct.)

Write a program to play out the Monty Hall scenario a million times and
find out for yourself whether you should switch doors.

Write a program that calculates the likelihood that the attacker will
win a Risk battle, for all possible attacker and defender army sizes
from 1 to 20.

Write a program to determine the probability of landing on "Go to Jail"
in one trip around the Monopoly board.

Write a program that plays a decent game of Pontoon - i.e. actually
assesses the relative merits of sticking, buying another card, or
twisting, and decides accordingly.
</quote>

The following ones (even though it involves processing input) can be taken up as well:

<quote>
Write a program that displays only the first n lines of its input.

Write a program that displays only the leftmost n characters of each
input line.

Write a program that displays only characters in columns x to y of each
input line. 
</quote>

- Anand

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

#73926

Anand Hariharan <mailto.anand.hariharan@gmail.com> writes:

> On Monday, October 26, 2015 at 3:11:17 AM UTC-5, Richard Heathfield wrote:
>> On 26/10/15 04:49, Anand Hariharan wrote:
>> 
>> <snip>
>> 
>> > Many of Richard's exercises require you to process input.  It is
>> > quite difficult to process input using C.
>> 
>> It isn't as hard as you make out.
>
> I'd say it is.  I'd say there are people whom YOU consider as experts
> (I am NOT including me as one of them) who would say it is.

I think it very much depends on the particular program.  Some IO can be
very fiddly in C and some can be simple.  For example, one exercise,
common to Richard's set and mine -- essentially a simple version of the
head utility -- can be written a few lines.  Spoiler alert: I've put one
possible solution at the end.

<snip>
>> And there is only a very limited 
>> amount one can do /without/ processing input. After all, the whole 
>> /point/ of a program is to turn input into output!
>> 
>
> The 'input' could be hard-coded into the program.  I'd get a beginner
> to write loops correctly first. Focus on overall program design and
> logic.

Yes, but the options are very limited for writing interesting programs
when all the data is internal.  I liked it when using graphics because,
often, that "data" has an internal logic that flows from what is being
drawn; and when it does not it is often arbitrary (e.g. the spiral
"looks good" if grown by a factor of 1.3 per cycle, say).

> Ben Bacarisse made a point similar to mine elsethread and you received
> it quite warmly.  Either he made his point much better than I (likely,
> since he made it clear he was referring to *interactive* input) or it
> matters to you as to who makes the statement.

Yes, interactive input -- properly and safely done -- is a real pain in
many languages but certainly it is in C.  I recall suggesting that Alla
simply make a "best effort" attempt to get data and be done with it.
But I don't think Richard's exercises were intended to require
interactive input.

<snip>

head:
This version (in C >= 1999) deliberately avoids anything but the IO.
There's no detection of errors, but that's deliberate.

  #include <stdio.h>
  #include <stdlib.h>
   
  int main(int argc, char **argv)
  {
       if (argc == 2) {
            int c, n_lines = atoi(argv[1]);
            while (n_lines > 0 && (c = getchar()) != EOF) {
                 putchar(c);
                 n_lines -= c == '\n';
            }
       }
  }

-- 
Ben.

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

#73971

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> head:
> This version (in C >= 1999) deliberately avoids anything but the IO.
> There's no detection of errors, but that's deliberate.
>
>   #include <stdio.h>
>   #include <stdlib.h>
>    
>   int main(int argc, char **argv)
>   {
>        if (argc == 2) {
>             int c, n_lines = atoi(argv[1]);
>             while (n_lines > 0 && (c = getchar()) != EOF) {
>                  putchar(c);
>                  n_lines -= c == '\n';
>             }
>        }
>   }

You say "C >= 1999".  The only thing that requires C99 or later is the
assumption that falling off the end of main() is equivalent to
"return 0;".  Did you have anything else in mind?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#74014

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> head:
>> This version (in C >= 1999) deliberately avoids anything but the IO.
>> There's no detection of errors, but that's deliberate.
>>
>>   #include <stdio.h>
>>   #include <stdlib.h>
>>    
>>   int main(int argc, char **argv)
>>   {
>>        if (argc == 2) {
>>             int c, n_lines = atoi(argv[1]);
>>             while (n_lines > 0 && (c = getchar()) != EOF) {
>>                  putchar(c);
>>                  n_lines -= c == '\n';
>>             }
>>        }
>>   }
>
> You say "C >= 1999".  The only thing that requires C99 or later is the
> assumption that falling off the end of main() is equivalent to
> "return 0;".  Did you have anything else in mind?

No, just that.  I think it's nicer to have an implicit return 0 when the
code is not written to take errors into account.  I know the effect is
identical.

-- 
Ben.

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

#73927

On Monday, October 26, 2015 at 11:05:30 PM UTC, Anand Hariharan wrote:
> On Monday, October 26, 2015 at 3:11:17 AM UTC-5, Richard Heathfield wrote:
> > On 26/10/15 04:49, Anand Hariharan wrote:
> > 
> > <snip>
> > 
> > > Many of Richard's exercises require you to process input.  It is quite difficult to process input using C.
> > 
> > It isn't as hard as you make out.
> 
> I'd say it is.  I'd say there are people whom YOU consider as experts (I am NOT including me as one of them) who would say it is.
> 
> How long did you take to write your freadline (or fgetline or 
> read-indefintely-long-line) library?  It would take me several
> hours to write one on my own and even when I declare "I'm done",
> not only would it still have warts, I would suspect it could fail
> in obscure cases and/or suspect it could potentially leak.  Such 
> is the beast that is C.
> 
You have to know the tricks.

char *fgetline(FILE *fp, int *err)
{
   int ch;
   char *answer = 0;
   char *temp;
   size_t bufsize = 0;
   size_t len = 0;

   while( (ch = fgetc(fp)) != EOF)
   {
     if(len +1 >= bufsize)
     {
        if(bufsize > bufsize + bufsize/2 + 32)
          goto out_of_memory;
        temp = realloc(answer, bufsize + bufsize/2 + 32);
        if(!temp)
          goto out_of_memory;
      
        bufsize = bufsize + bufsize/2 + 32;
     }
     answer[len++] = ch;
   if(ch == '\n')
        break;
   }
   if(err)
     *err = ferror(fp) ? -2 : 0;
   answer[len] = 0;
   return answer;

out_of_memory:
   if(err)
     *err = -1;
   free(answer);
   return 0;
}

That's untested, just written off pat.

But there are lots of gotchas.

You have to know the pattern while ( (ch = fgetc(fp)) != EOF)
just use that, all the time and routinely, for reading characters
from a stream.
The loop breaks when EOF is reached, or on error. So you need to 
call ferror to distinguish between the two.
The buffer needs to grow by a factor between about 1 1/3 and 2,
but if you start from 0, you need to add a small constant. And#
you need to realloc to a temporary, to avoid a memory leak on
failure.
The sizes have to be size_t, which is unsigned. So the condition
has to be be written in an odd way to cover zero, and it's len +1
to count the nul.

 

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

#73930

On 26/10/15 23:05, Anand Hariharan wrote:
> On Monday, October 26, 2015 at 3:11:17 AM UTC-5, Richard Heathfield wrote:
>> On 26/10/15 04:49, Anand Hariharan wrote:
>>
>> <snip>
>>
>>> Many of Richard's exercises require you to process input.  It is quite difficult to process input using C.
>>
>> It isn't as hard as you make out.
>
> I'd say it is.

And I'd say it isn't.

> I'd say there are people whom YOU consider as experts
 > (I am NOT including me as one of them) who would say it is.

And I'd say you're probably right. And I'd disagree with them.

> How long did you take to write your freadline
 > (or fgetline or read-indefintely-long-line) library?

That was a very long time ago, and I don't recall. A few minutes, maybe 
- half an hour tops. Nor is it relevant as far as I can see.

> It would take me several hours to write one on my own
 > and even when I declare "I'm done", not only would it
 > still have warts, I would suspect it could fail in
 > obscure cases and/or suspect it could potentially leak.
 > Such is the beast that is C.

Yes, but we're talking about student programs, the intent of which is to 
give the student practice in learning basic concepts. We're not talking 
about rock-solid, bullet-proof, shrinkwrap-ready software.

>> And there is only a very limited
>> amount one can do /without/ processing input. After all, the whole
>> /point/ of a program is to turn input into output!
>
> The 'input' could be hard-coded into the program.
 > I'd get a beginner to write loops correctly first.
 > Focus on overall program design and logic.

It may surprise you to hear it, but I'm coming around to that point of 
view myself (in the present case, at least).

> Ben Bacarisse made a point similar to mine elsethread
 > and you received it quite warmly.  Either he made his
 > point much better than I (likely, since he made it
 > clear he was referring to *interactive* input)

Although his point was similar, it was not identical. And yes, he made 
his point very well.

> or it
 > matters to you as to who makes the statement.

Yes, of course my reaction to a statement depends at least in part on 
who makes it. I'm human too. But it may surprise you to hear that you're 
on my good-guys list. I disagreed with you because I thought you were 
wrong. (And didn't you do the same thing? i.e. disagree with me because 
you thought I was wrong? That's allowed on Usenet!) But the more of 
Alla's code I read, the more I am coming around to the point of view 
that my suggested exercises are perhaps a bit of a stretch, and some 
simpler exercises are required.

>>   > Suggest you postpone those for now.
>>
>> Then make some better suggestions for practice programs, ones that don't
>> involve processing input.
>>
>
> I said *Many* of your exercises, not /All/ of them.  Of the ones you proposed , I'd suggest these to OP (sorry can't get Google to quote individual lines):
>
> <quote>
> Write a program that displays all possible arrangements of the notes of
> the C major scale (C D E F G A B), using each note once only (except C
> which you use twice) that begin and end on C.
>
> Write a program to create a Web page, using the first line of input as
> the title text and the remainder as a body paragraph. (Use the W3C
> online checker to ensure that the resulting HTML is 100% correct.)
>
> Write a program to play out the Monty Hall scenario a million times and
> find out for yourself whether you should switch doors.
>
> Write a program that calculates the likelihood that the attacker will
> win a Risk battle, for all possible attacker and defender army sizes
> from 1 to 20.
>
> Write a program to determine the probability of landing on "Go to Jail"
> in one trip around the Monopoly board.
>
> Write a program that plays a decent game of Pontoon - i.e. actually
> assesses the relative merits of sticking, buying another card, or
> twisting, and decides accordingly.
> </quote>
>
> The following ones (even though it involves processing input) can be taken up as well:
>
> <quote>
> Write a program that displays only the first n lines of its input.
>
> Write a program that displays only the leftmost n characters of each
> input line.
>
> Write a program that displays only characters in columns x to y of each
> input line.
> </quote>

Well then, quite a few survived after all. ;-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73972

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 26/10/15 23:05, Anand Hariharan wrote:
>> On Monday, October 26, 2015 at 3:11:17 AM UTC-5, Richard Heathfield wrote:
>>> On 26/10/15 04:49, Anand Hariharan wrote:
[...]
>> The 'input' could be hard-coded into the program.
>  > I'd get a beginner to write loops correctly first.
>  > Focus on overall program design and logic.
>
> It may surprise you to hear it, but I'm coming around to that point of 
> view myself (in the present case, at least).

Another approach I've seen is to provide the student(s) with a simple
set of input routines, perhaps including a function that reads the next
line from stdin and returns a pointer to an allocated string holding the
line with the '\n' stripped.  (Basically gets(), but safe.)  Memory
allocation and deallocation can be dealt with later.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#73844

Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> You have already covered enough features of the language to enable you
> to write some quite powerful programs. There's still much to learn,
> but this might be a good time to take stock of what you have learned
> so far, and spend a couple of weeks just writing programs, rather than
> trying to learn new features.
>
> For example:
>
> Write a program that displays only the first n lines of its input.

Part of the trouble with so many books teaching programming is that they
insist in interactive input.  The students write program that prompt for
input, the program reads is off it goes.  That seems to be the case
here.

Your exercises (and they are otherwise very well chosen) don't work so
well in that context.  For example, the "n" above has to come from the
same place as data whose lines are being read.  And then the output
clutters up the screen as the user types more input.  I think that in
order to set up and motivate this sort of exercise, the student needs to
know

(1) How to run programs (not write them) taking input from a file or a
    pipe.[1]

(2) How to get simple data (like your n) from command-line arguments.

The first is easy though not always easy for a self-learning student.
The second is not hard, but will involve a degree of hand-waving about
arrays and pointers at the start but you can process simple command-line
arguments using standard boilerplate code anyway.  The end result is
that the student can write tools that be combined in genuinely useful
ways.  After writing

  line-count    -- count the number of input lines
  head n        -- output only the first n lines of input
  match string  -- output only lines that contain the given string
  reverse       -- reverse the order of the lines in the input
  pick i j k... -- output only the numbered columns from each input line
  sort          -- sort the input by line

(all good exercises on their own) the student can then use these tools
to solve real problems.

> Write a program that displays only the /last/ n lines of its
> input. (Harder.)

I'd say that's a significant understatement unless you constrain the
problem with some fixed limits.

My preference was to use the "software tools" idea here too by asking
for a program to reverse the order of the input lines.  The last 10
lines can then obtained by

  <data reverse | head 10 | reverse

These exercises also build well one on another.  For example, if you
implement reverse by reading the whole file (this is where you introduce
dynamic allocation), sort becomes a very simple extension to that.

> Write a program that displays only the leftmost n characters of each
> input line.
>
> Write a program that displays only the rightmost n characters of each
> input line. (Harder!)
>
> Write a program that displays only characters in columns x to y of
> each input line.

My preference here would be to concentrate on "columns" -- parts of a
line separated by one or more spaces.  This lets the student build
slightly more useful programs.

  <data | pick 2 1 | sort | pick 1 2

sorts by the second column an then puts the two columns back in order.

<snip other good exercises that are in a different vein>

[1] The most annoying thing in student programs -- including a hard-
wired input file name, or prompting for the name of the file to use!

-- 
Ben.

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

#73845

[Alla - I hope you're reading this!]

On 26/10/15 11:22, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>> [...] this might be a good time to take stock of what you have learned
>> so far, and spend a couple of weeks just writing programs, rather than
>> trying to learn new features.
>>
>> For example:
>>
>> Write a program that displays only the first n lines of its input.
>
> Part of the trouble with so many books teaching programming is that they
> insist in interactive input.  The students write program that prompt for
> input, the program reads is off it goes.  That seems to be the case
> here.

You make an excellent point. I was assuming (and almost certainly 
*wrongly* assuming) knowledge of command line arguments and piped input.

<snip>

> [...]  After writing
>
>    line-count    -- count the number of input lines
>    head n        -- output only the first n lines of input
>    match string  -- output only lines that contain the given string
>    reverse       -- reverse the order of the lines in the input
>    pick i j k... -- output only the numbered columns from each input line
>    sort          -- sort the input by line
>
> (all good exercises on their own) the student can then use these tools
> to solve real problems.

Of course, these suggestions suffer from the same problem as mine - they 
are perhaps just a touch premature at this stage.

>> Write a program that displays only the /last/ n lines of its
>> input. (Harder.)
>
> I'd say that's a significant understatement unless you constrain the
> problem with some fixed limits.

What I had in mind was a maximum line length (say, 60 including the 
newline, and therefore 61 including the terminator, which would keep the 
output easily postable on Usenet), and a maximum number of lines (say, 
10) to remember. I didn't make that clear. (I was in ideas mode rather 
than details mode!)

> My preference was to use the "software tools" idea here too by asking
> for a program to reverse the order of the input lines.  The last 10
> lines can then obtained by
>
>    <data reverse | head 10 | reverse
>
> These exercises also build well one on another.  For example, if you
> implement reverse by reading the whole file (this is where you introduce
> dynamic allocation), sort becomes a very simple extension to that.

I think dynamic allocation is also a little premature.

<snip>

>> Write a program that displays only characters in columns x to y of
>> each input line.
>
> My preference here would be to concentrate on "columns" -- parts of a
> line separated by one or more spaces.  This lets the student build
> slightly more useful programs.

I would do both - starting with mine and progressing on to yours.

>
>    <data | pick 2 1 | sort | pick 1 2
>
> sorts by the second column an then puts the two columns back in order.
>
> <snip other good exercises that are in a different vein>
>
> [1] The most annoying thing in student programs -- including a hard-
> wired input file name, or prompting for the name of the file to use!

Yes, especially as (when prompting) you have to remember to rip out the 
newline.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73874

Richard Heathfield <rjh@cpax.org.uk> writes:

> [Alla - I hope you're reading this!]
>
> On 26/10/15 11:22, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>> [...] this might be a good time to take stock of what you have learned
>>> so far, and spend a couple of weeks just writing programs, rather than
>>> trying to learn new features.
>>>
>>> For example:
>>>
>>> Write a program that displays only the first n lines of its input.
>>
>> Part of the trouble with so many books teaching programming is that they
>> insist in interactive input.  The students write program that prompt for
>> input, the program reads is off it goes.  That seems to be the case
>> here.
>
> You make an excellent point. I was assuming (and almost certainly
> *wrongly* assuming) knowledge of command line arguments and piped
> input.
>
> <snip>
>
>> [...]  After writing
>>
>>    line-count    -- count the number of input lines
>>    head n        -- output only the first n lines of input
>>    match string  -- output only lines that contain the given string
>>    reverse       -- reverse the order of the lines in the input
>>    pick i j k... -- output only the numbered columns from each input line
>>    sort          -- sort the input by line
>>
>> (all good exercises on their own) the student can then use these tools
>> to solve real problems.
>
> Of course, these suggestions suffer from the same problem as mine -
> they are perhaps just a touch premature at this stage.

The first three included?  I wouldn't say so.  Alla has already written
a program that reads a line with fgets and looks for it in the strings
in an array.  Reading a line and looking for a given string in that line
is, if anything, a bit easier.

Anyway, I was not actually suggesting a program of work.  For one thing,
these exercises were the second half of a 12 week course.  In the first
half the students were given a very simple graphics library and they
wrote programs to draw pictures.  In that part they learned, first,
about decomposing programs into functions and then about simple
variables and about loops and so on.  They already had some facility
with structuring code when starting on string processing examples.

I suppose my only point was to put in a plea to have exercises that
seem to have some real utility.

<snip>
-- 
Ben.

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

#73891

On 26/10/15 17:00, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> [Alla - I hope you're reading this!]
>>
>> On 26/10/15 11:22, Ben Bacarisse wrote:
<snip>
>>
>>> [...]  After writing
>>>
>>>     line-count    -- count the number of input lines
>>>     head n        -- output only the first n lines of input
>>>     match string  -- output only lines that contain the given string
>>>     reverse       -- reverse the order of the lines in the input
>>>     pick i j k... -- output only the numbered columns from each input line
>>>     sort          -- sort the input by line
>>>
>>> (all good exercises on their own) the student can then use these tools
>>> to solve real problems.
>>
>> Of course, these suggestions suffer from the same problem as mine -
>> they are perhaps just a touch premature at this stage.
>
> The first three included?

Picky picky picky. :-) Sorry, I really need to learn to read at some 
point. It would be /so/ helpful.

<snip>

> I suppose my only point was to put in a plea to have exercises that
> seem to have some real utility.

I understand that point of view, and I suspect that it's one you share 
with bwk, which is perhaps why K&R2 is an excellent C tutorial but not a 
great programming tutorial.

One of the great benefits of academic exercises is that they /don't/ 
necessarily have much real utility. They can be written, learned from, 
and then thrown away.

The trouble with useful programs is that they are useful. (And you may 
quote me on that.)

A poorly-written, badly designed useful program will very often produce 
results that are less than ideal, but rather than go to the trouble of 
rewriting it *right now*, students will subconsciously tailor future 
tools so that they work with the existing (poorly-written, badly 
designed) tools - and you end up with something like MFC. ;-)

That temptation just doesn't exist with academic exercises. Having 
written a program to spit out every other character, one thinks, "Okay, 
that was great, I got it working; now, is it of any further use? No. 
Fine, so I can bin it." But if the student has written a program to, 
say, sort up to 30 lines of text (using something execrable such as 
Bubble Sort, no doubt), he may find himself restricting future tools to 
writing a maximum of 30 lines, for backward compatibility with mysort.

That's actually not a great example of what I mean, but it'll have to do 
because I'm too tired to think of a better one.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#73860

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 25/10/15 18:30, Alla _ wrote:
>
> <snip>
>
>> True. Doing my best to solve this )
>> Still hope for the day when fundamentals
>> settle down in my mind.
>
> You have already covered enough features of the language to enable you 
> to write some quite powerful programs. There's still much to learn, but 
> this might be a good time to take stock of what you have learned so far, 
> and spend a couple of weeks just writing programs, rather than trying to 
> learn new features.
>
> For example:
>
> Write a program that displays only the first n lines of its input.
>
> Write a program that displays only the /last/ n lines of its input. 
> (Harder.)
>
> Write a program that displays only the leftmost n characters of each 
> input line.
>
> Write a program that displays only the rightmost n characters of each 
> input line. (Harder!)
>
> Write a program that displays only characters in columns x to y of each 
> input line.
[...]

A number of these programs provide opportunities to think about corner
cases.  For example, if a program is asked to display the first or last
10 lines of its input, what should it do if there are only 5 lines?
What if there are *no* lines?

In such cases, I suggest that part of the exercise should be to define
the behavior unambiguously.  Sometime the answer may seem obvious but
it's still worth writing down.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#73875

Keith Thompson <kst-u@mib.org> writes:

> Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
>> Write a program that displays only the first n lines of its input.
>>
>> Write a program that displays only the /last/ n lines of its input. 
>> (Harder.)
>>
>> Write a program that displays only the leftmost n characters of each 
>> input line.
>>
>> Write a program that displays only the rightmost n characters of each 
>> input line. (Harder!)
>>
>> Write a program that displays only characters in columns x to y of each 
>> input line.
> [...]
>
> A number of these programs provide opportunities to think about corner
> cases.  For example, if a program is asked to display the first or last
> 10 lines of its input, what should it do if there are only 5 lines?
> What if there are *no* lines?
>
> In such cases, I suggest that part of the exercise should be to define
> the behavior unambiguously.  Sometime the answer may seem obvious but
> it's still worth writing down.

That's a very useful skill.  When I was teaching, I made that part of
the exercise.  Part of the grade was for specifying the problem well
enough to be able know if the code was correct or not, and the code was
marked against the student's specification, and not the one I might
originally have had in my head.

-- 
Ben.

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

#73890

On Monday, October 26, 2015 at 9:55:55 AM UTC-5, Keith Thompson wrote:
> A number of these programs provide opportunities to think about corner
> cases.  For example, if a program is asked to display the first or last
> 10 lines of its input, what should it do if there are only 5 lines?
> What if there are *no* lines?

In many cases, it can be helpful to have multiple library functions whose
behavior in "normal" cases is identical, but whose behavior in corner cases
differs.  For example, in a platform which supports exceptions, it may be
useful to have both of the following functions:

   someName(String s, int startOfs, int length)

Return a string of exactly length characters from string s, starting at
zero-based offset startOfs.  If the length of the string is less than
startOfs+length, throw an exception.

   someName(String s, int startOfs, int length)

Return a string of up to length characters from string s, starting at
zero-based offset startOfs.  If the length of the string is less than
startOfs, return an empty string; if less than startOfs+length, return
the tail of the string starting at startOfs.

   someName(String s, int startOfs, int length, char padding)

Return a string of exactly length characters from string s, starting at
zero-based offset startOfs.  If the length of the string is less than
startOfs, startOfs+length, behave as though it was padded with the
indicated character.

All three functions behave identically in the "normal" case, but if a
standard library doesn't include all three, user code will often have to
either define its own functions to supply the missing functionality (in
many cases less efficiently than a version with the internals of strings
could do) or--if the first version was the missing one--tolerate sloppy
error trapping [if code is expecting to output six characters to a record
made up of fixed-length fields, having the code throw an exception would
be better than having it output only five characters].

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web