for and arrays

[Bill Cunningham]

I understand this code.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

This should take every element of the array a and set it to 1,2,3,4,5.
Great. Now for the big question. How would you work this?

int a [5][3];

And make the first element of 5 all zeros and the second element of 3 equal
to 1,2,3 ? I don't know how to work with a 2 dimensional array.

Bill

 

[Ben Bacarisse]

I understand this code.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

Did you try?

This should take every element of the array a and set it to 1,2,3,4,5.
Great.

No, a loop that "sets" things will usually have an assignment in its
body.

Now for the big question. How would you work this?

int a [5][3];

And make the first element of 5 all zeros and the second element of 3 equal
to 1,2,3 ? I don't know how to work with a 2 dimensional array.

I'd stick with 1 dimensional ones. If you are in this for the
challenge of learning C, then it is much better to master the easy
bits before moving on. If you have some objective in mind (i.e. you
want to write some specific program) then you should pick a language
with fewer pitfalls and peculiarities than C. In particular,
interpreted languages let you learn by trying things out which, I
suspect, is a style that would suit you.

 

[Bill Cunningham]

I understand this code.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

Did you try?

Well I tried and it compiled with no errors. Or atleast compiled anyway.
Yes this is an excercise to learn. All I do is an excercise to learn. What
if one had an array of 500 ints and had the simple task of setting them
1-500? How's this for another take.

int a[10];
int b;
for (b=0;b<10;b++) {

a[ b=b+1];
}


Bill

 

[Ben Bacarisse]

I understand this code.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

Did you try?

Well I tried and it compiled with no errors. Or atleast compiled
anyway.

You must have found out by now that a program that compiles is like an
essay the spell-checks. It does not mean you've answered the question.

Yes this is an excercise to learn.

Compiling it is not enough, then. The wonderful thing about
programming is that your program can tell you if you've got it right.

All I do is an excercise to learn. What
if one had an array of 500 ints and had the simple task of setting them
1-500? How's this for another take.

int a[10];
int b;
for (b=0;b<10;b++) {

a[ b=b+1];
}

Let's assume that you intended to write a[500] rather than a[10]. You
need to move one character characters to turn the above into
a program that does what you want, but can you see which character
needs to move at to where?

[I still think that you should learn an interpreted language.]

 

[Keith Thompson]

I understand this code.

No, I'm afraid you don't.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

This should take every element of the array a and set it to 1,2,3,4,5.

You seem to be thinking that the line "int a;" assigns a value to
an element of a. In fact, it doesn't do anything at all like that.
Knowing what it actually does won't help you, so please ignore the
following. (It declares a VLA which hides the declaration of a.)

Just this once, I'll give you a freebie. If you want to set the
elements of a to 1, 2, 3, 4, 5, here's one way to do it:

int a[5];
int i;
for (i = 0; i < 5; i ++) {
a = i + 1;
}

Great. Now for the big question. How would you work this?

int a [5][3];

And make the first element of 5 all zeros and the second element of 3 equal
to 1,2,3 ? I don't know how to work with a 2 dimensional array.

You don't even understand what a 2 dimensional array is. Your
question assumes that it's a 5-element array followed by a 3-element
array. It isn't. It's a 5-element array, each of whose elements is a
3-element array of ints, for a total of 15 (5*3) ints.

Here's a conceptual picture of your one-dimensional array, where each
'#' represents an element that can hold an int value:

+-+-+-+-+-+
|#|#|#|#|#|
+-+-+-+-+-+

And here's a corresponding picture for your "int a[5][3];":

+-+-+-+
|#|#|#|
+-+-+-+
|#|#|#|
+-+-+-+
|#|#|#|
+-+-+-+
|#|#|#|
+-+-+-+
|#|#|#|
+-+-+-+


But you shouldn't even be thinking about 2-dimensional arrays until
you have a firm grasp on 1-dimensional arrays.

 

[Bill Cunningham]

You don't even understand what a 2 dimensional array is. Your
question assumes that it's a 5-element array followed by a 3-element
array. It isn't. It's a 5-element array, each of whose elements is a
3-element array of ints, for a total of 15 (5*3) ints.

I understand if I am correct that each of the 5 elements have 3
elements. Yes. What I didn't understand was

a=i+1;

Bill

 

[Barry Schwarz]

I understand this code.

No, I'm afraid you don't.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

This should take every element of the array a and set it to 1,2,3,4,5.

You seem to be thinking that the line "int a;" assigns a value to
an element of a. In fact, it doesn't do anything at all like that.
Knowing what it actually does won't help you, so please ignore the
following. (It declares a VLA which hides the declaration of a.)

Since there are no braces around the statement, it is a constraint
violation in C89 since declarations must precede statements. Even in
C99 it should be a duplicate definition of a.


Remove del for email

 

[Barry Schwarz]

I understand this code.

You are not even close as others have pointed out.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

This should take every element of the array a and set it to 1,2,3,4,5.
Great. Now for the big question. How would you work this?

int a [5][3];

And make the first element of 5 all zeros and the second element of 3 equal

What do you think the phrase "first element of 5" means? What about
"the second element of 3"? How many elements to you think this 2D
array has?

to 1,2,3 ? I don't know how to work with a 2 dimensional array.

Don't even try till after you understand 1D arrays.


Remove del for email

 

[Keith Thompson]

I understand this code.

No, I'm afraid you don't.

int a[5];
int b;
for (b=0;b<5;b=b+1)
int a;

This should take every element of the array a and set it to 1,2,3,4,5.

You seem to be thinking that the line "int a;" assigns a value to
an element of a. In fact, it doesn't do anything at all like that.
Knowing what it actually does won't help you, so please ignore the
following. (It declares a VLA which hides the declaration of a.)

Since there are no braces around the statement, it is a constraint
violation in C89 since declarations must precede statements. Even in
C99 it should be a duplicate definition of a.

It's also a constraint violation in C89 because it's a VLA. But I
didn't want to go into too much detail about why it's wrong. The way
to transform that into what Bill intended is to delete it and write a
correct line.

 

[Bill Cunningham]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ? Though I have even more to learn.
This C syntax is confusing. Bash and Perl are interesting though.

Bill

 

[Kaz Kylheku]

for (b=0;b<10;b++) {

a[ b=b+1];
}

[ snip ]

[I still think that you should learn an interpreted language.]

In light of that cute a[b=b+1] above, it better be one
that is very liberally interpreted, to the point of being
downright charitable.

 

[Bill Cunningham]

Bill Cunningham said:

[I still think that you should learn an interpreted language.]

I've come so far with C

No, you haven't. You're still failing to grasp Chapter 1 of K&R2, after
what must be something like a decade of trying. That isn't far. That's
near.

[snip]

About 5 years is more like it. And for one year I gave up on C. But
everything is in C or C++. Looking at Bash it doesn't look any simpler
really and in just looks C like. I need someone to explain things to me when
I get stuck. If I had a tutor you would be suprised in what I can pick up.
But that's one thing you don't get in clc. The one thing I need.

Bill

 

[Keith Thompson]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ? Though I have even more to learn.
This C syntax is confusing. Bash and Perl are interesting though.

No, I'm afraid you haven't come very far at all with C.

You might consider studying Python. Perl is largely a mish-mash of C,
AWK, shell scripting, and a few other languages. Python has a more
coherent design. Personally, I'm a big fan of Perl, but I don't think
it's the language for you.

 

[Bill Cunningham]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ? Though I have even more to
learn.
This C syntax is confusing. Bash and Perl are interesting though.

No, I'm afraid you haven't come very far at all with C.

You might consider studying Python. Perl is largely a mish-mash of C,
AWK, shell scripting, and a few other languages. Python has a more
coherent design. Personally, I'm a big fan of Perl, but I don't think
it's the language for you.

There's always assembly

Bill

 

[Ben Bacarisse]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ?

Learning is not like rolling a boulder up a hill. The learning does
not start to pour out of you head the moment you stop stuffing more
in. In fact, you may find that *more* of the C you've seen so far
"sticks" if you take a break and look at something else. The only
reason to keep going would be if you are very close to achieving some
goal with C, but that does not seem to the case.

However, the main reason is because I think you will get on better
with language that allows you to get immediate feedback from trying
things out. I don't say this without some experience of how people
learn programming. Some people are born planners -- they think, plan,
sketch things out, revise the plan, and then write an almost perfect
program first time. Other like to try this construct, have a go with
that idea, wonder why such-and-such behaves like so-and-so and, over
time, they can evolve a program. People in the first group would
prefer to read (often cover to cover) a reference type of book for the
language they are about to use. Those in the second like tutorials
with lost of examples and variations on a theme. I think you are
closer to the second group than the first.

You can learn any language using either style, but interpreted
languages suit the second group better, at least at first.

Though I have even more to learn.
This C syntax is confusing. Bash and Perl are interesting though.

Both are a Very Bad Idea (for reasons too messy and off topic to get
into here). I think you would prefer a language where the pieces fit
together in a logical and relatively unconstrained way. The best
example of that is Haskell, but all the best books are rather
expensive (and all the on-line tutorials seem to delight in too much
jargon). My top choice for you would be Scheme because it is clean
and logical and has excellent supporting texts, now entirely free on
the web. See http://mitpress.mit.edu/sicp/ If that is too far removed
from what you know, try Python.

BTW, far more significant would be to find a friend, nearby, who could
help you learn.

 

[Bill Cunningham]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ?

Learning is not like rolling a boulder up a hill. The learning does
not start to pour out of you head the moment you stop stuffing more
in. In fact, you may find that *more* of the C you've seen so far
"sticks" if you take a break and look at something else. The only
reason to keep going would be if you are very close to achieving some
goal with C, but that does not seem to the case.

[snip]

Goal? Read and understand file sections,headers, symbols and sectors. That
would probably involve hex dumps, debuggers, BFD knowledge and logic
understanding to take apart a program to bits and reconstruct whatever I
want like a new file format. That is the goal in my head. But one has to
learn a language with this and assembler will be involved.

Bill

 

[Ben Bacarisse]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ?

Learning is not like rolling a boulder up a hill. The learning does
not start to pour out of you head the moment you stop stuffing more
in. In fact, you may find that *more* of the C you've seen so far
"sticks" if you take a break and look at something else. The only
reason to keep going would be if you are very close to achieving some
goal with C, but that does not seem to the case.

[snip]

Goal? Read and understand file sections,headers, symbols and sectors. That
would probably involve hex dumps, debuggers, BFD knowledge and logic
understanding to take apart a program to bits and reconstruct whatever I
want like a new file format. That is the goal in my head.

I did not say you did not have one. I said, keep up with C if you are
close to achieving a particular goal using it. I don't think you
are. I.e. I don't think you will loose anything by trying a new way
to learn programming.

Your reply reads, to me, as if I have annoyed you. I am sorry if that
is that case, but I accept that it is almost impossible to avoid being
annoying in this medium. My suggestions about how you might change
tack were intended to be helpful. When the path to the summit is too
steep, going sideways can get you up there faster.

But one has to
learn a language with this and assembler will be involved.

Very few of these goals (things to learn about) are language specific
and although learning C might help, it seems to me neither necessary
nor sufficient for achieving them.

 

[Mark L Pappin]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ?

Because "so far" appears to be not very far at all. At some stage you
should consider cutting your (or in this case everyone else's) losses.

This C syntax is confusing.

The syntax is pretty fundamental to using the language.

Part of your confusion seems to be (as has been said numerous times)
that you start with a vague problem specification and then throw
isolated language elements at it, hoping that one of them will stick.

It has also been suggested numerous times that you try starting with a
simple problem specification and work until you have a complete
program that solves that problem (and understand the various issues
involved) _before_ you move on to the next problem, but you have
chosen not to do this.

As a consequence of your responses to the help you have been offered
here, more and more people are simply ignoring your posts, and thus
your pool of potential help is drying up. I don't like to see someone
with a stated desire to learn left ignored and ignorant so I'll give
it one try:

If you post answers to the following exercises here within the next
couple of weeks, and engage in reasonable discussion over any
commentary other posters make about your answers including
demonstrating that you can modify your code as directed, then I'll
spoon-feed you further exercises and you _will_ learn to program in C.
If you don't, then my killfile is happy to be of service (to me).

1. Copy and paste this code (between "/*begin1*/" and "/*end1*/") into
a new source file, compile, and run it. What output does it produce?

/*begin1*/
#include <stdio.h>
int main(void){
/* you are not expected to understand this - it is to
verify that you can and will follow instructions */
printf("%s%c%d\n",
"protest"+3,
"blank space"[5],
27/3-2*2*2);
return 0;
}
/*end1*/


2. Write a program to print a single line containing the greeting
"Hello, world!" followed by a newline character.

3. Write 2 different programs to each print a single line containing
the digits 0 through 6 inclusive, separated by spaces, followed by a
newline character. (Hint: the simplest will look a lot like your
answer to exercise 2 above; a more complex one will use a 'for' loop.)

Bash and Perl are interesting though.

.... but off-topic here.

mlp

 

[Bill Cunningham]

[I still think that you should learn an interpreted language.]

I've come so far with C now why stop ?

Learning is not like rolling a boulder up a hill. The learning does
not start to pour out of you head the moment you stop stuffing more
in. In fact, you may find that *more* of the C you've seen so far
"sticks" if you take a break and look at something else. The only
reason to keep going would be if you are very close to achieving some
goal with C, but that does not seem to the case.

[snip]

Goal? Read and understand file sections,headers, symbols and sectors.
That
would probably involve hex dumps, debuggers, BFD knowledge and logic
understanding to take apart a program to bits and reconstruct whatever I
want like a new file format. That is the goal in my head.

I did not say you did not have one. I said, keep up with C if you are
close to achieving a particular goal using it. I don't think you
are. I.e. I don't think you will loose anything by trying a new way
to learn programming.

Your reply reads, to me, as if I have annoyed you. I am sorry if that
is that case, but I accept that it is almost impossible to avoid being
annoying in this medium. My suggestions about how you might change
tack were intended to be helpful. When the path to the summit is too
steep, going sideways can get you up there faster.

Annoyed? Well I do read this as if you are trying to help. But giving up
C is like giving up on math because you have trouble pulling products from
multiples from your head because you have trouble with multiplication. There
are calculators and you can go onto higher maths if you have a little help
with a calculator.

It's like giving up.

Bill

 

[Mark L Pappin]

I need someone to explain things to me when I get stuck. If I had a
tutor you would be suprised in what I can pick up. But that's one
thing you don't get in clc. The one thing I need.

I may live to regret it, but I'm offering - see my other post in this
thread.

Note however that I _will_ drop you like a schoolcase if you don't
demonstrate the requisite level of effort and progress. If this
policy is not to your liking, you get double your money back.

mlp