For reference, static memory is memory that is memory that is assigned, managed, and freed for you (an example is
char const* str = "Hello World!";).
C/C++ will clean that string up for you.
Dynamically allocated memory is memory you request, manage, and must clean yourself (an example isType_t* array = malloc( sizeof(Type_t)*arrLength );).
I'm messing around with C strings in C++, even testing ideas for my own String type. - And I was creating a String +(char c) method, when I thought of something: "How can I return a String object whose str property is statically allocated, and not dynamically allocated?".
Since the only method of adding a character to an immutable string I can think of involves using malloc( (oldStrLen+1)*sizeof(char) ), which is dynamically allocated.
So, is there a way I can copy the contents of a pointer to a new statically allocated pointer, or convert dynamically allocated memory to statically allocated memory in C/C++?
Top comments (7)
We don't use
malloc()in C++.Since C++11, we avoid
newas much as possible. Instead, we use smart pointers.Except for educational purposes, you should use
std::string.Since we don't know that your custom
Stringclass looks like, it's almost impossible to answer your question. Nevertheless, the answer is probably "no" ;)Well, the best way to describe it is a C++ programmer's poor-man's Java
String.But, does this help answer my question? code.sololearn.com/cYg3qaNUP6t0
There is so much to say about this code... Some remarks:
1- Why mixing char* and unsigned char*?
2- Why usig unsigned char? oO
3- this-> is not needed, most of the time
4- I see getlen(std::string) --> why don't you simply use std::string? Is this code only for educational purpose?
5- getlen(unsigned char const*) : aren't you missing ++i in the for loop?
5- TOO MUCH CASTS /!\
6- Don't use C style casts. Use C++ cast operators
7- unsigned char const* const str = nullptr; --> why is this pointer const?! You want to set it in the constructor Oo
Note: What's with the two random "Oo"s?
1- Because I prefer
unsigned charwhen working with characters, andunsigned charis compatible withchar, but I don't know if it's compatible withsigned char. Though, I guess I should just usechar, huh?2- For the reason stated above (I love unsigned characters).
3- I know, but since I work in the context of Java, and JavaScript, I prefer the
this., because I've gotten attached to using it for properties.4- I just wanted to make my own
Stringtype for fun, to add my own custom methods, without having to dig into the internals of the traditionstd::string. - So, technically, I guess you could say so.5- Yes. But it should be an
i++and not++i. (Since won't the latter incrementibefore the loop begins?)6- This was a deliberate decision. I realize they can cause errors, and allow too much freedom. - But, this decision is also in part to not understanding how C++'s typecasts work, and why they wouldn't just replace C's typecasts (if they were so bad). (I know, compatibility reasons, blah blah blah, but they still could have made it work, adding their own casts with
(Type) value.)7- I do. And I still can in the member-initializer-list, since those apparently happen before the instantiation of the class (or right as it happens).
NOTE: this is juste a smiley: Oo => en.wikipedia.org/wiki/List_of_emot... => Surprised
1/2- Not everything is a matter a preference. See stackoverflow.com/questions/75191/...
3- Usually, we don't add
this->when its not needed. It improves codes' readability.*4- OK
5- Both occur at the end of each iteration. In C++, we generally use
++iin for loops. See betterprogramming.pub/stop-using-i...6- If you don't understand the C++ cast operators, then you don't understand what you code do. You should really use them. See stackoverflow.com/a/1609185/12342718
7- My bad: it works in the initialization list. Note that you have a cast that takes away the
const.AFIK, you cannot convert dynamic memory in static or stack memory since both need to be known at compile time. You can move it into static memory but you would still need a buffer with a constant size to be prepared at compile time. Which means it won't be a "new" static memory
Static memory is not automatically cleaned up for you. It is globally shared memory and you will still need to clean it up, unless you mean at app exit, at which point more or less everything is cleaned up.
char const* my string = "";
Is not static, use std::string instead, seriously.
Also you can just make a std::string instance and assign the value of a pointer dereferenced string to it. Complex types require you copy your data to a new variable / memory block yourself. Memory management involving anything pointer that's not a smart pointer, is completely your responsibility.
For your moving memory behind a pointer question, probably std::move documentation will give you some insights.
By statically allocated pointer you mean a smart pointer, I assume? Pointers are just that, references to a block of memory. How you deal with that memory is your responsibility.
I would go as far as recommending to stay away from raw pointers and only use std:: types like smart pointers, they deal with a lot of difficult things like memory management and copy/move/manipulation of data in safe ways.