arrays in c
Tjelvar Eriksson
I'm a complete newbie to c but well familiar with javascript/php and wonder:
Does c support arrays, two dimensional, dynamicly resizable or how do i
resize them
and preserve it's content?
I want to do:
$twoDimensionalArr=array(array()); //declare the two dimensional array. I
don't know it's dimensions yet.
while (!recordset_eof_check) {
$oneDimensionalArray=db_get_row($dbconn); //get one record from db as one
dimensional array
$twoDimensionalArr[]=$oneDimensionalArray; //add the array to the 2Xarr
}
How can I do this in C?
I don't understand a blink of C with it's * & # % ^ so pleace comment any
suggestions.
Thanks,
and try the superior open source database at firebird.sourceforge.net
Tom St Denis
"Tjelvar Eriksson" <tjem...@hotmail.com> wrote in message
news:yf%67.4598$h%2.9...@news010.worldonline.se...
Seriously consider buying a good C book. None of these "learn C in 12
minute" books but perhaps "The C Progamming Language 2nd Edition" by
Kernighan and Ritchie. It's not too expensive and will cover all of C, not
just the parts the author learnt in their exciting new 12 day IT class...
Tom
Joona I Palaste
> Hi,
> I'm a complete newbie to c but well familiar with javascript/php and wonder:
> Does c support arrays, two dimensional, dynamicly resizable or how do i
> resize them
> and preserve it's content?
C supports one-dimensional, two-dimensional, even 47-dimensional
arrays. However, dynamically resizing them with preserving content
is a bit difficult.
In C, you cannot dynamically resize an array. It just isn't done!
You can emulate it though, by using pointers instead of arrays and
using the functions malloc(), realloc() and free().
Here's a sample C function that will allocate a two-dimensional
array dynamically.
int **array(int width, int height) {
int **tmp;
int i;
if (tmp=malloc(width*sizeof(int *)))
for (i=0; i<width; i++)
tmp[i]=malloc(height*sizeof(int));
return tmp;
}
Here's a sample C function that will free the two-dimensional array
allocated by the above function.
void unarray(int **arr, int width) {
int i;
for (i=0; i<width; i++)
free(tmp[i]);
free(tmp);
}
By using realloc() instead of malloc() in the function array() above
you should be able to resize an already allocated array with
preserving content. Further help on realloc() is available from other
comp.lang.c readers and a C book.
> I want to do:
(off-topic code snipped)
> How can I do this in C?
I don't know the language that was in, so I can't comment.
> I don't understand a blink of C with it's * & # % ^ so pleace comment any
> suggestions.
Almost every language has operators made from punctuation characters.
They won't bite you.
> Thanks,
> and try the superior open source database at firebird.sourceforge.net
Sorry, I didn't try it yet.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bee could, in effect, gather its junk. Llamas (no poor quadripeds) tune
and vow excitedly zooming."
- JIPsoft
Zoran Cutura
wrote:
...
> C supports one-dimensional, two-dimensional, even
> 47-dimensional arrays.
If I understand 5.2.4.1 a conforming implementation
needs to allow 12 array subscriptions (or less in combination
with function or pointer declarations) in a declaration
so 47 may not always be possible.
--
Z (Zoran....@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Owen Brydon
>
> Once upon a while "Joona I Palaste" <pal...@cc.helsinki.fi>
> wrote:
> ...
>
> > C supports one-dimensional, two-dimensional, even
> > 47-dimensional arrays.
>
> If I understand 5.2.4.1 a conforming implementation
> needs to allow 12 array subscriptions (or less in combination
> with function or pointer declarations) in a declaration
> so 47 may not always be possible.
>
So must every conforming implementation be able to compile the following
or not? Just curious.
(please excuse line wraps)
#include <stdio.h>
int main(void)
{
typedef int multiarray[1][1][1][1][1][1][1][1][1][1][1][1];
/* 12 subscripts */
typedef multiarray multimulti[1][1][1][1][1][1][1][1][1][1][1][1];
/* another 12 subscripts */
multimulti example[1][1][1][1][1][1][1][1][1][1][1][1];
/* another 12 subscripts */
example[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0
][0][0][0][0][0][0][0][0][0][0][0][0]=7;
/* 36 subscripts */
printf("value=%d\n",example[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]);
/* 36 subscripts */
return 0;
}
Owen
--
"Actually Dennis Ritchie is Lionel Ritchie's half-brother. He wrote
the original versions of all Lionel's hits. In some cases, the
titles were changed, for instance ``Hello, World'', which Lionel
shortened by dropping ``World''." -- Kaz Kylheku, comp.lang.c
Sol Rosenberg
> Seriously consider buying a good C book. None of these "learn C in 12
> minute" books but perhaps "The C Progamming Language 2nd Edition" by
> Kernighan and Ritchie. It's not too expensive and will cover all of C, not
> just the parts the author learnt in their exciting new 12 day IT class...
>
> Tom
No, but the learning curve is somewhat steep. I do not understand why
all are against these small "quickies". You should read a C book that
is easy, and wake your interest (I'm sorry to say, but K&R did not
wake mine), then as you start to program and run into real problems
you can (and will) study books as "The C Progamming Language".
Jesper
Zoran Cutura
from IEEE 9899:1999 5.2.4.1
The implementation shall be able to translate and execute
at least one program that contains at least one instance
of every one of the following limits:
....
-- 12 pointer, array, and function declarators (in any combinations)
modifying an arithmetic, structure, union, or incomplete
type in a declaration
...
So I would say that a conforming implmentation may refuse to
compile your program.
Richard Bos
> > Seriously consider buying a good C book. None of these "learn C in 12
> > minute" books but perhaps "The C Progamming Language 2nd Edition" by
> > Kernighan and Ritchie. It's not too expensive and will cover all of C, not
> > just the parts the author learnt in their exciting new 12 day IT class...
>
> No, but the learning curve is somewhat steep. I do not understand why
> all are against these small "quickies".
The simple answer? They teach bad programming habits and
misunderstandings about C. We see the effects of those all too often
here on c.l.c, and usually accompanied by a question on the lines of
"Why does a[i]=i++; not work?".
Richard
Owen Brydon
Having had a peruse of N843, I would agree. In fact, as well as 5.2.4.1,
6.7.5 #7 is of interest:
[#7] As discussed in 5.2.4.1, an implementation may limit
the number of pointer, array, and function declarators that
modify an arithmetic, structure, union, or incomplete type,
either directly or via one or more typedefs.
^^^^^^^^^^^^^^^^^^^^^^^^^
Lew Pitcher
I can't resist adding my two cents worth...
Tjelvar Eriksson wrote:
>
> Hi,
Hi.
> I'm a complete newbie to c
Well, we all were, once (and some of us still are <g>)
> but well familiar with javascript/php
That's nice. Not applicable, but nice
> and wonder:
>
> Does c support arrays,
Yes
> two dimensional,
Yes
> dynamicly resizable
I'm not sure. Up to C89, no (but there were/are ways to simulate this),
with C99, I believe that there is _some_ provision for dynamically
resizable arrays. I'm sure that the C experts (of which I am not a
member) here can (and have) expounded on this feature (or will expound
on my mis-remembering of it).
> or how do i resize them and preserve it's content?
Well, at worst case, you've used malloc() to allocate the space, and
realloc() to reallocate them. memcpy() will let you move them around.
> I want to do:
>
> $twoDimensionalArr=array(array()); //declare the two dimensional array. I
> don't know it's dimensions yet.
>
> while (!recordset_eof_check) {
> $oneDimensionalArray=db_get_row($dbconn); //get one record from db as one
> dimensional array
> $twoDimensionalArr[]=$oneDimensionalArray; //add the array to the 2Xarr
> }
>
> How can I do this in C?
Do what? Oh, you mean that stuff that you expressed in some foreign
language that's not understandable here? Well, you framastan the
frippitz, and gorgle the frortz. Then you reblippiq your abnorogs and
the rest is obvious.
> I don't understand a blink of C with it's * & # % ^ so pleace comment any suggestions.
First and only suggestion: Go learn C. If you "don't understand a blink
of C", then _any_ other suggestion that we could make would be over your
head. Once you've learned C, you will comprehend enough of the
terminology and techniques to understand any reasonable suggestion we
could make.
> Thanks,
You're welcome
> and try the superior open source database at firebird.sourceforge.net
What does this have to do with C?
Besides, I like Berkeley DB, MySQL, Oracle, and DB/2 UDB.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576
Salvador Peralta
Why should anyone buy a "lesser" book when they can have the
authoritative guide? Simple. Many people learn c as a first
language, and not every beginner is ready to digest K&R as an intro
to programming. Most beginner's aren't. K&R acknowledges this in
the introduction: "This book is not an introductory programming
manual".
I would suggest that the reason that you generally get a lower class
of questions from people reading "teach yourself..." is that people
who are reading K&R as a rule are generally a more experienced and
sophisticated caliber of student. By 'sophisticated', I mean that
most have probably already read one or more "teach yourself" books
and/or had formal training before getting a whiff K&R.
In defense of the "quickie books"... K&R is rather spartan to stand
on its own as a mechanism for teaching c to novices. My own study of
C ( such as it is ) has benefitted tremendously from having a few
easier to digest books around as a supplement to K&R.
K&R also makes some curious choices. I have yet to determine what
particular stroke of editorial sadism prompted them to sandwich a
page and a half on bitwise operators in ch 2.9 between
increment/decrement operators and assignment operators. As a
heuristic device, that's a little like telling a piano student to
sandwich "eroica" in between learning "mary had a little lamb" and
"chopsticks".
Stefan Farfeleder
> Tjelvar Eriksson wrote:
>> Does c support arrays,
> Yes
>> two dimensional,
> Yes
>> dynamicly resizable
> I'm not sure. Up to C89, no (but there were/are ways to simulate this),
> with C99, I believe that there is _some_ provision for dynamically
> resizable arrays.
Well, in C99 you can create an VLA whose size is only known at runtime:
void foo(int n)
{
int a[n];
/*...*/
}
AFAIK there's no possibility to change a's size once it is defined.
--
Stefan Farfeleder
Chris F.A. Johnson
> In defense of the "quickie books"... K&R is rather spartan to stand
> on its own as a mechanism for teaching c to novices. My own study of
> C ( such as it is ) has benefitted tremendously from having a few
> easier to digest books around as a supplement to K&R.
The argument is not against "quickie books" so much as the fact that most
of them are badly written. A well written, accurate book would be
welcomed.
> K&R also makes some curious choices. I have yet to determine what
> particular stroke of editorial sadism prompted them to sandwich a
> page and a half on bitwise operators in ch 2.9 between
> increment/decrement operators and assignment operators. As a
> heuristic device, that's a little like telling a piano student to
> sandwich "eroica" in between learning "mary had a little lamb" and
> "chopsticks".
Especially since the Eroica is a symphony with no piano part!
--
Chris F.A. Johnson http://cfaj.freeshell.org
===================================================================
My code (if any) in this post is copyright 2001, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License
Micah Cowan
> > dynamicly resizable
>
> I'm not sure. Up to C89, no (but there were/are ways to simulate this),
> with C99, I believe that there is _some_ provision for dynamically
> resizable arrays. I'm sure that the C experts (of which I am not a
> member) here can (and have) expounded on this feature (or will expound
> on my mis-remembering of it).
C99 defines dynamically sizeable arrays, but not /resizeable/. That
is, you can define its size using a variable when the array is
created, but you cannot then change that size during the lifetime of
the array.
> > or how do i resize them and preserve it's content?
>
> Well, at worst case, you've used malloc() to allocate the space, and
> realloc() to reallocate them. memcpy() will let you move them
> around.
Why would you need memcpy()? realloc() will move the old data to the
new space before freeing the old, if need be.
Micah
--
John Golubenko: "Ok, I'm newbie, so correct me if I'm wrong."
-hs-: "Trust me, newbie or not, you will be corrected if you
are wrong!"
Sef Campstein
> resize them
> and preserve it's content?
C does support arrays, although they are one-dimensional and of fixed size.
You can however get the behaviour you want by:
- using a one dimensional array and access it as if it was 2-dimensional
array.
- making use of malloc(), realloc() for the dynamic sizing while preserving
content.
However, as you seem to be doing some db manipulations, maybe your db vendor
provides some lib to manipulate the db from within C code (and appropriate
data types).
Micah Cowan
> > Does c support arrays, two dimensional, dynamicly resizable or how do i
> > resize them
> > and preserve it's content?
>
> C does support arrays, although they are one-dimensional and of fixed size.
Who says they're one-dimensional? Is
int array[10][20];
not a declaration of a two-dimensional array?
> You can however get the behaviour you want by:
> - using a one dimensional array and access it as if it was 2-dimensional
> array.
I'd be very interested to see how you propose to do that. Please post
a compilable example (NOTE: I'm talking to Sef here; I'm perfectly
aware of one way to technically do as he proposes - no guru responses, please).
> - making use of malloc(), realloc() for the dynamic sizing while preserving
> content.
This would be the way to deal with the problem at hand - having
dynamically resizable arrays. OP: Read the FAQ for more details.
http://www.eskimo.com/~scs/C-faq/s6.html
Micah
--
"Quite frankly, C isn't a good language for idiots and never will be.
Same for Ferraris, for that matter."
- Dann Corbit
Richard Heathfield
>
> "Sef Campstein" <s...@campst.tmfweb.nl> writes:
>
> > > Does c support arrays, two dimensional, dynamicly resizable or how do i
> > > resize them
> > > and preserve it's content?
> >
> > C does support arrays, although they are one-dimensional and of fixed size.
>
> Who says they're one-dimensional? Is
>
> int array[10][20];
>
> not a declaration of a two-dimensional array?
No [1]. It is a declaration of a one-dimensional array of 10
one-dimensional arrays, each containing 20 ints.
[1] This is incorrect [2]. 6.5.2.1 of C99 says: Successive subscript
operators designate an element of a multidimensional array object.
[2] "But Richard - if you *knew* it was wrong, why did you say it?" [3]
[3] I don't know. [4]
[4] "You're weird, sir." [5]
[5] Stop calling me 'sir'.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Bruce G. Stewart
>
> Micah Cowan wrote:
> >
> > "Sef Campstein" <s...@campst.tmfweb.nl> writes:
> >
> > > > Does c support arrays, two dimensional, dynamicly resizable or how do i
> > > > resize them
> > > > and preserve it's content?
> > >
> > > C does support arrays, although they are one-dimensional and of fixed size.
> >
> > Who says they're one-dimensional? Is
> >
> > int array[10][20];
> >
> > not a declaration of a two-dimensional array?
>
> No [1]. It is a declaration of a one-dimensional array of 10
> one-dimensional arrays, each containing 20 ints.
>
> [1] This is incorrect [2]. 6.5.2.1 of C99 says: Successive subscript
> operators designate an element of a multidimensional array object.
>
> [2] "But Richard - if you *knew* it was wrong, why did you say it?" [3]
>
> [3] I don't know. [4]
>
> [4] "You're weird, sir." [5]
>
> [5] Stop calling me 'sir'.
The array-of-arrays notion is everything an N-dimensional array would
be, and more. This is a better thing (imho) for a few reasons:
- When you have described the meaning of a one dimensional array,
you've described all orders.
- It naturally admits the idea of dealing with a single row of a "2
dimensional array" as a 1 dimensional array without any additional
notation or concepts.
- "Vectorized" arrays (eg int *array[10]) conveniently use the same
notation for access as normal arrays.
Salvador Peralta
> On Tue, 24 Jul 2001, Salvador Peralta wrote:
>
>> In defense of the "quickie books"... K&R is rather spartan to stand
>> on its own as a mechanism for teaching c to novices. My own study
>> of C ( such as it is ) has benefitted tremendously from having a
>> few easier to digest books around as a supplement to K&R.
>
> The argument is not against "quickie books" so much as the fact that
> most of them are badly written. A well written, accurate book would
> be welcomed.
As a rule, I tend to trust authors more than critics, except in the
rare cases where the critic provides something other than vague
deconstruction.
OTOH, I have only purchased 2 of the Ty Books ( html 1994, perl 1995
) and refuse to purchase any book labeled "... for dummies" as a
matter of principle.
FWIW, I got most of my introductory c from Steve Summit's online
course notes, K&R, and C by Example.
I am now spending most of my free time wading through Plank's
Programming Notes, Stevens' Unix Network Programming, C Unleashed,
Osborne's book from the Complete Reference series, this newsgroup,
and basically anything I can get my hands on that teaches me
something new about the language or how to use it.
Tjelvar Eriksson
simple answers on simple questions. I never asked for these myriad of book
advices...
Thanks again,
t
Micah Cowan <mi...@cowanbox.com> skrev i
diskussionsgruppsmeddelandet:yu88zhc...@mcowan-linux.transmeta.com...
Ben Pfaff
> As a rule, I tend to trust authors more than critics, except in the
> rare cases where the critic provides something other than vague
> deconstruction.
This isn't necessarily a good idea. Very little checking of
facts goes on in the production of some books. I know this
because I wrote a chapter for _C Unleashed_, and very little
checking of my facts went on during the production process. The
reviewer I had only had some style comments (ones that sounded
pretty uninformed).
David Lee Lambert
> Richard Bos on Tuesday 24 July 2001 08:13:
..
> >> No, but the learning curve is somewhat steep. I do not understand
> >> why all are against these small "quickies".
> >
> > The simple answer? They teach bad programming habits and
> > misunderstandings about C. We see the effects of those all too often
> > here on c.l.c, and usually accompanied by a question on the lines of
> > "Why does a[i]=i++; not work?".
>
> Why should anyone buy a "lesser" book when they can have the
> authoritative guide? Simple. Many people learn c as a first
> language, and not every beginner is ready to digest K&R as an intro
> to programming. Most beginner's aren't. K&R acknowledges this in
> the introduction: "This book is not an introductory programming
> manual".
The problem I see is that many of the "one week/21 days/etc.." books
aren't really suitable as an introductory programming manual either. As
to myself, I started out with K&R and my compiler's library reference
(Turbo C++ 1.01, if anyone remembers it...) I had only written a few
five-liners in BASIC before that.
Somewhere I heard the quote "A mediocre programmer can write a FORTRAN
program in any language". It seems as if this class of books encourages
such mediocrity. They have some basic advice about programming, and a
lot of vague, possibly inaccurate references to higher-level concepts.
> I would suggest that the reason that you generally get a lower class
> of questions from people reading "teach yourself..." is that people
> who are reading K&R as a rule are generally a more experienced and
> sophisticated caliber of student. By 'sophisticated', I mean that
> most have probably already read one or more "teach yourself" books
> and/or had formal training before getting a whiff K&R.
Or simply skipped over them...
A real introductory book on C should have advice like this in the first
chapter...
- Remember that identifiers are case-sensitive
- Remember that variables must be declared
I think it would be best to not even cover strings until a later chapter,
but cover the address-of operator in the very first pages; for instance,
I hope that this would be a good first-chapter program:
/* program to compute the sum and difference of two numbers */
#include <stdio.h>
int main()
{
int n1, n2;
int N;
printf("Enter pairs of numbers; "
"EOF or any letter to terminate\n");
while (!feof(stdin)) {
N = scanf("%d%d", &n1, &n2);
if (N < 2) break;
printf("sum= %d diff= %d\n", n1 + n2, n1 - n2);
}
return 0;
}
/* end of program */
This program illustates variables, looping, and string-constants, as well
as basic arithmetic and declaration of variables.
> K&R also makes some curious choices. I have yet to determine what
> particular stroke of editorial sadism prompted them to sandwich a
> page and a half on bitwise operators in ch 2.9 between
> increment/decrement operators and assignment operators. As a
> heuristic device, that's a little like telling a piano student to
> sandwich "eroica" in between learning "mary had a little lamb" and
> "chopsticks".
It depends... Ritchie worked at Bell Labs. To an electrical engineer,
bitwise operations are a lot more important than addition/subtraction.
Increment/decrement operators aren't much use to the scripting crowd,
either, except as entries in loop indexes, and I think that that's
better introduced in an example of a loop...
Unfortunately, I lent my copy of K&R 2 to a friend and never got it back.
--
DLL
http://web.egr.msu.edu/~lamber45/
Richard Heathfield
Er, that means that you - the author - were IYHO better informed than
your technical editor - the critic. Doesn't that contradict your opening
sentence? :-)
Ben Pfaff
> Ben Pfaff wrote:
> >
> > Salvador Peralta <ad...@salvador.venice.ca.us> writes:
> >
> > > As a rule, I tend to trust authors more than critics, except in the
> > > rare cases where the critic provides something other than vague
> > > deconstruction.
> >
> > This isn't necessarily a good idea. Very little checking of
> > facts goes on in the production of some books. I know this
> > because I wrote a chapter for _C Unleashed_, and very little
> > checking of my facts went on during the production process. The
> > reviewer I had only had some style comments (ones that sounded
> > pretty uninformed).
>
> Er, that means that you - the author - were IYHO better informed than
> your technical editor - the critic. Doesn't that contradict your opening
> sentence? :-)
The point was supposed to be that if the author isn't any good,
it's quite likely that it won't be caught by anyone during the
production process. But maybe you realize that and that's the
reason for the smiley.
--
Available for short-term C and Linux contracts through September 2001.
Salvador
Yes, I don't doubt it. I've purchased books where neither the author
nor reviewers bothered to verify that their code would even compile.
One example of this is an assembler for linux book that recently I
purchased in which the author reversed nasm's method for getting the
value of an address with getting the location of the address in every
piece of code in the book! And that was in a second edition!
OTOH, I'd suggest that many reviewers (on the accu list, for example)
will cheerfully throw out a book or article that gets 95% of a topic
right on account of the 5% that it handles poorly or even throw
something out because they simply disagree on a style-related issue.
At least when someone writes a book, they are opening themselves up to
scrutiny and review. Most critics are not subject to either.
Micah Cowan
> Chris F.A. Johnson on Wednesday 25 July 2001 10:39:
>
> > On Tue, 24 Jul 2001, Salvador Peralta wrote:
> >
> >> In defense of the "quickie books"... K&R is rather spartan to stand
> >> on its own as a mechanism for teaching c to novices. My own study
> >> of C ( such as it is ) has benefitted tremendously from having a
> >> few easier to digest books around as a supplement to K&R.
> >
> > The argument is not against "quickie books" so much as the fact that
> > most of them are badly written. A well written, accurate book would
> > be welcomed.
>
> As a rule, I tend to trust authors more than critics, except in the
> rare cases where the critic provides something other than vague
> deconstruction.
Any vague deconstructions in reference to the books discussed are
simply for the fact that the critics have hashed their myriad problems
in excruciating detail many times in the past. Searches on
groups.google.com will likely be fruitful.
>
> OTOH, I have only purchased 2 of the Ty Books ( html 1994, perl 1995
> ) and refuse to purchase any book labeled "... for dummies" as a
> matter of principle.
Some of the "... For Dummies" books are informative, helpful, and
entertaining - make great references. The "C For Dummies" happens not
to be.
>
> FWIW, I got most of my introductory c from Steve Summit's online
> course notes, K&R, and C by Example.
>
> I am now spending most of my free time wading through Plank's
> Programming Notes, Stevens' Unix Network Programming, C Unleashed,
> Osborne's book from the Complete Reference series, this newsgroup,
> and basically anything I can get my hands on that teaches me
> something new about the language or how to use it.
Looks like you have good taste in C books :)
Micah
--
"*I* don't think you understand your question."
-- Tom Plunket
Richard Heathfield
<snip>
> > Osborne's book from the Complete Reference series, this newsgroup,
> > and basically anything I can get my hands on that teaches me
> > something new about the language or how to use it.
>
> Looks like you have good taste in C books :)
Micah - you *do* know who wrote "C - the Complete Reference", don't you?
(And yes, I /have/ read it - and it /is/ as bad as it's painted.)
Salvador Peralta
> (And yes, I /have/ read it - and it /is/ as bad as it's painted.)
I bought it because chapter 29 deals with how to build a simple c
interpreter. I looked at the code, could understand it, and felt
that it would be worth muddling through. *ahem* if present company
had included a chapter on that in C Unleashed, I might never have
bought the Complete Reference book. :)
Richard Heathfield
You'd be amazed at some of the stuff originally considered for "C
Unleashed". Had every suggestion been included, you'd have had to trade
in your wheelbarrow for a fork-lift truck.
CBFalconer
Unfortunately it is just plain WRONG. The !feof statement won't
do what you want. The scanf is dangerous, and will barf on
extraneous chars in the input. You didn't compile and test it.
--
Chuck F (cbfal...@my-deja.com) (cbfal...@XXXXworldnet.att.net)
(Remove "XXXX" from reply address. my-deja works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Dave Vandervies
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>You'd be amazed at some of the stuff originally considered for "C
>Unleashed". Had every suggestion been included, you'd have had to trade
>in your wheelbarrow for a fork-lift truck.
You say that as if it were a Bad Thing.
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
Certainly I believe in it. I believe it is designed to generate media
attention and bilk investors out of money, and I think it's succeeding
admirably. --Paul Tomblin in the scary devil monastery
Richard Heathfield
>
> In article <3B608F10...@eton.powernet.co.uk>,
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>
> >You'd be amazed at some of the stuff originally considered for "C
> >Unleashed". Had every suggestion been included, you'd have had to trade
> >in your wheelbarrow for a fork-lift truck.
>
> You say that as if it were a Bad Thing.
I have a dozen copies on a single bookshelf. (I know, I know, but I
think they look pretty.) If they were any bigger, either they wouldn't
fit or they'd break the shelf. And that would indeed be a Bad Thing.
Stefan Farfeleder
> David Lee Lambert wrote:
>>
>> /* program to compute the sum and difference of two numbers */
>> #include <stdio.h>
>>
>> int main()
>> {
>> int n1, n2;
>> int N;
>>
>> printf("Enter pairs of numbers; "
>> "EOF or any letter to terminate\n");
>>
>> while (!feof(stdin)) {
>> N = scanf("%d%d", &n1, &n2);
>> if (N < 2) break;
>> printf("sum= %d diff= %d\n", n1 + n2, n1 - n2);
>> }
>>
>> return 0;
>> }
>> /* end of program */
>>
>> This program illustates variables, looping, and string-constants, as well
>> as basic arithmetic and declaration of variables.
> Unfortunately it is just plain WRONG. The !feof statement won't
> do what you want. The scanf is dangerous, and will barf on
> extraneous chars in the input. You didn't compile and test it.
I can only suspect you didn't either. The feof isn't wrong, it's just
superfluous and could be replaced by while (1). The program will quit on
extraneous chars, I don't consider that bad.
The only UB occurs if you enter a number > INT_MAX. You can change %d to
%4d if you like:
while (scanf("%4d%4d", &n1, &n2) == 2)
printf("sum= %d diff= %d\n", n1 + n2, n1 - n2);
Not that I would recommend scanf for real use, but IMHO this program is
easier to understand for a novice than the same program with fgets and
strtol. YMMV.
--
Stefan Farfeleder
Dave Vandervies
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>Dave Vandervies wrote:
>>
>> In article <3B608F10...@eton.powernet.co.uk>,
>> Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>>
>> >You'd be amazed at some of the stuff originally considered for "C
>> >Unleashed". Had every suggestion been included, you'd have had to trade
>> >in your wheelbarrow for a fork-lift truck.
>>
>> You say that as if it were a Bad Thing.
>
>I have a dozen copies on a single bookshelf. (I know, I know, but I
>think they look pretty.) If they were any bigger, either they wouldn't
>fit or they'd break the shelf. And that would indeed be a Bad Thing.
I bet if you'd've made it a dozen times as big, you could have made
that one big book look a lot prettier than a dozen of the smaller
ones. Then you'd only need to put one on the shelf, and there would
be room for it and the shelf would be able to handle it.
ObTopicalityDiscussion: Why does nobody ever respond to my on-topic
posts? Does my newsswerver filter them out or something?
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
Why don't I just lock everyone up and throw away the key and be done with the
whole business? Sheesh, I can see now why all dictators end up as bad guys...
--Richard Heathfield in comp.lang.c
Brian B. Rodenborn
>You'd be amazed at some of the stuff originally considered for "C
>Unleashed". Had every suggestion been included, you'd have had to trade
>in your wheelbarrow for a fork-lift truck.
I used one of those "Two Men and a Truck" operations to bring a copy
home from the library.
BTW, I just checked the library's on-line service, and all four copies
they purchased at my behest are checked out. Sounds like some folks
in St. Louis County MO are getting some use out of the book.
--
A program should follow the `Law of Least Astonishment'. What is this law? It
is simply that the program should always respond to the user in the way that
astonishes him least. - The Tao of Programming
Ben Pfaff
> In article <3B608F10...@eton.powernet.co.uk>,
> Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>
> >You'd be amazed at some of the stuff originally considered for "C
> >Unleashed". Had every suggestion been included, you'd have had to trade
> >in your wheelbarrow for a fork-lift truck.
>
> BTW, I just checked the library's on-line service, and all four copies
> they purchased at my behest are checked out. Sounds like some folks
> in St. Louis County MO are getting some use out of the book.
*FOUR* copies? That's three more than I've ever seen in one
place. I've only ever seen one copy in a bookstore, and that
only once. Maybe _C Unleashed_ is more successful than I
thought.
Micah Cowan
Chapter 19 of "C Unleashed" probably covers the topic significantly
better; though it doesn't specifically deal with building a C
interpreter - but then, I doubt that book does, either - the entire C
grammar makes a whole chapter. I doubt that its really a C
interpreter - its probably just a C /expression/ interpreter. There's
no way you could even begin to touch a C interpreter in one language.
Brian B. Rodenborn
Ben Pfaff <pfaf...@msu.edu> wrote:
>> BTW, I just checked the library's on-line service, and all four copies
>> they purchased at my behest are checked out. Sounds like some folks
>> in St. Louis County MO are getting some use out of the book.
>*FOUR* copies? That's three more than I've ever seen in one
>place. I've only ever seen one copy in a bookstore, and that
>only once. Maybe _C Unleashed_ is more successful than I
>thought.
That's four copies for the system, their nominal homes are in four
different branches.
A couple of years ago, I discovered the on-line interface to the public
library. This includes a form to fill out when you'd like something they
don't currently have. They are very good about going out and purchasing
the requested items, if available.
I've ordered a plethora of books, CDs and videos since then. I never know
how many copies of any item they will order, it varies from two to 15
or so. Technical books tend to be of the lower order, probably due to
price.
Mark
trip a while back, selling for considerably less than cover price.
I decided I'd pick one up at the local Sam's once I got home
(didn't want to hold the book on the plane) only to find that the
local Sam's Club doesn't stock it!
Looking forward to my next trip to New Jersey!
Mark
Tor Rustad
> Salvador Peralta wrote:
> >
> > had included a chapter on that in C Unleashed, I might never have
> > bought the Complete Reference book. :)
>
> You'd be amazed at some of the stuff originally considered for "C
> Unleashed". Had every suggestion been included, you'd have had to trade
> in your wheelbarrow for a fork-lift truck.
Knuth writes multiple volumes, so can you! I usually hate thick books
(unless they are reference manuals), since at one point I usually get bored
of all the talk. ;-)
"C Unleashed" has a lot of chapters, of the ones I have read so far, these
could be replaced IMHO
* Chapter 15: Sparse Matrix
* Chapter 26: Encryption
* Chapter 29: Parallell Processing
and maybe
* Chapter 3: Optimization
The reason, is perhaps because I find these topics interesting myself and
simply are being too critical about the content...
"Sparse Matrix" isn't what most C programmers need to do, so this chapter
should simply be dropped. However, the other chapter on matrix computations
(17) will be very useful to many people.
"Encryption" or security is important today, but this is a difficult subject
so it can't be explained well in 30 pages. Better: Have a chapter
explaining how to use e.g. OpenSSL package in a C program, and let people
learn encryption from a real security book (written by an expert).
"Parallell Processing" is interesting, of the things I wanted to read about
here was OpenMP and MPI API... but not a word! Why not replace it with a
chapter on POSIX pthreads?!?
I felt that "Optimization" was too focused on micro-optimizing techniques,
what about another communication chapter or a chapter on plattform
independent data representation (e.g. XDR, ASN.1) (or POSIX or compiler
stuff or OS kernel stuff or ......)?
To be honest, what I really missed was some chapters by Chris Torek, Kaz K.
and Dan Pop.[1] :-)
[1] Topics could for example be extracted from : "BSD OS kernel", "Standard
C library", "Dan Pop compiler"[2], "POSIX", "pthreads" or whatever.
[2] IIRC, Kaz K stated this as the most compliant ANSI C compiler (or
language validator)...
--
Tor <torust AT online DOT no>
Richard Heathfield
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> > Salvador Peralta wrote:
> > >
> > > had included a chapter on that in C Unleashed, I might never have
> > > bought the Complete Reference book. :)
> >
> > You'd be amazed at some of the stuff originally considered for "C
> > Unleashed". Had every suggestion been included, you'd have had to trade
> > in your wheelbarrow for a fork-lift truck.
>
> Knuth writes multiple volumes, so can you! I usually hate thick books
> (unless they are reference manuals), since at one point I usually get bored
> of all the talk. ;-)
Ah, but I do it so well... :-)
As a matter of fact, I do think the talk is important. It's meant to be
a *book*, after all, not a bunch of lecture notes or a code repository.
After all, people who buy books either like to read, or like to spend
money, or both. It seems that many "C Unleashed" readers fall purely
into the first category, and get it out of their local library (sigh
shrug).
If ever I get around to writing a decent C tutorial, you can be sure
that it'll include lots of backchat.
>
> "C Unleashed" has a lot of chapters, of the ones I have read so far, these
> could be replaced IMHO
>
> * Chapter 15: Sparse Matrix
> * Chapter 26: Encryption
> * Chapter 29: Parallell Processing
>
> and maybe
>
> * Chapter 3: Optimization
>
> The reason, is perhaps because I find these topics interesting myself and
> simply are being too critical about the content...
>
> "Sparse Matrix" isn't what most C programmers need to do, so this chapter
> should simply be dropped. However, the other chapter on matrix computations
> (17) will be very useful to many people.
If there were a second edition (and I don't have any information on
whether there will be), I would be inclined to agree with you on both
counts.
> "Encryption" or security is important today, but this is a difficult subject
> so it can't be explained well in 30 pages. Better: Have a chapter
> explaining how to use e.g. OpenSSL package in a C program, and let people
> learn encryption from a real security book (written by an expert).
Or perhaps just walk through some C implementation techniques (e.g.
modular exponentiation, one-way hashing, and so on), and perhaps add
just a splash of theory. I agree that you'd be better off learning
crypto from a crypto book.
>
> "Parallell Processing" is interesting, of the things I wanted to read about
> here was OpenMP and MPI API... but not a word! Why not replace it with a
> chapter on POSIX pthreads?!?
I haven't a clue what you're talking about. Ask Stephan. STEPHAN!!
(Where IS he, nowadays?)
> I felt that "Optimization" was too focused on micro-optimizing techniques,
I disagree, but I recognise the point. Without re-reading the chapter I
can't quite recall what Mikey said about macro-optimisation, but I'm
sure he covered it in reasonable detail.
> what about another communication chapter or a chapter on plattform
> independent data representation (e.g. XDR, ASN.1)
Not a bad idea, actually.
> (or POSIX or compiler
> stuff or OS kernel stuff or ......)?
A Linux chapter was nearly included. IMHO dropping it was the right
decision.
>
> To be honest, what I really missed was some chapters by Chris Torek, Kaz K.
> and Dan Pop.[1] :-)
Well, I did ask Chris, and he politely declined. I am ashamed to admit
that I forgot to ask Kaz, but IIRC he says he got an invite anyway and
turned it down.
Not sure about Dan. This might have been before his return, actually.
If I had the chance again, I think I'd want to add: more about embedded
systems and Unix, since those are the platforms on which C's future is
likely to rest; more about expression parsing and perhaps a bit on
compiler-writing; a completely reworked simulations chapter; a chapter
on neural networks, because they can be a lot of fun; and a complete
technical and typographical revision of everything currently in the
book! (This would include some non-fascist style convergence and perhaps
slightly more fascist intra-book code re-use. Code re-use wasn't at the
forefront of our minds first time round, I'm afraid.)
For me, the most important aspect of the book is that it doesn't try to
teach you C (for the most part); I always wanted to focus on taking
existing ISO C knowledge and showing what else could be done with it.
I'm reasonably happy that we achieved that. And I'm equally happy that I
managed to sneak in a chapter on sockets without anyone shouting too
loud about its inherent non-portability. :-)
[ For the record, this article is not intended to solicit extra sales
(although I'm hardly going to stop you if you are suddenly desperate to
go out and buy a copy); it is merely a technical discussion - which I
did not start - of the book's current and putative future contents. ]
Tor Rustad
[...]
> If ever I get around to writing a decent C tutorial, you can be sure
> that it'll include lots of backchat.
As long as the S/N ratio is above a certain level I am fine... :-)
> > "Encryption" or security is important today, but this is a difficult
subject
> > so it can't be explained well in 30 pages. Better: Have a chapter
> > explaining how to use e.g. OpenSSL package in a C program, and let
people
> > learn encryption from a real security book (written by an expert).
>
> Or perhaps just walk through some C implementation techniques (e.g.
> modular exponentiation, one-way hashing, and so on), and perhaps add
> just a splash of theory. I agree that you'd be better off learning
> crypto from a crypto book.
Therefore give the working C programmer what he need instead, namely an
introduction on how to get started with a open source crypto toolkit. From
what I have seen from e.g. the OpenSSL doc, it is not that easy (Peter G.
cryptlib has a much nicer doc & C interface but this is not a free toolkit
in all cases). Such information could even be interesting to the working
professionals aswell, since they tend to use commercial toolkits instead,
but may have cases where it is of interest to use a portable open source
toolkit. Other topics could be PKCS #11, CDSA, GSS and IDUP, but (for my
taste) these topics are too complicated and special. Also, I don't think the
industri will support it much (except PKCS #11 of course).
IMHO, modular exponentiation etc. belong to a multiprecition package. So I
don't agree that the mainstream C programmer need it. I could like something
about e.g. the Chinese reminder theorem, but that is actually a bad sign!
:-)
> > "Parallell Processing" is interesting, of the things I wanted to read
about
> > here was OpenMP and MPI API... but not a word! Why not replace it with
a
> > chapter on POSIX pthreads?!?
>
> I haven't a clue what you're talking about. Ask Stephan. STEPHAN!!
I hear you, no place to hide!?! :-)
With OpenMP and MPI API we can build poor man's supercomputer with only some
PC's (e.g. running Linux) in a rack and using a switch for communication.
This is well known in the scientific community, and I think MPI (Message
Passing Interface) is becoming a de facto standard for C programming this
type of parallel problems. I haven't yet set up a beawolf cluster myself,
but some commercial companies has already looked into using this technology
(at least we have).
For SMP I would like to use POSIX pthreads, BTW a free port of this API is
also available for Win32. I have done threads and mutex using the Win32 API
before, but with pthreads the C programmers can get portable code. There is
a good online book on the subject and I really think more C programmers
should know about this excellent standard.
Some relevant news groups I am lurking are
comp.parallel.mpi
comp.programming.threads
> > I felt that "Optimization" was too focused on micro-optimizing
techniques,
>
> I disagree, but I recognise the point. Without re-reading the chapter I
> can't quite recall what Mikey said about macro-optimisation, but I'm
> sure he covered it in reasonable detail.
Fair, but with modern optimizing compilers and modern CPU architectures in
mind, much of the old micro-optimizing tricks isn't simply true anymore. So
I think we should be careful about avocating it at all, both in books and
here. This is expert stuff, and I think even experts have hard times
micro-optimizing these days.
BTW, in the past I was for several years a regular member of a special
tuning group at work, where we each week did perfomance & tuning of a rather
big parallel on-line system, but after upgrading the HW last year, there was
simply no point in continuing this kind of work ...
However, every C programmer should have a copy of R. Sedgewick's "Algorithms
in C"!
> If I had the chance again, I think I'd want to add: more about embedded
> systems and Unix, since those are the platforms on which C's future is
Still I guess most "C programmers" use VC++, and Linux is gaining momentum.
Also I think hand held devices will be important.
> likely to rest; more about expression parsing and perhaps a bit on
I'm just writing some message parsing code as we speek...TLV hacking is fun!
> compiler-writing; a completely reworked simulations chapter; a chapter
I can't imagine a compiler-writing chapter just in C, even if Holub's
"Compiler design in C" is one of the C books I have really spent a lot of
time reading. Using lex & yacc is a simpler and better way IMHO.
> on neural networks, because they can be a lot of fun;
I don't know about neural networks at all, is it related to AI? In that case
it could be *really* fun reading about it.
> For me, the most important aspect of the book is that it doesn't try to
> teach you C (for the most part); I always wanted to focus on taking
> existing ISO C knowledge and showing what else could be done with it.
> I'm reasonably happy that we achieved that.
Yes fine work, I'm just nitpicking of course.
> And I'm equally happy that I
> managed to sneak in a chapter on sockets without anyone shouting too
> loud about its inherent non-portability. :-)
In the real world C programmers can't always be topical, we often need and
should use extensions of the language. IMHO, leaving out sockets
programming, would have been a *big* mistake. I would liked more on this
subject, e.g. how to handle proxy and how to integrate SSL (or perhaps SSH)
could have been of major interest.
Richard Heathfield
>
> I don't know about neural networks at all, is it related to AI? In that case
> it could be *really* fun reading about it.
Yes, it's related to AI; pattern recognition, for example. Basically a
neural network is "a collection of units that are connected in some
pattern to allow communication between the units. These units, also
referred to as /neurons/ or /nodes/, are simple processors whose
computing ability is typically restricted to a rule for combining input
signals and an activation rule that takes the combined input to
calculate an output signal". (R. Callan, "The Essence of Neural
Networks", Prentice Hall 1999.)
Could be a lot of fun to write a C library to do that kind of thing.
Dave Vandervies
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
<snip discussion of contents of _C Unleashed_>
>For me, the most important aspect of the book is that it doesn't try to
>teach you C (for the most part); I always wanted to focus on taking
>existing ISO C knowledge and showing what else could be done with it.
>I'm reasonably happy that we achieved that. And I'm equally happy that I
>managed to sneak in a chapter on sockets without anyone shouting too
>loud about its inherent non-portability. :-)
Well, if you're taking requests for the second edition:
I was really hoping for a `You can do *that* in C??!?' sort of chapter
that covered something (probably more a programming technique than an
actual application of some kind) that C isn't exactly known for making
easy. When the book was published I would've been happy with something
about how to make C do inheritance and polymorphic function calls (and
it's probably still not a Bad Thing for a chapter of this sort), but
now that I've figured out how to do that I'd be looking for something
else... maybe a way to do coroutines in strictly conforming code
without resorting to ugly macro hacks?
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
So C programmers now fill their code up with smiley faces. When will
people realise that digraphs were a practical joke all along? :-)
--Lawrence Kirby in comp.lang.c
Richard Heathfield
>
> Well, if you're taking requests for the second edition:
> I was really hoping for a `You can do *that* in C??!?' sort of chapter
I love volunteers. They're so cute.
:-)
Dave Vandervies
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
>Dave Vandervies wrote:
>>
>> Well, if you're taking requests for the second edition:
>> I was really hoping for a `You can do *that* in C??!?' sort of chapter
>
>I love volunteers. They're so cute.
>
>:-)
The problem with me volunteering for that is that if I'd write that
chapter, I wouldn't be able to look at it and say `Wow, you can do
*that* in C??!?' because I'd already know that you could.
dave
--
Dave Vandervies dj3v...@student.math.uwaterloo.ca
There are two kinds of fools -- those who never climb Mt. Fuji, and those who
climb it twice. --Old Japanese proverb (according to the BSD fortune file)
Vinay Pai
classes that do much the same thing. Don't ask here, thought. C and
C++ are different languages, and C++ is off-topic here.
"Tjelvar Eriksson" <tjem...@hotmail.com> wrote in message news:<yf%67.4598$h%2.9...@news010.worldonline.se>...
> Hi,
> I'm a complete newbie to c but well familiar with javascript/php and wonder:
>
> Does c support arrays, two dimensional, dynamicly resizable or how do i
> resize them
> and preserve it's content?
>
> I want to do:
>
> $twoDimensionalArr=array(array()); //declare the two dimensional array. I
> don't know it's dimensions yet.
>
> while (!recordset_eof_check) {
> $oneDimensionalArray=db_get_row($dbconn); //get one record from db as one
> dimensional array
> $twoDimensionalArr[]=$oneDimensionalArray; //add the array to the 2Xarr
> }
>
> How can I do this in C?
> I don't understand a blink of C with it's * & # % ^ so pleace comment any
> suggestions.
>
> Thanks,
> and try the superior open source database at firebird.sourceforge.net
Joona I Palaste
> No [1]. It is a declaration of a one-dimensional array of 10
> one-dimensional arrays, each containing 20 ints.
> [1] This is incorrect [2]. 6.5.2.1 of C99 says: Successive subscript
> operators designate an element of a multidimensional array object.
> [2] "But Richard - if you *knew* it was wrong, why did you say it?" [3]
> [3] I don't know. [4]
> [4] "You're weird, sir." [5]
> [5] Stop calling me 'sir'. [6]
[6] "OK, sir".
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller
David Lee Lambert
> David Lee Lambert wrote:
> >
> > /* program to compute the sum and difference of two numbers */
> > #include <stdio.h>
> >
> > int main()
> > {
> > int n1, n2;
> > int N;
> >
> > printf("Enter pairs of numbers; "
> > "EOF or any letter to terminate\n");
> >
> > while (!feof(stdin)) {
> > N = scanf("%d%d", &n1, &n2);
> > if (N < 2) break;
> > printf("sum= %d diff= %d\n", n1 + n2, n1 - n2);
> > }
> >
> > return 0;
> > }
> > /* end of program */
> >
> > This program illustates variables, looping, and string-constants, as well
> > as basic arithmetic and declaration of variables.
>
> Unfortunately it is just plain WRONG. The !feof statement won't
> do what you want. The scanf is dangerous, and will barf on
> extraneous chars in the input. You didn't compile and test it.
I beg your pardon... I did indeed compile and test this, and it acted
according to my ideas of how it should work...
As I was saying, an introductory C program should show something that is
short, simple, yet completely correct. This program may not be
well-commented or user-friendly -- these are open to debate -- but it is
*correct*, except that feof() may be superfluous.
This is how I should have specified the program:
"This program will read pairs of integers seperated by whitespace from the
standard input and will print out their sums and differences. If it
cannot parse another pair of numbers, and in particluar at EOF, it will
quit." (Actually, this should be clear from the help-text.)
Line-by-line input requires a discussion of character arrays, and, to be
completely correct, requires fgets() and sscanf() -- hardly the first
functions to introduce to a beginner. Interactive input adds another
dimension. Even input validation requires advanced tecniques or
nonstandard functions such as regex().
In order to counter your objections, I propose another example:
/* program to compute the sum and difference of two numbers */
#include <stdio.h>
int main()
{
int N, dn = 1;
int n, m;
printf("Enter pairs of numbers; "
"EOF or any letter to terminate\n");
while (scanf(" "), !feof(stdin)) {
N = scanf("%d%d", &n, &m);
if (N < 2)
goto err;
printf("sum= %d diff= %d\n", n + m, n - m);
dn++;
}
printf("EOF\n");
return 0;
err:
printf("parse error in item #%d\n", dn);
}
/* end of program */
Of course, if I've misunderstood what you mean by "feof() won't do what
you want...", please explain in more detail. However, I hope you'll try
to run the program first...
--
DLL
David Thompson
...
> As I was saying, an introductory C program should show something that is
> short, simple, yet completely correct. This program may not be
> well-commented or user-friendly -- these are open to debate -- but it is
> *correct*, except that feof() may be superfluous.
>
example because it tends to cause the learning of false beliefs,
that one should or even must use it this way. You are right that
the prior poster's criticism was too strong; feof() and [f]scanf()
often (especially in code posted here?) are misused to produce
infinite loops and garbage results, but you avoided those shoals.
> This is how I should have specified the program:
>
> "This program will read pairs of integers seperated by whitespace from the
> standard input and will print out their sums and differences. If it
> cannot parse another pair of numbers, and in particluar at EOF, it will
> quit." (Actually, this should be clear from the help-text.)
>
Pretty much. Personally I would make the prompt/instruction
"Enter pairs of integers" because to anyone who actually paid attention
in high school math "number" includes real and complex (and rational!)
and entering those to this program won't work. Unless this is used in
a context where the numbers are necessarily counts or other integers,
e.g. "numbers of sheep and goats" or "Erdos numbers".
> Line-by-line input requires a discussion of character arrays, and, to be
> completely correct, requires fgets() and sscanf() -- hardly the first
> functions to introduce to a beginner. Interactive input adds another
> dimension. Even input validation requires advanced tecniques or
> nonstandard functions such as regex().
>
It doesn't strictly _require_ these functions, but they are usually
the right way (which you want to teach) so accepted arguendo.
> In order to counter your objections, I propose another example:
...
> while (scanf(" "), !feof(stdin)) {
> N = scanf("%d%d", &n, &m);
> if (N < 2)
> goto err;
> printf("sum= %d diff= %d\n", n + m, n - m);
> dn++;
> }
>
In case of I/O error during the scanf(" "), feof(stdin)
still returns false, the second (body) scanf() also fails,
and you somewhat misleadingly report "parse error".
EOF or I/O error during the second scanf() produces
the same message, which is arguably correct in the
first case (since an odd number of input values
violates the stated format requirement).
IMO the least bad way of doing this is
while( scanf("%d%d",&n,&m) == 2 ) { .. body .. }
if( feof(stdin) ) ..EOF..
else if( ferror(stdin) ) ..I/O error..
else ..(available but) bad input..
but any *scanf is still subject to Undefined Behavior
if a numeric input value overflows the type (here int).
(Also if string/char input exceeds the buffer it is stored to,
but that you can prevent, sometimes clumsily, with widths.)
> printf("EOF\n");
> return 0;
> err:
> printf("parse error in item #%d\n", dn);
> }
In C89 need a return 0; (or something, e.g. EXIT_FAILURE) here,
and even in C99 I consider it (much) better style to be explicit.
--
- David.Thompson 1 now at worldnet.att.net