Quote:Original post by Mantrid
also, you're sending a float, which means at one point in our program there are two floats, whereas it's "cheaper" to send a pointer to the float, since a pointer is smaller in size than a float, so you can do that
That's hardly ever true for primitives. If anything, passing a pointer to a float makes the code harder to understand and manage. But yes, for larger objects, passing a pointer (or often better, a reference) is often more efficient.
The concept behind pointers is indeed rather simple - they point to other objects - but their use can be quite tricky. For example, pointers can point to actual objects, but they can also just contain random addresses. Trying to dereference such pointers is asking for trouble.
Also, with regards to dynamic memory allocation, a pointer doesn't indicate whether it 'owns' the object it points at or not. What I mean is this: you can create a float on the stack (float a;) and make a pointer point to it (float* p = &a). That's all fine. But if you dynamically allocate a float and make a float pointer point to it (that float is now on the heap, or freestore): (float* p = new float;), then you're responsible for cleaning up that float (delete p;). In both cases you're using pointers, but in one case you need to clean up what you're pointing at, yet in the other case you definitely shouldn't call delete on it: what's on the stack will be removed automatically when it goes out of scope.
It's usually better to use higher level constructions (smart pointers, standard library containers) to reduce the risks and automate the tedious parts of memory management.
