Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a simple question that I have been unable to find an answer to.
If you want to know how to make/use/manipulate pointers, there are 1001 resources. But I'm wondering if this statement describes the point of pointers (pun intended):
Pointers are a portable, stack-based variable type that make object references easy.
Is this a fair statement? Any elaborations?
Pointer is very powerful C/C++ construct. You can directly access memory using pointer.
Now let me evaluate your statement as per my knowledge.
Pointers are a portable, stack-based variable type that make object
references easy.
Pointers are a portable - May not be, it can be dependent on bitness of your system. If you are using 16 bit pointer, then addressable memory would be 16 bit, same for 32 and 64 bit.
Stack-based variable - Can be on heap or stack, also can keep address of stack (in case of variable) or heap memory
make object references easy - May not be, you may need to use difficult de-referencing, like using * or arrow operator (->), . You also need to null check it.
From Wikipedia:
a pointer is a programming language object whose value refers directly
to (or "points to") another value stored elsewhere in the computer
memory using its address
Although Stack Pointers are a particular implementation utilising a pointer, the more general Pointer isn't anything to do with a stack.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I'm currently reading through Crash Course C++ and have a question regarding types.
If I declare and initialize both an int and a long long variable on a 64-bit machine running Linux to the decimal value 4, does the compiler recognize the wasted bytes and make changes to the underlying type? This is probably a no, as at some point that field may take on a value that would cause overflow with a smaller type (i.e. going from 8 bytes to 4).
I've read a little about object byte reordering during compilation in c++; that compilers can sometimes rearrange fields to minimize padding in memory. Just wondering if there is a similar optimization that happens for numeric types.
I do not think that the compiler will change the size of a variable. It might do so because of the as if rule, but if it can reliably do that, it means that the variable is used is a very simple context, for example assigned (or initialized) once from a constant and then only used in the same compilation unit and its address is not used (that last point if often said odr-usage for One Definition Rule).
But in that case, the compiler will simply optimize out the variable because it can directly use its value, so it will use no memory at all...
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
So I was looking at the source code of unreal engine and I came across this:
class USphereComponent* CollectionSphere;
There are using pointer for something that is going to be initialized and spawned once when the game begins and some objects will be overlapping it,I thought pointers are mainly used for more mid-high memory allocation purposes
So why are they using it now?
Keep in mind Im not really good at pointers so Im just trying learn and gather some information about it.
Whether to use pointers or not has almost nothing to do with "low" or "mid-high memory allocation purposes".
You use a pointer when you need a pointer, and often that's when the pointee (the thing being pointed to) will live for longer than an "automatic" object would in any of the program's existing, conveniently-accessible scopes.
Basically, *CollectionSphere will be a global (or something similar), but we can't construct it right away. The author has decided that they need fine control over the lifetime of the object. So, they have created a pointer to point to that object when the time comes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am using smart pointers on my current project, and it seems very cumbersome to have to type long lines of code when using them.
Because I wanted my code to be cleaner and easier to follow I started typedef-ing smart pointers like such:
typedef std::unique_ptr<System> SystemPtr;
So my question is, is it bad practice to typedef a smart pointer?
There is nothing wrong with it, but your choice of name is horrible. Someone reading that has no clue if that is a shared pointer, a unique pointer, an intrusive reference counting com pointer, or just a raw pointer to System.
If you really need brevity,
template<class T>using up=std::unique_ptr<T>;
is one more character at point of use than your plan up<System>, and makes it more clear that this is a unique pointer, and does not require a typedef per type. Plus it leads to puns in some cases.
As others have mentioned there is nothing syntactically incorrect about it. I'd just like to add that having to hunt for, or rely on something like Intellisense, to easily find a definition in larger projects can be unpleasant. Programmers rely on staying "in the zone" to do their best work. Even something as simple as taking 60 seconds to track down a typedef can ruin the groove.
For reasons like this I feel that in situations like yours and simply in general, it's a better practice not to apply typedefs liberally. You should be able to easily and quickly find a variable's type by traversing to the top of the associated scope.
And truth be told your type isn't that long (high level meta-types can be multiple lines long).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
As far as I have understood, if for example I want to create a c++ object with memory allocated on the stack,I have to use the keyword new,which therefore returns a pointer to the object which was created on the heap.
Is there any way to create an object on the heap,and access it directly,without the use of pointers ?
Is there any way to create an object on the heap,and access it directly,without the use of pointers ?
Let's start by saying that the C++ standard does not have a notion of heap and stack because C++ can be compiled on machines that does not have an heap. So, from now on I'm just gonna assume you mean to dynamically allocate memory.
You can avoid using new to dynamically allocate memory by using malloc (and similar C functions) but I wouldn't recommend this, especially because you would still use pointers.
The other alternative is to use an std::unique_ptr together with std::make_unique and generate a dynamically allocated resource and just bind a reference to it:
auto ptr = std::make_unique(...);
auto& ref = *ptr;
and then you'll be able to avoid using pointer semantic. But really: just use std::unique_ptr and be done with it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Context: I'm making a simple library. In it, I'm returning one of the classes I've created, which I could, a) declare on the stack and expect the user to copy to the heap if it needs to be on the heap, or, b) declare on the heap and expect the user to delete the object when they're done with it.
Which of these methods is a best practice, and if there isn't a clear winner, which should be used where? I'm thinking I'll create a .dll (.so, etc), but would the answer change if I were creating a different type of binary? What would happen if a user copied the headers and sources into their project and built the entire library each time they build their project. What would change?
Side note: I suppose a third option would be to allow a parameter to signify whether or not an object returned by a function is on the stack. This seems really convoluted, though, and I've never seen a library/API do that. A fourth option would be to allow a pointer to an already-existing object, which is then filled with new data. This way allows for the user to specify which sort of object they'd like, but it, again, seems rather convoluted.
Always prefer automatic memory management. Only use dynamic memory management if you need dynamic lifetime. If your function's purpose is to return a T, there is no need for dynamic lifetime here.
If you do need dynamic lifetime, then do not ever deal with raw pointers to objects that you need to delete- always use smart pointers.
Also,
expect the user to copy to the heap if it needs to be on the heap
You mean move to the heap, right?