Exactly where GazL suggested in the next post beyond yours here.

I'd start new topics on a new thread not titled "tried to write something and have failed ...", that's not a good issue description by the way.

I know you've said the equivalent of, "so be it, and I'll let the mods decide."

I'm not proposing to split this thread, but it is 180+ posts, the topic title doesn't really say exactly what it was all about, and it has strayed greatly in thread topic, if again, one could say it was a topic at all, excepting the content of your first post as a guide.

If you choose to explore dynamic allocation and linked lists, great. It would be more clear about things if it came within a new topic and stayed on that primary topic until you were satisfied that you got that topic.

Personally I've not seen realloc() as being used much. Instead just malloc(), or calloc(), and free(). Why? Rather than try to "play" with memory in place or accept the possibility that a pointer may be changed as part of any re-allocation function, instead I allocate a thing once, use it, and if I ever finish with it, I free it. I'd recommend you stick with those fundamental behaviors first.

The MOST PROBLEMATIC issue that programmers run into involve memory leaks, stale pointers, and invalid pointers.

1. Memory Leaks: You do not free memory, you continue to allocate forever, and over time you eat up all the memory, when you didn't design for that, or intend to, but you still can do this.
2. Stale Pointers: People free things up, or pass a memory pointer along and something else frees it up, but another part of the code still tries to use that pointer. Guess what? It is not NULL, it points to memory, so no exceptions, or faults, however the memory which was freed up by someone else is now open for re-use by a future allocation, if you use that pointer, you may find the exact former data still there, or you may find random other data there. The computer won't intentionally overwrite freed memory, but in a future alloc() it may grant that memory to another function, or even process. And once it gets used for the new purpose, the stale pointer now really is a problem. Besides the fact that a pointer, pointing to freed memory is always a problem.
3. Invalid Pointers: If you have a pointer to allocated memory you keep it, you do not change it, because you may lose the original and thus when it comes the time to free that memory, how would you do it? So if you increment a pointer, or manipulate it in some manner that the heap allocation knows nothing about and you forget the original pointer, you have now put yourself in an impossible situation. This is the risk with functions like realloc(), they "may" move the pointer, or you "may" make a mistake as to how much memory was allocated for it. Why take this risk? It is unwarranted, and you can write your code to "keep track of pointers", "understand the size allocated and not make it random", and so forth.

Those are my recommendations and their reasons.

But it's all you.

Absolutely:
You ask a question I can decipher, and can follow, I'll answer it as best as I can, as well as admit where I'm off/incorrect on my answer.
You ask a question (hypothetical) that involves all examples from this entire thread, I'm going to answer the parts where I can review and offer help with, using as much effort as I can stand to put in.

Here's a point:
You're doing this learning. As I know very well, it helps "us" to help you, because we refine our learning too. But, I need you to "think". Why do you think I keep asking you questions while not shoving the answer and a full example at you? Why do I persist with asking you to use GDB? Because (1) I don't want to re-see the statements, "I'm totally lost! I have no idea!", and etc, and (2) I'd like you to use that analytical mind which you use very adroitly when you answer a complex Linux packages or install question, and apply that to this topic.

You've been given the tools. Say to yourself, "Wait. I'm smarter than this! This is supposed to be a known, easy example. I can get this!"
And then use basics to aid you in diagnosing the problem.

All a computer does is to address and manipulate memory and to test memory and branch. I know you're not looking a CPU microcode, but if you look at the older ones the more simple ones, you'll see that there are bunch of addressing modes which allow you to locate a spot in memory. You then can copy the data to somewhere else, or change the memory you are looking at. You also can test that memory and then branch your code based on the result. That's it. All the library functions are is vastly great window dressing, they are useful. My ulterior point is that every time I've tried to write "cool" code, either funny looking, or somehow clever, because it was fairly obtuse, I either get it and then very few can understand it moving forwards, so it's not useful in work, I have to document or explain it, and peers reject it, or, I get it vastly wrong and I go down a rats maze trying to decipher it, all the while knowing that if I just "did" it the normal method, I'd have been done days ago. And so how do I get out of that funk? I go back to fundamentals.

4 members found this post helpful.

Thank you GazL. That makes sense. I might go back a little further in the book and re-read about arrays before I try understanding those functions - particularly multidimensional arrays. Thanks again for all of your help!

RT, first off, thanks for the info - I can see myself reviewing your post above at a later stage to reinforce my understanding of what you've said above (and I will be reviewing it at some point). So thanks again for that and the rest of the help you've given me.

While I DO understand why you say what you say about analyzing things, and debugging with gdb, etc, and I'm not saying you're wrong either - I hear you. When I answer a non-programming related question here; First I ask myself; do I know anything about the issue the OP is asking about? If the answer is a flat out no, then I generally move on to the next thread. If the answer is yes, then I look at what their saying and think "what could be the problem based on what the OP is saying? Then go from there. If I have a problem myself, and I do know something about the issue; I think "well, based on what I can call fact, what could be the problem?", then try the old "process of elimination" to try get to the reason(s) for the problem(s). And/or I look at any error messages from the software concerned, logs, whatever else related to the issue(s). And go from there. So as an example; I try and mount something formatted with NTFS, but I get an error message from say mount telling me it can't mount it. I'd check that the ntfs-3g package is installed, let's say no it isn't; I go ahead and install that package, and I can then mount it - problem solved. The point: I don't need to know how the ntfs-3g driver is written to know any of that. Would I even know where to start to write my own ntfs-3g driver? No, no way - which is exactly why I wouldn't even attempt to try doing that. So again, I get what you're saying there, and have indeed tried employing the same with programming. But unless I not only correctly understand both the problem and how to solve it, it's still near impossible for me. It was only because of Mechanikx's post #169 that structures finally make more sense to me now. As trying to properly understand the examples in the book was like looking for a needle in a haystack - it was impossible. It's only because Mechanikx explained it in the way he did and I could visually SEE what he was saying with the examples he gave in the same post. The point: trying to sit there analyze what the book or anyone was saying without that would not have made it click. That's just how I learn, there isn't anything I can do about that - I would if I could, believe me. As I said in my other thread here in Programming; I'm a visual learner, not an auditory learner, nothing I can do about that.

I tried some years ago now to do a Civil Construction course, the trainer asked everyone in the room to organize into groups of three. Then with two people sitting behind the third person, asked those two people to give guided instructions to the person sitting in front of them on how to build a paper plane with the piece of paper he had given them. This is with every group saying out aloud how to build the paper plane to the person sitting in front of them. It come my turn to try and follow the instructions from the two people sitting behind me to build the paper plane. I could not understand what they were saying, so I put the piece of paper down, then said "I'm sorry, but I cannot properly hear what the instructions are, so I'm not even going to try and do it". The trainer noticed this, then said to everyone "STOP, James (myself) has stopped even trying to build the paper plane, because he doesn't understand the instructions from the two people sitting behind him. This was the whole of asking you all to do that: to see if anyone would actually stop. You all kept trying to build the paper plane anyway, even though it was impossible to properly hear and understand the instructions you were being given. The lesson here is that: if you don't understand what you're being told: then STOP and ask for clarification!" - I was the only person who stopped even trying to build the paper plane. The point: I'd much rather admit it when it just isn't clear to me, and I don't properly understand something. Rather than make even more of a mess of it. Speaking of which...

I was trying to get another program I wrote in my other thread in the Programming forum here to detect an integer overflow, but even looking at the example GazL posted, I still cannot figure out how to even express the if statement to actually check for it. In the CODE block below, and while I've looked at it several times now, I'm still not understanding why "sum" is being subtracted from INT_MAX and INT_MIN. I know "sum" stores the result of summing the entered number. I know INT_MAX specifies the maximum integer amount that the machine can store, and the opposite for INT_MIN. But it's still simply not obvious to me exactly what's going on in the if statement below, even though the rest of GazL's example here does seem to make sense (as well as GazL's description they gave in the same post below the example itself). The point: it's one thing to understand how a program works at a "high level"/just using it, it's another thing to understand how software works at a low level. So my "analytical mind" is still going"Um, ah, ah, I don't f***ing know!!!". Is that your fault RT? Is that anyone else's fault? Of course not. So I wish I could just "analyze" it and figure it out too, and I can't tell you in words how frustrating it is (particularly when as you say, I can usually solve non-programming problems other posts here at LQ - like one of the forum's you mod here RT being Newbies there), to know what the problem is, to even know why I'm having the problem, to know exactly where the problem is, but still have no f'ing idea HOW to fix it.

All of that said, if I have any further questions about structures or pointers, then I'll start a new thread instead. I'm also happy to start a new thread about how to get the bloody thing to actually detect an integer overflow/underflow as well - if you think I should RT. Thanks again.

A primary skill of a programmer is to be a problem solver.

You do not appear to be developing this skill at all.

To be honest, I wouldn't worry about integer overflow while you're starting out. It's something to be aware of but it's an unnecessary complication for a beginner. Once you get the hang of things you can start to worry about things like that and code more defensively.

Anyway, lets say INT_MAX is 10 (which it obviously isn't but it makes this example easy).

If I have a variable n that is set to 6. Then INT_MAX - n = 4, so it is safe to add any number less than or equal to 4 to n. What you can't do is: if ( n + 5 <= INT_MAX) because you can't safely add the 5 to n in order to check if you can safely add 5 to n, because you just did!
See how it works? There's no magic here.

BTW, lineArray was only a single dimensional array. The fact it was an array of pointers doesn't change that.

It's definitely worth going over the chapter on arrays and pointers again. When you understand that given:
char a[] = "wibble"
why both, a[4] == 'l' and *(a + 4) == 'l' are the same, then you'll be ready to use arrays and pointers interchangeably.

P.S. You've been struggling with the Kochan book all along, perhaps an alternative might suit you better if that one doesn't fit with your learning style.

1 members found this post helpful.

Thanks again GazL.

Just to clarify; I didn't mean to make you think that I though "lineArray" was a multdimensional array - I just meant that's something I'm still a little iffy about. Sorry for misleading you GazL.

In all honesty, I think you're probably right in the sense, and for example, and to use pointers as an example (but not limited to); while he does quite a good job explaining things don't get me wrong, I didn't really understand what a pointer actually "was" before ntubski said in my other C thread that they contain memory addresses - that just wasn't clear beforehand. Yes, they obviously "point" to something else, hence the name "pointer", but without the full context if you know what I mean, it's hard for me to properly understand anymore about the subject in question. This is what I was trying to say in my last post to this thread. It was the same story with structures before Mechanikx made them much more clear (as I was saying above).

It's much easier to fix problems with software at a "high level" (not programming) that's already been written, as I've already learnt how to install Linux configure various things, etc. I learnt all of that by doing, I didn't really learn all of that by trying to figure out exactly how stuff works per se (if you know what I mean). Sometimes it was/is just by trying different things until something works, and/or it becomes more clear. It took me years in any case to know what I do know about Linux - I didn't read a book about it.

So yes, I think you have a point when you say my "learning style" - clearly it's not the same as other people's. Again, if I could help that, I most certainly would - I can't. BTW, can you recommend anything that would make things clearer?

Thanks again for all of your help GazL.

The only books I've ever read on the subject are the Kochan book and the original K&R "The C Programming Language" book, so I'm not really well placed to offer advice on that one. Maybe just google for C tutorials and see what comes up? Try a few different ones until you find one that makes sense to you.

No worries GazL. Thanks again for all of your help.

Perhaps I should just forget about trying to learn programming. I really don't know at this point...

A while back in one of your other threads you said something to the effect of "How am I supposed to understand how x works when I can't even understand/see how a while loop works?". Would you be able to elaborate on that a bit? What part of it is unclear to you? Correct me if I'm wrong but you have made a few references to not being able to "see" how it works. I understand what you said about your Civil Engineer course, but in this instance what do you think you would need to see in regards to a while loop in order to understand how it works? Or any other concept you are fuzzy about and need to see how it works in order to comprehend it?

I maybe wrong here, so if I'm wrong someone please correct me, but maybe you should start looking into some of the underlying concepts of programming. Nothing too in-depth or advanced but enough to give you a general idea about what's going on beneath the surface.

Below is a link to a youtube channel. It teaches some underlying concepts while at the same time being geared towards beginners. If I remember correctly his examples are for 32-bit. So there will be differences compared to 64-bit. But I think this would be enough to get you started in the right direction. Or maybe to just eliminate a possible path for right now.

https://www.youtube.com/user/mycodeschool

1 members found this post helpful.

I wouldn't say you're "wrong". While I'm not sure how to explain it in a way that will make much, if any sense, but I'll try since you ask...

So to use your post #158 (I think I meant to cite that post in my last post actually - so apologies about that) and structures as an example; you explained that the "today" variable is indeed of type "struct date" (in that example). You explained that "today" is actually a structure with the member variables defined under the "struct date" declaration, so "today.day", "today.month", etc. Then you actually posted the context of what you meant by that, so you explained that the code below is like a "template".

Then you explained that the "struct date today" line actually creates the structure and let's me actually USE it - it wasn't clear to me beforehand what the "date" part of "struct date" was verses the "today" part of it. More to the point; that makes it clear that "today" IS actually that structure, and that "struct date" by itself simply just tells gcc; this is what a structure beginning with "struct date" actually looks like, and what member variables it holds - if that makes sense. So not only the way you explained it, with the way you showed how it works was much clearer to me than trying to "read between the lines" in the book. As "it's declared as type struct date" simply doesn't mean much to me without the context that spells the above clearly - I could actually visually SEE what you meant by simply following not only what you explained in your post #158, but also the examples you gave in the CODE blocks in that same post. Otherwise I may think, "well, is it of integer type, a float, a char????", rather than "is of type struct date" is in; that's the NAME of the "template" that defines what members the structure has - so I could have "now" instead of "today", and the only thing that changes (as long as it's still "of type struct date") is that, it actual structure would look like "now.day", "now.month", etc - again, that simply wasn't clear to me in the book.

Perhaps maybe even more to the point would be GazL's post #430 about pointers and functions here in my other C thread; They explained that the function gets an independent copy of the pointer, that both have the same value initially/point to the same memory location. Then gave an example program that actually prints out the actual value of the pointer in question, so I could visually see what they were saying. Then they also explained it in simple terms below their code example. That's what I meant by "I need to be able to SEE it", so again, depending on exactly what it is you're talking about, that may not be clear by just running through the program with gdb - or indeed, printf might be able to show me just as much without even needing to run it through gdb.

I know what I'm saying sounds funny, I know - sometimes I have trouble trying to understand how my own mind works in that regard. But it's just the way it is, nothing I can do, their the cards I've been dealt. This is what I mean about being a "visual learner" rather than an "auditory learner".

So if we take a non-programming example as one more example; did I read a book about installing Linux when I first installed it many years ago now? No. I just done it by following the visual prompts on screen (I already knew what partitions where, etc). Perhaps a better example would be when I learnt how to use the MS-DOS command-line back in the day; did I know what even just half of the commands actually did, let alone how they worked? No. I run the ones I know from it, then saw what happened. Then tried figuring out WHAT actually happened, and how you're supposed to use them. Again, I didn't read a book about it beforehand. I didn't try and figure out how I was suppose to use them, and even what said command actually done - I just learnt by doing. I remember editing I think it was autoexec.bat from memory, or it could have been config.sys (don't remember for 100% now), trying to get the sound card to work (don't remember why it wasn't configured correctly). I DO remember trying every single value I could think of, and probably was sitting there for at least an hour trying, then I finally put the correct value in (I think it was for the sound card's IRQ line), and hey presto, it worked! I didn't honestly really understand exactly what I was doing at the time, let alone why you had to have certain things in autoexec.bat and config.sys - I know now that autoexec.bat is for stuff you want to be loaded when MS-DOS starts up, and config.sys is for loading drivers, memory management, etc - didn't know most of that back then, other than MS-DOS looked at them when it started up, that was it.

The moral of the story is that; I can't normally just read about something to get a "complete picture" of it - particularly when what I'm reading isn't crystal clear. I need to be able to visualize how it works in my own mind before it makes "total sense" to me. Hopefully what I've said in this post makes at least some sense anyways.

Getting out of this that you are best served by examples with comments.

My suggested solution would be:

• One topic, one thread. Good thread title, and try not to evolve the discussion from the primary topic. Examples: "how to use C pointers", "Need help understanding C structures"
• Do not get into posting or examining full programs which cover other details beyond your thread topic.
• Post only the relevant parts of code or small test code where you do not understand, but keep the code as minimal as possible to not stray from your primary learning goal.
• Always suggest that it's best for people to offer you documented, and tested examples to help you learn. And ask them to not provide you with complicated examples containing off topic information.
• Absolutely start by posting your attempt. Keep the attempt simple without complicating it by having lots more code that is not related.
• Please understand that summarizing with a simple one line question is far better than a moderately long post describing how you've reached your present point.

1 members found this post helpful.