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?
Related
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 2 months ago.
Improve this question
I am trying to code a relatively simple program to understand in which scenarios it would be more efficient and useful to use the heap.
I first read that you better store large objects on the heap.
So I created a std::vector on the heap and filled it with an insane amount of bytes, something like 18Gb. At some point, it threw a std::bad_alloc exception, then my OS (Linux mint) killed the process after the swap was full. But the result was the same with the stack, so I don't understand how it's better on the heap.
Maybe I lack creativity, but I cannot think of a design where I would absolutely need to use the heap, I can always pass a reference of my object on the stack and achieve the same memory usage efficiency. For every program I wrote, it was always more efficient to use the stack speed wise and was the same for memory usage.
So, in what scenario is it useful to use the heap regarding memory usage efficiency or speed?
You use the heap whenever you need more flexibility than the stack provides. If you need to allocate memory to return something from a function, then it can't be on the stack, because it would be freed when the function returned. And it can't be global, because you might call the same function more than once.
In C++, you might not always realize that you are using the heap, because classes like std::vector and std::string use the heap internally. You don't always have to write new yourself to use the heap.
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 11 months ago.
Improve this question
The stack class will maintain a dynamically allocated internal buffer of type unsigned long* which will be created in the constructor and is used to store the elements. This internal buffer must be wrapped in a smart pointer. The buffer is always increased or decreased in blocks and not with each element that comes in or goes out. The increment/decrement block size is passed as a parameter in the constructor.
If you want to learn how to use smart pointers then forget this code for a moment. Start a new small program that just makes sure you understand how they work.
Define a test class with just a string and an int in it. Make them public
Add a constructor so you can see when its created.
Add a Destructor so you can see when its deleted.
Create an instance using std::make_unique
Set things in the instance, write a function that accepts the unique_ptr as an argument and cout the fields in the test object
repeat with std::shared_ptr
Make sure you understand what is going on, dont just try to blindly nail stuff into your stack implementation. If you get stuck post a new question just on this.
The code above has so many other errors in it you will not get a clean set of answers to your specific 'smart pointers' question. Plus you wont be able to make it work reliably
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 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.
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.