There was a question asked about what a C++
wrapper class is, and I think he provided a good answer. His username: GManNickG from Stack Overflow provided the following code with his answer:
class int_ptr_wrapper
{
public:
int_ptr_wrapper(int value = 0) :
mInt(new int(value))
{}
// note! needs copy-constructor and copy-assignment operator!
~int_ptr_wrapper()
{
delete mInt;
}
private:
int* mInt;
};
That code prompted me with a question. I've heard from several different people that its considered bad practice to use the new and delete keywords.
Is there a certain situation in which I should use new or delete? Also If I wrote the code above like below, which is considered better practice?
class int_ptr_wrapper
{
public:
int_ptr_wrapper(int value = 0) :
m_int(&value) {}
private:
int* m_int;
};
There is (almost) always a better way than using new. There is absolutely always a better way than using delete.
Have a look at the documentation for std::shared_ptr<> and std::unique_ptr<>. Between them they cover every scenario you will ever need with regard to scoped memory management, automatic releasing of memory resources, automatic closing of files, automatic zeroing out of memory used for encryption... and so on. This is because both classes give you the opportunity to provide a custom deleter, so no matter how complex your memory deallocation needs, they're covered flawlessly and safely.
Writing a complete scoped memory manager class is harder than it at first seems. The c++ standard has done it for you. There is no good argument to reinvent that particular wheel.
Related
I have searched a lot on this. But may be I am not getting the phrasing right.
Consider,
Class A {};
Class B {
public:
A* getA();
void setA(A *aVarParam);
private:
A *aVar;
};
Now since aVar is a member variable of class B I want to ensure that it stays alive as long the corresponding object of class B exists.
So the options I see here are,
Make a deep copy of aVarParam and hold a pointer to it.
Use something like a Boost shared pointer.
Both of which seems either too much work or ugly syntax. Am I missing something here? Do all C++ programs use one of these 2 options?
More Explanation:
Ok many of you wanted to see an example of how I am using it. Actually I wanted a general purpose strategy kind of answer. Hence the original example. Here is the example I am trying to use:
#ifndef DBSCHEMA_H
#define DBSCHEMA_H
#include <string>
#include <vector>
#include "dbtable.h"
namespace models {
class DbSchema
{
public:
explicit DbSchema();
boost::shared_ptr<std::string> getSchemaName() const;
void setSchemaName(const boost::shared_ptr<std::string> schemaName);
std::vector<models::DbTable> getTableList() const;
void setTableList(const std::vector<models::DbTable> tableList);
private:
boost::shared_ptr<std::string> schemaName_;
std::vector<models::DbTable> tableList_;
};
}
#endif // DBSCHEMA_H
Here the class DbSchema is being used as a thin model which will direct the UI (A QT application). And there will be many Schema Builders which will actually communicate with different databases to fill the DBSchema objects which the UI will use.
I hope this clears up about what I am trying to achieve. I am not a C++ programmer. After programming Java, Objective-C, PHP and JavaScript for years, I am trying to satisfy an itch to write a "real C++" application.
For the sake of the question, I'll assume that you have a genuine reason for storing a pointer, rather than the object itself. However, if your real code is similar to the example, then there is no good reason for storing a pointer to a string.
The third option is to take ownership of the object. Before C++11, this was tricky to achieve without the danger of leaks or dangling pointers, but these days we have move semantics and unique_ptr, a smart pointer to handle single transferable ownership semantics.
#include <memory>
class B {
public:
void setA(std::unique_ptr<A> aVarParam) {
aVar = std::move(aVarParam);
}
private:
std::unique_ptr<A> aVar;
};
std::unique_ptr<A> myA(new A);
assert(myA); // we own the object
b.setA(std::move(myA)); // transfer ownership
assert(!myA); // we no longer own it
If you want B to own the object A then it is not clear
to a user who owns the object after a function like
A* getA();
who should delete the object?
even though there is additional syntax using a shared_ptr
would make it clear to the user of your class who owns the
object.
std::shared_ptr<A> getA();
If you otoh want to pass the object along to somebody else
use std::unique_ptr instead.
there is not much overhead at all adding this and it makes
your code easier to read.
I think the first question you need to answer is a matter of conception.
Who's supposed to own the resource, and who's using it.
If these two are the same, a unique_ptr seems appropriate, if not, the shared_ptr/weak_ptr could be appropriate, but again, without knowing more about your whole problem, seems hard to give a definite answer.
For example, if your class is merely using the resource without owning it, the resource should be stored with a shared_ptr somewhere, and your class should only hold a weak_ptr to it, and lock it only when it wants to use it, and be prepared to handle the case where the resource has been deleted (if that should happen).
edit: after seeing your edit
Seeing your code like that, I don't see why you would need a pointer, just use a classic std::string and all will be fine... (unless I'm missing something, but that raises the question: why a pointer?)
i was wondering if it is possible to force an object to be created on the heap by creating a private/protected desctuctor and by using shared_ptrs to ensure an automatic resource managment (the RAII features of a shared_ptr) at the same time.
Can that be done in a different way maybe?
The reason i ask that, is because from what i heard(didnt look at that yet) at the STL there are no virtual descructors,so there is no way to ensure safe destruction other than...shared_ptr?
And if so,there is no way to force the object to the heap since shared_ptr is trying to access the destuctor.
Anyway to bypass these limitations?
C++ is a language that puts the correctness of the code in the hand of the programmer. Trying to alter that via some convoluted methods typically leads to code that is hard to use or that doesn't work very well. Forcing the hand of the programmer so that (s)he has to create an object on the heap even if that's not "right" for that particular situation is just bad. Let the programmer shoot him-/herself in the foot if he wants to.
In larger projects, code should be reviewed by peers (preferably at least sometimes by more senior staff) for correctness and that it follows the coding guidelines of the project.
I'm not entirely sure how "virtual destructors" relate to "safe destruction" and "shared pointers" - these are three different concepts that are not very closely related - virtual destructors are needed when a class is used as a base-class to derive a new class. STL objects are not meant to be derived from [as a rule, you use templates OR inheritance, although they CAN be combined, it gets very complicated very quickly when you do], so there is no need to use virtual destructors in STL.
If you have a class that is a baseclass, and the storage is done based on pointers or references to the baseclass, then you MUST have virtual destructors - or don't use inheritance.
"safe destruction", I take it, means "no memory leaks" [rather than "correct destruction", which can of course also be a problem - and cause problems with memory leaks]. For a large number of situations, this means "don't use pointers to the object in the first place". I see a lot of examples here on SO where the programmer is calling new for absolutely no reason. vector<X>* v = new vector<X>; is definitely a "bad smell" (Just like fish or meat, something is wrong with the code if it smells bad). And if you are calling new, then using shared pointer, unique pointer or some other "wrapping" is a good idea. But you shouldn't force that concept - there are occasionally good reasons NOT to do that.
"shared pointer" is a concept to "automatically destroy the object when it is no longer in use", which is a useful technique to avoid memory leaks.
Now that I have told you NOT to do this, here's one way to achieve it:
class X
{
private:
int x;
X() : x(42) {};
public:
static shared_ptr<X> makeX() { return make_shared<X>(); }
};
Since the constructor is private, the "user" of the class can't call "new" or create an object of this kind. [You probably also want to put the copy constructor and assignment operator in private or use delete to prevent them from being used].
However, I still think this is a bad idea in the first place.
The answer by Mats is indeed wrong. The make_shared needs a public constructor.
However, the following is valid:
class X
{
private:
int x;
X() : x( 42 ) {};
public:
static std::shared_ptr<X> makeX()
{
return std::shared_ptr<X>( new X() );
}
};
I don't like to use the new keyword, but in this case, it is the only way.
I enjoy using the operators new and delete in C++ a lot but often have a problem calling delete later on in the program's code.
For example, in the following code:
class Foo {
public:
string *ace;
Foo();
~Foo();
};
Foo::Foo() {
ace = new string;
}
Foo::~Foo() {
delete ace;
}
void UI::ButtonPressed() { //Happens when an event is triggered
Foo *foo = new Foo;
ui->label = ace; //Set some text on the GUI
delete foo; //Calls the destructor, deleting "ace" and removing it from the GUI window
}
I can declare a new string but when I delete it, it removes the value from the GUI form because that string has now been deleted.
Is there a way for me to delete this allocated string somehow later on?
I don't want to declare it as a global variable and then delete it on the last line of the program's source code. I could just never call delete but from what I have been taught that's bad and results in memory leaks.
You should read about the RAII pattern. It is one of the most important concepts to know for a C++ programmer.
The basic idea is that the lifetime of a resource (a new'ed object, an HTTP connection, etc.) is tied to the lifetime of an object. This is necessary in order to write exception safe code.
In your case, the UI widget would make a copy of the object and free it in its own destructor. The calling code could then free its copy right away (in another destructor).
If you are using std::string for both ace and ui->label then you don't have to worry about the memory for foo->ace being deleted once the foo object goes out of scope.
A copy of the Right-Hand argument is made available to ui->label on an = (assignment operation). You can read more about it on the C++ std::string reference page for string::operator=.
Also, such problems can be avoided in full by using smart pointers, such as the ones provided by the boost library. Read this great post on stackoverflow on this subject to get a better understanding.
Well, there's a lot to say of your code. Some things have already been said, e.g. that you should make string a normal member so the allocation/deallcoation issue goes away completely (that's a general rule for C++ programs: If you don't absolutely have to use dynamic allocation, then don't, period). Also, using an appropriate smart pointer would do the memory management for you (also a general rule in C++: Don't manage the dynamic allocations yourself unless you really have to).
However let's pretend that you have to use dynamic allocation, and you have to use raw pointers and direct new and delete here. Then another important rule comes in (which actually isn't a C++ specific rule, but a general OO rule): Don't make the member public. Make it a private member, and offer a public member function for setting it. That public member function then can properly delete the old object before assigning the pointer to the new one. Note that as soon as you assigned the pointer, unless you've stored the old value elsewhere, the old value is lost forever, and if the object has not been deleted up to then, you can't delete it later.
You also want to consider whether it is really a good idea to take ownership of an object passed to you by pointer (and assigning to a pointer member which has a delete in the destructor is a ― not very obvious ― way to pass ownership). This complicates the object lifetime management because you have to remember whether you passed a certain object to an ownership-claiming object (this is not an issue if you have a strict policy of always passing to ownership-claiming objects, though). As usual, smart pointers may help here; however you may consider whether it is a better option to make a copy of the passed object (for std::string it definitely is, but then, here it's better to have a direct member anyway, as mentioned above).
So here's a full list of rules, where earlier rules take precedence to later unless there's a good reason not to use it:
Don't use dynamical allocation.
Manage your dynamical allocation with smart pointers.
Use new only in constructors and delete only in the corresponding destructor.
Always have the new and delete for a specific pointer in member functions of the same class. (Actually the previous rule is a special case of this one, but a special case which should be preferred to the general one.)
Here's a more idiomatic C++ program:
class Foo {
public:
std::string ace;
Foo() : ace() {
// nothing to do here. ace knows how to create itself…
}
// and copy itself…
Foo(const Foo& other) : ace(other.ace) {}
// and clean up after itself…
~Foo() {
}
// and copy/assign itself…
Foo& operator=(const Foo& other) {
this->ace = other.ace;
return *this;
}
};
void UI::ButtonPressed() {
// `new` is not needed here, either!
Foo foo;
ui->label = foo.ace; //Set some text on the GUI
// `delete` is not needed here
}
If you really need to call new, always use an appropriate smart pointer -- Writing delete is banished from modern C++ ;)
class A
{
public:
A(){}
~A(){}
void DoSomething(int x){}
};
void func(int i)
{
A *pa = new A();
pa->DoSomething(i);
delete pa;
}
Do you guys see any problem with this code?
I can only see following two:
func is only operating on object of class A and should be made member of A.
object of class A should be created on the stack instead of heap.
Any other ideas?
object of class A should be created on the stack instead of heap.
Yes, pa should be created as an automatic variable (on the stack) instead of dynamically (on the heap).
However, it's also wrong as written because it isn't exception-safe. If pa->DoSomething(i) throws an exception, you will leak the object pointed to by pa.
The correct way to manage resource lifetimes is to use Scope-Bound Resource Management (SBRM; also called Resource Acquisition Is Initialization). The RAII way to manage a dynamically allocated object is to use a smart pointer:
void func(int i)
{
std::auto_ptr<A> pa(new A());
pa->DoSomething(i);
}
Manual resource management is brittle and dangerous because it's easy to get wrong. In this trivial example, it's easy to see that pa->DoSomething(i) does not throw an exception because it doesn't do anything at all. But in almost every real program, it's not that easy.
Manual resource management quickly becomes very difficult as a program grows in size and complexity. Automatic resource management using Scope-Bound Resource Management scales very well.
func is only operating on object of class A and should be made member of A.
This is not correct. You should only implement a function as a member function if it requires access to the internal state of the object. This means that you should prefer to implement functions as non-member functions wherever possible.
The more member functions you have, the more work it takes to thoroughly test a class because there are more ways that the internal state of the class can be modified.
Herb Sutter explains this principle by breaking down the std::string class in his Guru of the Week article "Monoliths Unstrung."
Any exception happens on func() while executing A::DoSomething() cause a memory leak. Use a smart pointer (e.g. std::auto_ptr)
Also, a class that needs a copy constructor, an assignment operator or a destructor typically needs all three (I know, this one is empty - just saying).
Is this real code? Then the stateless class is completely superfluous, and void DoSomething(int x) should be a normal function. If not, post the real code, otherwise it's hard to give further advice.
I have another theory question , as the title suggested it's to evaluate a build of code. Basically I'm considering using this template everywhere.
I am using VC++ VS2008 (all included)
Stapel.h
class Stapel
{
public:
//local vars
int x;
private:
public:
Stapel();
Stapel(int value);
~Stapel(){}
//getters setters
void set_x(int value)
{
x = value;
}
int get_x(int value)
{
x = value;
}
void CleanUp();
private:
};
Stapel.cpp
#include "Stapel.h"
Stapel::Stapel()
{
}
Stapel::Stapel(int value)
{
set_x(value);
}
void Stapel::CleanUp()
{
//CleanUpCalls
}
The focal point here is the cleanup method, basically I want to put that method in all my files everywhere , and simply let it do my delete calls when needed to make sure it's all in one place and I can prevent delete's from flying around which , as a rookie, even I know is probably not something you want to mess around with nor have a sloppy heap.
What about this build?
Good bad ? why ?
And what about using destructors for such tasks?
Boost provides several utilities for RAII-style heap-managment:
Smart pointer (there are several implementations here for different scenarios)
Pointer Containers
Drawbacks of your proposal:
In your implementation, you still have to remember to place a delete in the CleanUp-method for every heap-allocation you do. Tracking these allocations can be very difficult if your program has any kind of non-linear control flow (some allocations might only happen under certain circumstances). By binding the deallocation of resources (in this case memory) to the lifetime of objects on the stack, you do not have to worry as much. You will still have to consider things like circular references.
RAII helps you write exception-safe code.
In my experience, RAII leads to more structured code. Objects that are only needed inside a certain loop or branch will not be initialized somewhere else, but right inside the block where they are needed. This makes code easier to read and to maintain.
Edit: A good way to start implementing that is to get Boost. Then search your code for raw pointers, and try to replace every pointer by
A reference
A smart-pointer
A pointer container, if it is a container that owns pointers
If this is done, your code should not contain any deletes anymore. If you use make_shared, you can even eliminate all news. If you run into any problems that you cannot solve by yourself, check out stackoverflow.com ... oh wait, you know that one already ;)
Use smart pointers and RAII instead. That will not center all the deletes in one place, but rather remove them from your code. If you need to perform any cleanup yourself, that is what destructors are for, use them as that is the convention in C++.