Can someone help me "think outside the box"?

[SangoProduction]

Bloody hell. There's no programming forums I can ask on that allow such open ended questions (and I can't contact anyone in this class), so I'my desperately trying here. I'll try and walk through the question as best I can. I am just completely lost as to what this DM or "teacher" could possibly ever mean by "think outside the box" or "follow where your curiosity takes you". Because my curiosity takes me to YouTube. I legit think I am going to fail because I can't follow this son of a ****'s logic.

So, basically what's going on: Programming in C. We are to initialize 3 variables to anything (I set them all to 0), and then create pointers to them (ie variables that hold addresses of the variables they are pointing to). Simple enough. But then he wants, and I quote, "A good thorough explanation that shows you thought about it and put some effort into understanding it (even if not perfect)". Anything else is a grade of 0.

Part 2 is basically the same thing, but instead of initializing any variables, we just have an array of pointers (which, by default, points to some random spot in memory), which, when dereferenced, will try to interpret whatever it's pointing to as a whole number.

So, here's our short email conversation.


I've been thinking about it for about 2 and a half days now. I'm still not seeing what the big deal is that we're supposed to see. I mean clearly, we can see that the value of the pointers are addresses, and the dereferenced values are what they are pointing to. It's obvious that the variables are the expected sizes.

The only thing slightly potentially notable is the pointer sizes, which could, in theory, each be different (although, on my machine, they were always size of 4).

And it's pretty much the same story with part 2.

Clearly we have a bunch of hexadecimal representations of addresses, followed by whatever junk was in that location, interpreted as an int.

What deeper revelation are we supposed to have?



Those are important observations, but also somewhat superficial aspects of it that have already been mentioned. You narrowed your thinking to only what you have been told already, but to use an overused cliche, "think outside the box" on this.​



Can I get a hint of some sort?



What happens when you rearrange the variable declarations in part 1? What happens each time you run the programs? ​What do you notice about the addresses?​ Ask yourself what is about these addresses that's interesting. Why are they doing what they are doing? Let your natural curiosity explore it and wonder about it.


I mean, like.... clearly, the addresses are going to be different if you rearrange the order you declare the variables. The program is also put basically randomly in memory when loaded to run, so all the addresses are going to be different each time the program's run.

But again, that's just "superficial" stuff...I think. I can't tell what his definition of superficial is. What makes addresses moving around interesting? I don't know! I don't share his god damned mind. I don't know why he thinks it's interesting. He never even expressed that it was such outside of this email.

Does anyone at all have a deeper understanding of programming in C than me? Please. Or just a way to bull **** my way out of it. I really don't care at this point.

[Xanyo]

I only know basic programming, and this might not help at all, but...


I mean, like.... clearly, the addresses are going to be different if you rearrange the order you declare the variables. The program is also put basically randomly in memory when loaded to run, so all the addresses are going to be different each time the program's run.

It looks to me like you just need to elaborate. Expound on why the addresses will be different if you rearrange the order you declare the variables. If you need to, act like you're explaining it to someone with only basic programming knowledge, like me. I don't even know what you're referring to when you say "adresses". Try to look at it from an outside view so you can explain not only what the answer is, but why the answer is that.




Yeah, it can get annoying when teachers want you to do more than parrot back what they drilled into your head.


Again, I don't know a lot about programming, and this might not help, but I hope it does.

[Dekion]

Also not a programmer, but, is he referencing a pattern that appears when looking at the results of the program being run despite the changes in variables, or perhaps even a some indicator that the random factor isn't truly "random," again hinting at a sort of pattern? I did some old school programming *cough*Fortran 76*cough* back in my early college days...about 25 years ago, and any random number generator required a seed, thereby eliminating true randomness. I know that may not help, but, perhaps you can glean something from my rambling that will.

[weckar]

Crazy thought, but could it be that the core thing this teacher wants you to realize is the difference between a value and a container? And that even though multiple containers may contain the same value, they are still separate containers and therefore not equal?

Basic stuff, but you'd be surprised at how often people mess up on that.

[SuperPanda]

I teach literature in highschool and not program (at whatever level you're at) but my experience is that when a teacher asks you to think "outside the box" they are really asking you to think about the box itself and whether or not it is helpful.

between weckar and dekion's excellent responses you've got a solid foundation to go back to your area of studies and self-define "the box" so that you can "think outside" it.

[weckar]

Scary thought too for programmers: When you store a pointer, that location must become a value... you need another memory location to store it in, so you implicitly need another pointer...

See where I'm going with that?

[icefractal]

Are these in the form of pre-existing code, or are you supposed to write some that matches that description?

In the latter case, maybe what he's looking for is a usage of pointers that serves some purpose, such as:
Character fighter, ranger, wizard;
Character *front = &fighter, *middle = &wizard, *back = &ranger;

If it's the former, then my guess would be there's something semi-hidden about the code beyond what you describe. Are you allowed to post it?

[daremetoidareyo]

Scary thought too for programmers: When you store a pointer, that location must become a value... you need another memory location to store it in, so you implicitly need another pointer...

See where I'm going with that?

You'll have so many pointers around that invariably they develop a budding sentiences and eventually fall in love with each other; thereafter they begin creating entire caches of memory to store their babies. These baby pointers then carryon the tradition, and the population of pointers goes from linear expansion to exponential in the resource rich solid state harddrive of resources. But alas, RAM it turns out is the rate limiting resource, and entire populations of pointers crowd each other while disconnecting in ways unforeseen by their little cultures that they formed. And thus all pointers melancholily stall, trapped in an eternal loop of self perpetuating stasis, squabling over the scant available resources that are left. All of the pointers pray for an armageddon to shake the foundations of their state of maximum entropy frozen in time.

It's a rather beautiful testimony of the futility of all existence.

Hows that for outside the box.

[weckar]

I'd sig all of the above if my wrists hadn't endured enough slapping recently.

[SangoProduction]

Thank you all so much for your help. I'll try my very hardest to make this work. Thanks again.


You'll have so many pointers around that invariably they develop a budding sentiences and eventually fall in love with each other; thereafter they begin creating entire caches of memory to store their babies. These baby pointers then carryon the tradition, and the population of pointers goes from linear expansion to exponential in the resource rich solid state harddrive of resources. But alas, RAM it turns out is the rate limiting resource, and entire populations of pointers crowd each other while disconnecting in ways unforeseen by their little cultures that they formed. And thus all pointers melancholily stall, trapped in an eternal loop of self perpetuating stasis, squabling over the scant available resources that are left. All of the pointers pray for an armageddon to shake the foundations of their state of maximum entropy frozen in time.

It's a rather beautiful testimony of the futility of all existence.

Hows that for outside the box.
Very amusing.


Are these in the form of pre-existing code, or are you supposed to write some that matches that description?

In the latter case, maybe what he's looking for is a usage of pointers that serves some purpose, such as:
Character fighter, ranger, wizard;
Character *front = &fighter, *middle = &wizard, *back = &ranger;

If it's the former, then my guess would be there's something semi-hidden about the code beyond what you describe. Are you allowed to post it?

Preexisting code, basically. Sure.

#include <stdio.h>

int main(){

double a = 0;
int b = 0;
char c = 0;

double *ptra = &a;
int *ptrb = &b;
char *ptrc = &c;


printf("0x%x %i\n", ptra, *ptra);
printf("0x%x %i\n", ptrb, *ptrb);
printf("0x%x %i\n", ptrc, *ptrc);

printf("size of variable a %d\n", sizeof(a));
printf("size of variable b %d\n", sizeof(b));
printf("size of variable c %d\n", sizeof(c));
printf("size of variable *ptra %d\n", sizeof(ptra));
printf("size of variable *ptrb %d\n", sizeof(ptrb));
printf("size of variable *ptrc %d\n", sizeof(ptrc));

//part 2
int *array[10];
int i;

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

printf("0x%x %i\n", array+i, array[i]);
}

}


Scary thought too for programmers: When you store a pointer, that location must become a value... you need another memory location to store it in, so you implicitly need another pointer...

See where I'm going with that?

Indeed, Everything, is, in fact a pointer, when you get down to the OS level, at which point it's basically stored as an Array of pointers that can point anywhere within main memory. OK. I think I've got a good thread to go on here.


Crazy thought, but could it be that the core thing this teacher wants you to realize is the difference between a value and a container? And that even though multiple containers may contain the same value, they are still separate containers and therefore not equal?

Basic stuff, but you'd be surprised at how often people mess up on that.

Hmm *looks up container (computer science)*. I could work that in.


Also not a programmer, but, is he referencing a pattern that appears when looking at the results of the program being run despite the changes in variables, or perhaps even a some indicator that the random factor isn't truly "random," again hinting at a sort of pattern? I did some old school programming *cough*Fortran 76*cough* back in my early college days...about 25 years ago, and any random number generator required a seed, thereby eliminating true randomness. I know that may not help, but, perhaps you can glean something from my rambling that will.

Perhaps he does want a pattern. Perhaps.

In my original post, when I said randomly, I did mean that basically the algorithm that allocated memory, in which the program can run, was not known. (It could even be pseudorandomly pulling out enough contiguous space for it to run, in which case, no real pattern could be discerned. Although, no reasonable computer manufacturer does that. Even so, I doubt this thread is one which could be latched on to.)


It looks to me like you just need to elaborate. Expound on why the addresses will be different if you rearrange the order you declare the variables. If you need to, act like you're explaining it to someone with only basic programming knowledge, like me. I don't even know what you're referring to when you say "addresses". Try to look at it from an outside view so you can explain not only what the answer is, but why the answer is that.

That could be a possible route.

[Gruftzwerg]

Let your natural curiosity explore it and wonder about it.


wtf? I am really sorry for you. What kind of a jerk do u have as teacher? I would write an answer like this:


"We are not here to philosophy about C. We are here to "learn C".
A program language is a 100% logical construct. There is nothing to explore. You learn to write and read code. There is no space for natural curiosity and things to wonder about.

Consider to teach philosophy instead of programming languages, cause your teaching style is irritating and a waste of time. thx

[Hikarizu]

What I got when I asked a friend who enjoys contributing to stackoverflow:


The only thing that occurs to me is that will allocate consecutive addresses. For example if initialization 3 numbers one after another, their addresses will look something like this:
0xbfbd5054
0xbfbd5058
0xbfbd505c
Knowing that size_of(int) == 4,
4 = 0 + 4
8 = 4 + 4
c = 8 + 4
But I'm not sure if it's guaranteed. I guess that is not necessarily for the operating system to allocate contiguous block.

This or the abstract stuff the people before me mentioned.
Also: (that is a discord emoticon)

The teacher is slightly :trolleybus: IDK :smallsmile:
Tell me what was the great revelation if it's posted later.
Ask if something is unclear I had to translate it.

[icefractal]

The only things that come to mind are:
* A pointer is the same size, no matter what it points to.
* Pointers can point to pointers.
* An array is itself a pointer.
* When you add to (or do other math on) a pointer, it operates in units the size of the pointed-to type. Hence why "array + i" is the same as "&(array[i])", even though a pointer is more than one byte.

[A.J.Gibson]

I haven't read the whole thread, but (as someone else said) this is probably to get you to start thinking about pointer manipulation. The pointers will probably be sequential, so you what you've done is created an array of 3 values in memory. So you can say:

print(pointerA)
print(pointerA+4)
print(pointerA+8)

To get A, B, and C to print.

You could also create a pointer to a Long (8 byte) number and assign it the value of pointerA, and when you print it it will give you some huge number equal to A * 2^32 + B. I think.

On a side note, pointer manipulation like this is frowned upon in the professional world.

The other thing (already mentioned) is to get you to think about the different between a value of 0 and a value of 'not assigned'. Mistaking one for the other is a really common mistake in university. People will try to sum a group of numbers but not assign an initial 0 to begin with, and the result is a segmentation fault. It's like the difference between an empty box and a non-existent box - one can hold things, the other can not. The act of creating a variable assigns memory space to it - creating the box - and initializing sets the value inside the box other wise the initial value is whatever was there before hand). Creating a point creates a memory space to store the location of another memory space, but doesn't actually create the memory space it should be pointing at, so the pointer can not be initialized. If you use an uninitialized pointer, you could get any piece of data, though most likely it will point to something out of the segment of memory you have permission to access, and give you a segmentation fault.

[SangoProduction]

Wow. This is a lot of help. I really, really appreciate it you guys.

[John Longarrow]

When you initialize a variable you get back its address.

You can now reference that address in code without having to ask for it EVERY TIME.

You can either code your program as
"Go to address XYZ and return value"
or
"Go to <ADDRESS> and return value".

First only works if you already know where in memory you will be accessing. Second lets you write programs that can coexist with other processes and work regardless of where their values are stored in memory.

This means when coding your code does not read as

"Add one to pointer XYZ"

your code reads as

"Add one to VariableLoopCounter"

Is this closer to what you think your teacher is getting at?

[barakaka]

One project we had to do was taking the List container, and making it a SquaredList.

Use an array or whatever container to hold pointers to the column headers of the list. This way, you can resize the list, while keeping it as square as possible. This also lets you access certain parts of the list faster, because you can traverse the array faster than the whole List.

eg. an Array of Header pointers. The List has 9 values right now.
Header 1 | Header 2 | Header 3

1 4 7
2 5 8
3 6 9

Header 1 has a pointer to "1", Header 2 has a pointer to "4", and Header 3 has a pointer to "7". You can hop to header 3 if you want to access value "9" in the List. Resize if necessary, adding more Headers as you see fit.

[MaxiDuRaritry]

Here's a thought. Try re-describing what you told us that you told him in some really profound-sounding allegory, and tell it to him like a fairy tale. Like, the three variables are the Three Little Pigs, and the pointers are Big Bad Wolves...or something. Get creative. If nothing else, you've sufficiently covered the "thinking outside the box" part of his requirements.

[gooddragon1]

There is a somewhat more coding inclined forum: http://www.giantitp.com/forums/forumdisplay.php?62-Mad-Science-and-Grumpy-Technology

However, it looks like you're getting a good amount of help here so meh.

[Stayingpower]

Come back here when you have your final grade/correction/whatever. I'm interested in knowing what happened!

[Coventry]

You could write some code that shows you intentionally smashing the values in one variable by assigning to another variable via a pointer, for example:


void changeone (char *target, char value) {
*target = value;
}


void demo_pointers () {
char buffer[80];
char* worker = memset (buffer, 0, sizeof(buffer));

strprintf(buffer, "This string will be changed"); // *worker points at 'T'

worker += 2; // now it points at 'i'
changeone (worker++, 'a'); // "Thas string...", *worker points at 's'
changeone (worker++, 't'); // "That string...", *worker points at ' '

printf ("New value: [%s]\n", buffer);
printf ("The same value: [%s]\n", buffer[0]); // Same thing

changeone (buffer, 'W'); // "What string..."
printf ("Final value: [%s]\n", buffer);
}

[SangoProduction]

There is a somewhat more coding inclined forum: http://www.giantitp.com/forums/forumdisplay.php?62-Mad-Science-and-Grumpy-Technology

However, it looks like you're getting a good amount of help here so meh.

Thanks for that.

[SangoProduction]

Someone asked me to report on what I get. Well, I have to say: thanks to everyone who replied, because I got 100%

[John Longarrow]

So what was your answer??? Kewl on the 100%!!! Glad we could help!

[Segev]

Yay! Congratulations!

I still am not sure what he was really looking for, but at least you managed to give it to him! (Do you know what it was? Or are you just glad he saw it in what you provided?)

[MaxiDuRaritry]

I still am not sure what he was really looking for, but at least you managed to give it to him!https://s-media-cache-ak0.pinimg.com/originals/f1/2d/01/f12d01f97d13207582d6962651aee4e5.jpg

[Segev]

https://s-media-cache-ak0.pinimg.com/originals/f1/2d/01/f12d01f97d13207582d6962651aee4e5.jpg

My Mormon shields must be hyper-active today, because even called out on it, I'm not sure what I said that can be interpreted "dirty." Do I want to know?

[ComaVision]

My Mormon shields must be hyper-active today, because even called out on it, I'm not sure what I said that can be interpreted "dirty." Do I want to know?

Sango gave it to his professor for good marks. :smallsmile:

[SangoProduction]

lol.

And yeah, this is the answer I gave for the first part:


/*
To start off with the obvious: we can see that the value of the pointers are addresses, and the dereferenced
values are what they are pointing to. It's obvious that the variables are the expected sizes. Pointers can point to pointers.

Pointers also remain the same size because they are storing addresses, and not the actual values.
Of course, in C, as you'd expect from any language that's meant to run on more than one machine, these
pointers are not of inherently fixed length, because different systems with different memory configurations
need different pointer sizes.

The declarations of the variables essentially create consecutive addresses, most of the time, so you could,
theoretically, though in an incredibly stupid and unsafe manner, reference the variable after the first one
by doing pointer arithmetic say on the [pointer] + [sizeof(pointer)].

The elaboration (and thus assignment of addresses) of the variables seems to be in the order that
they are declared in code. So, simply swapping variables around doesn't do much, aside from
swapping which one has the lower address value.

That is, unless you try to place a pointer to a variable, above the variable's declaration.
It doesn't know what you are wanting to reference, because the declaration
hasn't been elaborated before it is called, so the compiler just shuts down and gives up like a 7
year old who can't figure out a problem on the first try and didn't even read the whole problem first.
That's not to diss the C compiler, I just thought you might want something mildly funny to read after
grading a hundred of these.
*/

And for part 2 (which I was completely lost on, so I think I literally copy/pasted someone's answer from above, lol):


/*
An array is itself a pointer. When you add to (or do other math on) a pointer,
it operates in units the size of the pointed-to type. Hence why "array + i"
is the same as "&(array[i])", even though a pointer is more than one byte.

This might be to get you to think about the difference between a value of 0
and a value of 'not assigned'. Mistaking one for the other is a really common
mistake. People will try to sum a group of numbers but not assign an initial 0
to begin with, and the result is a completely erroneous. It's like the difference
between an empty box and a non-existent box - one can hold things, the other can not.

The act of creating a variable assigns memory space to it - creating the box -
and initializing sets the value inside the box other wise the initial value is
whatever was there before hand.

*/