Website Update #1 - Must delay learning about pointers by any means necessary!
I worked on the website!
Now is a good time to mention that web scripting was my first venture into ComSci, so this website will probably look quite different as I start new projects and learn new skills. I am not even hosting it at the moment (thanks Google)!
I wanted to start small this time and focus on learning C++ for now, however I felt it necessary to make some quality-of-life improvements (read:badly executed hacks) to the WYSIWYG blog experience.
- Replaced the static profile section with a nicer, more functional one:
- Removed link to Blogger profile I am not going to use.
- Clickable profile image that takes you home.
- Snazzy subscribe button that takes you to an antiquated (but very nicely functional) email signup form: Up to once a day, if I posted anything, you will receive a digest of all posts made that day.
- Contact form that was cluttering the page and looked bad on mobile replaced with a link to a dedicated page containing the exact same form but better behaving.
- Despite Blogger accepting "+" characters when setting Labels, it breaks when searching for labels containing "+". So I've replaced "C++" with "CPlusPlus" until I can be bothered working out how to fix that or replace the entire blog.
- zol.gg now redirects to zolarix.games for that full-fat experience, whether you like it or not.
Believe me, I didn't spend 5 hours dusting off my HTML5 "skills" just to avoid learning about pointers. Just as in the same way I am not making this post just to check if the subscription to the feed actually works.
That being said, I must admit that being told "pointers really are quite simple" followed by the suggestion to "do a little reading up on them as you go" and immediately finding the following page...
...is a little daunting. I am sure after a good night's rest that will look like some light reading.
One thing that made pointers click for me was learning just how calling functions works. Every parameter you pass in is a COPY of what was outside the call. If you have a big object like a mesh or a text file you want to pass into a function, you don't want to copy the entire thing each time it's passed into and out of a function. A pointer, meanwhile, is literally just a memory address to that big honkin chonk of data - on 32 bit machines it's 32 bits long, 64 bit machines its 64 bits long etc, and that's a lot faster to copy into functions than a whole 4mb image. This also means the function can then follow the pointer to the data, modify it in some way and bam, that data has been adjusted outside the function too, which can be handy. As an analogy (And this is actually how file systems work), the path "C:/something.png" is the pointer, while the actual image is your data.
ReplyDeleteActually, thinking about it more, the file system analogy works super well for this. When you use 'new' to create a new block of memory, that returns a pointer, like saying "I need an empty PNG file that has at least 4mb of space" and then 'new' says "Sure, here ya go, it's at 'C:/temp/12345.png'. Now, you need to remember that path so that you can then 'delete' the pointer later. If the pointer is lost, the pointer itself is cleaned up by the system, but the actual data/file/whatever sticks around, now just clogging up your memory with no way to tell the system "Yo, I want that deleted". That's why you need to 'delete' your pointer when you're done with them, as that basically says 'get rid of this pointer, but also the data this points to'. Memory restored.
There's a bit more to it like RAII and shared_pointer, but they're basically mechanisms so that you yourself don't have to do 'new' or 'delete', and that when the container object disappears (Say, a function ends and you don't return it), it deletes the memory for you, meaning memory leaks become a lot less likely. I think Unreal's pointers kind of have this built in too, so you shouldn't need to worry about using 'new' or 'delete' too much in an Unreal context unless you're using your own special non-Unreal classes and what have you.
Oh, and finally, there's 'references' on parameters. Say you have something like 'void DoAThing(SomeObject &obj)', note the & on the parameter. This basically means you can just pass an object in - not a pointer - and behind the scenes C++ secretly pulls the pointer out, passes it to the function, then un-pointerizes it, saving you the effort of dealing with pointers at all, while also meaning you don't copy a honking huge data block. Also means that changes that happen inside DoAThing affect the object outside of it, just like using a pointer.
Hopefully that helps a tad.
Thanks for that, yes it does help elucidate both the benefit and risks of using pointers. I was thinking of a situation where it might be faster NOT to use a pointer. For example booleans would probably be faster to create a copy of, I imagine. Theoretically they are 1 bit but I believe my instructor said even they are 1 byte in reality, although there are ways to cram multiple in to one byte allocation. Further, I imagine the benefit is greater on 64-bit machines as you said the address is 8 bytes long on those.
DeleteBut perhaps the reality differs to the theory here. There would still be a higher memory usage overall, but possibly less time spent reading? And you would lose the ability to modify the original value directly, so I imagine more time would be spent updating the two copies. I am going to read up on pointers today, but just in case that is not covered because my idea is silly, it would be interesting to hear back about it.
RE: References - You use an asterisk to de-reference the pointer otherwise you get a compile error if I remember correctly. We learned that earlier but without the explanation.
Your introductory statement was especially important, because the only real context we were given was:
AActor* SomeActor;
(*SomeActor).GetName();
SomeActor->GetName();
We were not told what AActor was, nor GetName(). Out of about 20 times reading it, I always thought the two ways of calling the function were different. However, after your explanation and rereading the grammar again, I think the instructor is in fact saying that it is just two ways of writing it, but you can "follow and access in one using SomeActor->GetName();" - meaning just use that one as it is slightly shorter to write (maybe Unreal-specific shorthand, or some library?). I hope so, because I could not find "->" anywhere on the Pointers tutorial I linked.
Bools are a byte wide in size because the CPU can't really do single bit checking, and the busses between components in a computer are at least 8 bytes anyway. To check if a bit is flipped, you first have to load an entire byte, then mask out all the bits you don't care about so that they're all 0, then check if the remaining value is not 0. If it's not, it's true, if it is, it's false. If your bool is a full byte, then you can just assume 0 = false, anything not 0 is true.
DeleteFor most of the 'primitive' types, bools, ints, floats, doubles and such, there is actually a greater cost if you use pointers rather than just copy the raw value, since they're all, at a maximum, 64 bits long. It's only when you get into classes do pointers really become important for saving time.
Also, assume you have two functions:
void DoSomethingWithAPointer(Thing *ptr) //The '*' here means you expect a pointer.
{
Thing obj = *ptr; //The '*' gets the value from the pointer.
obj.DoStuff();
}
void DoSomethingWithAReference(Thing &obj) //The '&' means that this acts as a reference.
{
obj.DoStuff();
}
These are the same in principle. And if you have the code:
Thing blah;
DoSomethingWithAPointer(&blah); //We use '&' to get a pointer to this value;
DoSomethingWithAReference(blah); //No need to do anything. The reference part of this function handles pointer stuff automagically.
Then when compiled, you essentially have the same code twice, but references avoid you even having to look at pointers.
Finally
AActor is just some 'thing' in the world in Unreal land. Anything you can see and that has behaviours inherits from AActor. In fact, any class that starts with a capital 'A' means it inherits from AActor. Classes starting with a capital 'U' inherit from UObject, which is pretty much the base object of any class in Unreal-land (AActor inherits from UObject, but since Actors are pretty important, it gets its own prefix) and any class starting with a capital 'F' means it's some sort of basic number object like FVector (The F stands for 'Float', but is a hold over from Unreal Engine 1 days). I think 'F' classes have spread out more to consider generic 'struct' types as well, especially in networking land.
The two ways you wrote 'GetName()' are exactly the same when compiled. (*SomeActor).GetName(); was the original mechanism (Since *SomeActor is the original C way of getting an object from a pointer), while -> is the newer C++ method that helps avoid your code become a mess of brackets. They are identical though.
Sweet! That answers all the questions I was left with from the lectures so far. I hesitate to call it intuition because it took a few days for me to work out, but my painfully slow understanding of what was vaguely mentioned was on the right track. Misunderstanding these fundamentals could be disastrously confusing later, considering how focused on implementation they are. Thanks!
Delete