No need, it's already here. I don't think c is learned from a small tutorial.

1 members found this post helpful.

I agree sort of with both. Over the years, I've had a draft blog entry sort of titled, "C programming for beginners", and the time I've spent on it has been "every third year or so, for about 5-10 minutes".

While we all feel that there possibly can be better learning aids, (and this is long term recollection, since it's been 3+ years since I last tried any edits a.k.a. I dropped that effort entirely), each time I get to a point where I'm thinking, (1) I'd like to write something more interesting than hello.c, and also (2) illustrate something more useful/instructive where I can build upon it as an example and lesson plan. And then you get to thinking about the variety of concentration points you would advise a new learner about. You also may realize or feel that they could be different style learners than you, and you think of some people you've helped and where their messed up viewpoints led them astray. In the end, I'm realizing now that the best preparation for that all would be to develop an actual course syllabus, which would lead to a book. It's not just a small lesson, or tutorial. Those do help, but to really teach a new coder from scratch, it may involve the development of a course.

While I think there are chunks of this thread which would be very useful to a new coder, as observed earlier: ~500 replies, multiple pages to read, a lot of it may be confusing for anyone to start from scratch and get entirely through.

1 members found this post helpful.

Perhaps a rougelike game? That's a long-term project that can snowball into a suitable lesson plan.

I believe you misconstrue my meaning. I was not looking for ideas. I was saying that I believe any lesson plan may become the equivalent of a book and that I've long since decided to not continue trying to create any instructions on the matter.

However, by all means if you believe you have a realistic idea to create a useful guide, I suggest you start an LQ blog entry about the topic.

NOTE: This post is NOT a question - I'm only posting this in the event it might be helpful to others.

I come across another set of videos about C on YouTube which explained a few more things I wasn't clear on (rather by complete accident since I was actually looking for something else programming related), so just thought I'd post the link in case it might help others. I also now think I know what's meant by "an array decays to a pointer", in that, the array's name is in fact a pointer to the first element of said array. And this explains what exactly the array size does, and why it has a size in terms of the number of elements it has.

I also now understand why the chapter about "pointers" in the "Programming in C Third Edition by Stephen Kochan" was so bloody confusing the first time I read it. And I can even see how I would have written it differently to make things far more clear, after some practice, advice, watching some YouTube videos, and repeating that process. And now reading the chapter on "Pointers" for a third or forth time now, after all of the above.

Like for example, calling the address-of/reference operator the "address-of operator", instead of just the "address operator" as he calls it in his above mentioned book. And I also would have started the pointers chapter off by explaining what a pointer fundamentally IS.

So for example: "a pointer is kinda like a variable, but they contain a memory address. The address of what? Whatever the pointer is pointing to, hence it's name "pointer". The point is: a pointer can ONLY contain a memory address of what it's pointing to, it cannot contain anything else, and as such, the pointer itself does NOT contain the data itself that the pointer is pointing at. So if for example, we have a integer variable called "x", and that variable is stored at memory address 1, and we have a pointer called "ptr" that points to our "x" variable, then the value of our pointer called "ptr" would be that of memory address 1. Why? Because that's the location in memory that our "x" variable is stored at (in this made up example, but would almost certainly be stored at a different location in memory - but the principle remains the same regardless of the exact memory address), and that's what our "ptr" pointer is pointing to. Etc, etc."

Something like the above to start that chapter off would have made it far clearer WHAT a pointer actually IS, before the long-winded paragraph about "indirection" and why "indirection" is important to understand, and no, I'm not saying nor implying that "indirection" isn't important either. But with what I was saying above, then it would not only have directly implied what he said about "indirection", it would have made it far clearer. Instead of trying to read in-between the lines.

In any event, it's becoming much clearer all-round now - everything that is...

And no, I'm not going to get into some pointless debate about what names to use, etc either, bye.

I'm glad things are starting to come together for you. You had a rocky start but hopefully it's smoother sailing from here on in.

1 members found this post helpful.

Here are a couple of C books I own & can highly recommend:

1 (start with) https://users.soe.ucsc.edu/~pohl/abc4.html
2 (advanced but in fact explains C itself very well, inc c ptrs/arrays & C declarations) https://www.amazon.com.au/Expert-Pro.../dp/0131774298

Personally, I liked the first edition of "Programmin in C".

Somewhere in there it had that the array name is used like a constant address of a block of memory. Thus "decays into" is a silly phrase, and still allows the compiler to store extra information about the name (like size); and explains why there is no "sizeof" for pointers other than the size of the storage used for the pointer itself.

That's not quite true. The pointer that comes with an array behaves like that, but if you define a pointer separately, it has a size like any other variable. It's the same size as a long integer would be.

Here's one I did earlier:
The output was:
Size of name is 20
Size of pointer is 8

It is not necessarily the size of a long.

It depends on the architecture. A system with a 16 bit pointer using 8 bit bytes it will be 2 , yet a long could be 4.

This is why I said "other than the size of the storage used for the pointer itself".

1 members found this post helpful.