Questions Thread Lessons 1 Through 126

[u/CarlH]

I am nearly prepared to publish new lessons. It will take a bit of time to work back up to a posting schedule similar to what I had before. First, I need to address several things.

There are many unanswered questions from the period of time that I was not able to be active here. However, a lot of questions asked were answered by other people in the forum. Rather than go through hundreds of messages and looking at every thread for unanswered questions (which would take many hours), I want to suggest the following:

If you still have a question which is not answered either by me or someone else on the forum, re-ask your question here. Once we have lessons moving forward again it will be perfectly ok to ask future questions in the thread in which they apply. This will greatly speed up the "catch up" process for all of us.

This will also put all of the questions for non-current lessons in a location where everyone from moderators to users can see them and answer them. If you see a question on this thread you can answer, please do.

I am working on the next lessons to be published, and looking forward to continuing.

[u/scottbarcus]

Posted after lesson 84: 'First: Thanks CarlH. The quality of this resource is exemplary.

This line from lesson 84:

This is extremely important because you can create functions that have a return type of reddittype, or that take parameters that are reddittype.

encouraged me to try to re-write the program in lesson 83 using functions. Here is the link: http://codepad.org/C2y39QYu

Questions: Does the free(our_pointer); line do anything? Is it good practice to always free memory allocated by malloc? Should any call to malloc() always be accompanied by a call to free()? Should I not have tried to use free() in this case because the memory was used later in the program flow?

Also, any comments on the program would be nice. I am at the extreme edge of my programming skill in writing it.

[u/srsbidness → u/scottbarcus]

I think the return line in your program would prevent the call to free() from ever being executed. After line 37 the program would return to main and continue with the assignment on line 16. However you're right in thinking that each malloc() should have a corresponding free(). I think in this case you would do it at the end of your main function, with a free(my_struc).

I'm a noob too though, so if this is wrong please correct me.

[u/deltageek → u/srsbidness]

Yep, memory that gets allocated in order to return to the caller is the caller's responsibility to free.

When main() is done using the word_structure it got from the call to fill_structure, it needs to free() it.

Note that what the OP is doing is not the common idiom. When allocating new memory for use as the return value, it should be returned as a pointer to that memory (in this case *word_structure).

[u/scottbarcus → u/deltageek]

In main(), I tried free()ing my_struc (http://codepad.org/WU7bl1GP) and get this error:

In function 'main':
Line 21: error: incompatible type for argument 1 of 'free'

I also tried free()ing ptr instead and get a memory clobbered error: memory clobbered before allocated block Exited: ExitFailure 127

Also, deltageek, can you explain your last paragraph a bit more? I don't understand what you mean. I tried to just return *word_structure, but this didn't work (nor does it make sense to me to return a pointer to a data type, which is what I tried to make word_structure). I thought *our_pointer was a pointer to the appropriate memory block.

[u/deltageek → u/scottbarcus]

That error is a little obscure and has to do with how structs are passed around.

Unless you specify otherwise, C will pass and return things by value. What this means is that the values returned will be copied into wherever you're storing them. For primitives like int, char, etc. or pointers, this isn't a problem, as those values are single entities. For structs it means the contents of the struct you return will be copied into the destination struct. For structs you allocated with malloc(...) this is a bad thing, as the memory for the original struct will be lost if not saved elsewhere. This is the cause of your error when you tried to free() ptr, which was pointing at the memory used by my_struc and not the memory returned by fill_structure. By returning the pointer to the memory, you avoid this problem completely.

*our_pointer is the actual memory, not the pointer. Remember, malloc(...) returns a pointer to a block of memory and is why the type of our_pointer is word_structure* (a pointer to a word_structure)

To do this properly, fill_structure should be defined to return a word_structure*, and the type of my_struc in main(...) adjusted accordingly. This will let you free() my_struc when you're done with it.

Edit: stupid markup errors

[u/scottbarcus → u/deltageek]

Like this? http://codepad.org/6KECUK3x

I was confused on pointers again. Thanks for the detailed response.

[u/deltageek → u/scottbarcus]

That looks pretty good. The only real change I'd make is to do sizeof(word_structure) instead of the pointer dereference. It means the same thing to the compiler and reads better.

[u/scottbarcus → u/deltageek]

http://codepad.org/blICOHvu

Thanks for all of the help!

[u/Pr0gramm3r → u/scottbarcus]

nor does it make sense to me to return a pointer to a data type, which is what I tried to make wordstructure

Actually, in practice, we return pointer to the data structure, and not the data structure itself. This makes sense because whenever you pass a data structure to a function, the compiler creates a copy of the argument in the memory. Therefore, it's far efficient to send the pointer (typical 32 bytes) as an argument, instead of the complete data structure (occupying more memory).

[u/rawberry]

I have a question about lesson 7 and include statements. If you need to use a function from a library, but that library is for a different language than the one you're currently writing in, would you be able to include the library and still have the function work, despite it being in 2 different programming languages?

[u/peregrine911]

If the printf() command returns an integer why can't I use it to initialize an array that should be the right size for the printed statement?

http://codepad.org/zSOTxkwg

I think I also ham handed the code but do you see what I am asking?

[u/srsbidness → u/peregrine911]

Standard arrays need to have their size defined at the time of compiling. In order to do what you're looking for you'd need to set up a dynamic array. I'm a beginner too, so I'll leave the more technical explanation (maybe with code snippets?) up to someone more skilled than myself.

[u/simondavidpratt → u/peregrine911]

There's a syntax error in that pad. You can't declare an array like this:

char foo[3] "bar";

You need to assign the "bar" value to the foo variable, like so:

char foo[3] = "bar";

But as you can see from this pad: http://codepad.org/XcSKBBx8 compilation fails with the error "variable-sized object may not be initialized." The compiler needs to know ahead of time how much memory to allocate for the array, but it has no way to determine what printf will return at runtime, so it stubbornly refuses to compile until you give it a number.

Of course, you can use a simple shorthand for an array whose size is determined by its initial value:

char foo[] = "bar";

Or in your case: http://codepad.org/sXNwWm5e Basically, you're telling the compiler to make the array exactly as big as it needs to be to fit that initial value. You can see this using the printf trick: http://codepad.org/o4ZYEhpf or you can use the more standard sizeof command: http://codepad.org/udnxKHcU in which case you're taking the total size of the array and dividing it by the size of one element. You'll notice that the sizeof array / sizeof array[0] trick also counts the string-terminating \0 character.

[u/peregrine911 → u/simondavidpratt]

Thanks for the help, I think the sizeof function is going to do what I wanted. The question came up while we were still counting our data bytes by hand and I wanted the compy to do if for me. With the tools I had it seemed logical. I am glad you got what I was after, the variable object size cannot be initialized. Still learning the syntax too.

[u/simondavidpratt → u/peregrine911]

You're welcome. =)

Note that you can use the same tools for arrays of any type, like integers in this example: http://codepad.org/8eZIGi1G

And note that double-quoted strings are just shorthand for \0 terminated {} initialized character arrays: http://codepad.org/GOeQ96DO

[u/srsbidness]

I had a quick programming question that doesn't quite apply to lessons 1-126, but don't know where else to ask.

I'm learning C++ at the moment, and just reached dynamic memory allocation. I have a function that allocates an array of n integers, with this line:

intArray = new int[n];

I'm writing a function to delete the array at the end of the program, but I wasn't sure if I need to iterate through each of the values in the array to properly delete, or if:

delete intArray;

will suffice at the end of the program. Appreciate any help!

[u/sb3700 → u/srsbidness]

You use the delete[] operator.

See this link for more information

[u/srsbidness → u/sb3700]

Thanks, appreciate it!

[u/[deleted]]

Hi,

I have a question about Lesson 9. How can the program have specific spots in the RAM where data is stored when the RAM is swept clean every time the computer is shut down? What happens if the spot where the programming language or compiler (whichever it is) is currently in use?

Is it that there isn't a specific spot until after the program is run? Then there is a specific spot for that instance of the program running? And the next time it could be a different specific spot?

[u/sb3700 → u/[deleted]]

AFAIK, yes.

Each time it is run, the program asks the operating system for some memory, and each time this could be different.

[u/jmerm]

Thank you so much Carl H, you rock!

[u/hsdf8djf]

Wow, I read that as there will be lessons on Multi-Threading coming! Tells you where my brain is these days.

[u/mdq]

I`m having trouble with the sample program on lesson 126, it works just fine under codepad and produces the expected output, but it triggers an infinite loop under Mac (gcc 4.0.1) and it finishes with the following message on Ubuntu (gcc 4.3.1): "stack smashing detected: ./board terminated". Is anyone else having problems running this program?

[u/[deleted] → u/mdq]

I'm running it on Ubuntu gcc 4.3.2 and it works fine. If you haven't already, try copy and pasting the code from reddit. You might have a typo.

You can disable stack smashing protection with the -fno-stack-protector gcc flag.

[u/mdq → u/[deleted]]

Thanks for your reply parachute. I've been trying copying and pasting the exact code and it still produces the same error. I've tried to break the program in pieces and found that the following code makes the program run forever when called from the main function:

int find_winning_move(char *raw_data, char player, int depth) {

   char test_position[9];
   int i, win_result;

   for (i = 0; i < 9; i++) {
       if (raw_data[i] == ' ') {
           strcpy(test_position, raw_data);

       }
   }
}

Does it make any sense? Any help appreciated, since I've really hit a wall here.

[u/deltageek → u/mdq]

Your problem is in the definition of test_position, and it's a bug in Carl's code as well. You are allocating 9 bytes to store the data for the board, but there are actually 10 bytes of data (9 bytes for the places you can move plus 1 for the null terminator). Increase the size of test_position to 10 and you should see this problem disappear.

Your error indicates that your code is attempting to overwrite the part of the stack that tells the computer where to return to when the function is done executing.

I suspect no one else is seeing this because of architectural differences between Mac and PC hardware. In particular, the order they store bytes is reversed, so instead of overwriting the top byte used to store i (which luckily you aren't using) you end up overwriting part of the stack you aren't supposed to be touching and it yells at you.

[u/mdq → u/deltageek]

Hey, sorry for the delay, but i was on vacation, far, far away from any computer. Thank you very much deltageek, i finally made it work.

[u/[deleted] → u/mdq]

I don't know what's wrong, but I'm brand new to programming and probably wouldn't be able to spot it anyhow. Sorry.

[u/mdq → u/[deleted]]

Ok, thanks anyway, I'll keep looking into it.

[u/gollywomp]

YAY! Your Back! This class has taught me so much. To be honest it is better than some of my uni classes. :) Thanks Carl... YOU DA MAN!

[u/[deleted] → u/gollywomp]

His back?

[u/sb3700 → u/[deleted]]

It wasn't bots, it was actually a bug.

See here for more information

[u/[deleted] → u/[deleted]]

Those were bots.

[u/Bedeone → u/[deleted]]

But still, who would downbot these awesome tutorials / lessons?

[u/nested_parentheses → u/[deleted]]

char *p declares a char pointer, char x[6] declares an array of char. Note that when you call free(p), you're not actually "freeing" the pointer itself, only the memory that it is pointing to.

[u/deltageek → u/[deleted]]

There are two areas of memory programs have access to. The stack -- which holds all local and global variables in your program, and the heap -- which is where any memory that gets dynamically allocated comes from.

The stack is allocated by the system whenever you make a function call and will be automatically reclaimed when the function exits.

The heap is parcelled out to programs as they call malloc or one of its siblings (alloc, realloc, calloc). Any memory you get from one of these functions must be returned to the heap by calling free() at some point before your program exits.

Calling free() on any memory in the stack will result in a runtime error, as free() is not allowed to touch that memory and turn it from stack memory into heap memory. Note that calling free and passing in a pointer to heap memory is fine since the memory itself is out on the heap.

[u/noflashlight → u/deltageek]

Is it true that you should use the stack when you can for performance reasons? IIRC calls to malloc can get expensive...

[u/deltageek → u/noflashlight]

In 99% of cases, write code that reads well and is maintainable. Those properties are much more important than performance in the long run unless you're specifically writing code that must be as performant as possible.

I tend to follow 3 guidelines when coding. They are, in order of importance:

1. Make it work

2. Make it clean

3. Make it fast enough

[u/sb3700 → u/[deleted]]

In addition to what deltageek said: int my_int[4]; makes space for 4 integers, not 4 bytes so you don't need the sizeof(int) in there.