I'm porting an old C++ program to modern C++. The legacy program uses new and delete for dynamic memory allocation. I replaced new with std::unique_ptr, but I'm getting compilation error when I try to reset the unique_ptr.
Here is the striped down version of the program. My aim is to get rid of all the naked new.
#include <memory>
enum class Types {
ONE,
TWO,
};
// based on type get buffer length
int get_buffer_len(Types type) {
if(type == Types::ONE) return 10;
else if(type == Types::TWO) return 20;
else return 0;
}
int main() {
Types type = Types::ONE;
std::unique_ptr<char[]> msg{};
auto len = get_buffer_len(type);
if(len > 0) {
msg.reset(std::make_unique<char[]>(len));
}
// based on type get the actual message
if(type == Types::ONE) {
get_message(msg.get());
}
}
I get the following compilation error:
error: no matching function for call to 'std::unique_ptr<char []>::reset(std::__detail::__unique_ptr_array_t<char []>)'
| msg.reset(std::make_unique<char[]>(len));
| ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you look at the reset function, it takes a ptr to memory, not another unique ptr:
// members of the specialization unique_ptr<T[]>
template< class U >
void reset( U ptr ) noexcept;
This function is designed to allow you to reset a unique pointer and simultaneously capture memory that you intend to manage with said unique_ptr. What you are looking to do is assign an r-value unique_ptr to ann existing unique_ptr (msg), for which c++ also has an answer:
unique_ptr& operator=( unique_ptr&& r ) noexcept;
Move assignment operator. Transfers ownership from r to *this as if by calling reset(r.release()) followed by an assignment of get_deleter() from std::forward(r.get_deleter()).
So you can instead just do:
msg = std::make_unique<char[]>(len);
Related
if we have a code like this :
void g(int *n){
int m=n[1];
n= null ;
}
void main(){
int ∗ p = (int∗)malloc(10 ∗ sizeof (int));
int * q= p;
g(p);
}
so we know if we overload malloc, calloc , realloc ,new ,free and delete functions we can track first pointer that create or delete with this functions(p pointer in above example ) but how can i find and track other pointers and functions that using this allocated memory ? ( q pointer and g function in above example ) .should i overload Assignment statement and function call ? if yes how ? in other words i want to know live objects and last used time and location of an allocated memory too .
i want to implement an custom memory leak detection tools so i need to find all objects and pointer that using an allocated memory before report it that's leak or not .
What you're talking about is called reference counting. Searching stackoverflow for this topic gives you these results:
What is a smart pointer and when should I use one?
How does a reference-counting smart pointer's reference counting work?
what exactly reference counting in c++ means?,
The standard template library already has a std::shared_ptr which does that.
We need to keep track of the lifecycle of the resource, this is possible by controlling the creation, the copying and the deletion. If you do it without using a class, you'll end up with some functions, a state variable and a global variable. This is not very effective in keeping the concept of the shared resource in the focus of the user's mind. One tends to forget that one is using a shared resource because one sees a naked pointer and tends to use it like one, which would disregard the provided shared-pointer functionality.
If you were to encapsulate the functionality in a class, you should want to implement the concept for all types i.e. you should want to use templates. one way would be this:
#include <vector>
#include <stdexcept>
#include <cstdlib>
#ifndef SHARED_PTR_H
#define SHARED_PTR_H
template<class Tres_t>
class shared_pointer
{
// members
Tres_t* data_;
static std::vector<std::size_t> ref_counts_;
std::size_t ref_index_ = {};
public:
// lifecycle
shared_pointer() = delete;
shared_pointer(const std::size_t& size)
: data_{nullptr}
{
data_ = static_cast<Tres_t*>(std::malloc(size * sizeof(Tres_t)));
ref_counts_.push_back(1);
ref_index_ = ref_counts_.size() - 1;
}
shared_pointer(const shared_pointer& rhs)
: data_{rhs.data_}, ref_index_{rhs.ref_index_}
{
if (ref_index_ >= ref_counts_.size())
{
throw std::runtime_error("shared_pointer_ctor_index_error");
}
++ref_counts_[ref_index_];
}
shared_pointer(shared_pointer&& rhs)
: data_{rhs.data_}, ref_index_{rhs.ref_index_} {}
shared_pointer& operator=(const shared_pointer& rhs)
{
data_ = rhs.data_;
ref_index_ = rhs.ref_index_;
if (ref_index_ >= ref_counts_.size())
{
throw std::runtime_error("shared_pointer_ctor_index_error");
}
++ref_counts_[ref_index_];
}
shared_pointer& operator=(shared_pointer&& rhs)
{
data_ = rhs.data_;
ref_index_ = rhs.ref_index_;
}
~shared_pointer()
{
if (ref_counts_[ref_index_] == 0)
{
std::logic_error("shared_point_dtor_reference_counting_error");
}
--ref_counts_[ref_index_];
if (ref_counts_[ref_index_] == 0)
{
std::free(data_);
}
}
// main functionality
Tres_t* data()
{
return data_;
}
const Tres_t* data() const
{
return data_;
}
};
template<class Tres_t>
std::vector<std::size_t> shared_pointer<Tres_t>::ref_counts_ = {};
#endif
I've tested this code only rudimentarily so I'll leave it to you to test and improve it.
Hi guys I just watch a tutorial about MOVE CONSTRUCTOR (better than deep copy ) and I don't really understand the concepts I'm a beginner, not a pro so I need your help to understand let's start:
first here is the code from the tutorial :
#include <iostream>
#include <vector>
using namespace std;
class Move {
private:
int *data;
public:
void set_data_value(int d) { *data = d; }
int get_data_value() { return *data; }
// Constructor
Move(int d);
// Copy Constructor
Move(const Move &source);
// Move Constructor
Move(Move &&source) noexcept;
// Destructor
~Move();
};
Move::Move(int d) {
data = new int;
*data = d;
cout << "Constructor for: " << d << endl;
}
// Copy ctor
Move::Move(const Move &source)
: Move {*source.data} {
cout << "Copy constructor - deep copy for: " << *data << endl;
}
//Move ctor
> **Move::Move(Move &&source) noexcept
> : data {source.data} {
> source.data = nullptr;
> cout << "Move constructor - moving resource: " << *data << endl;
> }**
OK HERE IS THE THING the instructor says "we steal the data and null the pointer so my question waht happend when we assighn our pointer to nullptre is it equal to zero or cant we reach it any more or what ???"
Move::~Move() {
if (data != nullptr) {
cout << "Destructor freeing data for: " << *data << endl;
} else {
cout << "Destructor freeing data for nullptr" << endl;
}
delete data;
}
int main() {
vector<Move> vec;
vec.push_back(Move{10});
vec.push_back(Move{20});
vec.push_back(Move{30});
vec.push_back(Move{40});
vec.push_back(Move{50});
vec.push_back(Move{60});
vec.push_back(Move{70});
vec.push_back(Move{80});
return 0;
}
NULL is more or less a left-over from simpler days, when C++ was much closer to its ancestor C. Since C++ was first standardized (and even before) it was recommended to use 0 for null-pointers. C++11 added nullptr which is a drop-in replacement for both 0 and NULL.
However the type of nullptr is std::nullptr_t which can be useful for templates and function arguments (for overloading).
A really nice book I was recommended recently: Effective Modern C++ by Scott Meyers.
Neither 0 nor NULL has a pointer type.
Consider below code:
void f(int); // three overloads of f
void f(bool);
void f(void*);
f(0); // calls f(int), not f(void*)
f(NULL); // might not compile, but typically calls
// f(int). Never calls f(void*)
nullptr’s actual type is std::nullptr_t
f(nullptr); // calls f(void*) overload`
It can also improve code clarity, especially when auto variables are involved.
For example, suppose you encounter this in a code base:
auto result = findRecord( /* arguments */ );
if (result == 0) {}
If you don’t happen to know (or can’t easily find out) what findRecord returns, it may not be clear whether result is a pointer type or an integral type. After all, 0 (what result is tested against) could go either way. If you see the following, on the other hand,
auto result = findRecord( /* arguments */ );
if (result == nullptr) {}
there’s no ambiguity: result must be a pointer type.
nullptr shines especially brightly when templates enter the picture. Suppose you have some functions that should be called only when the appropriate mutex has been locked. Each function takes a different kind of pointer:
int f1(std::shared_ptr<Widget> spw); // call these only when
double f2(std::unique_ptr<Widget> upw); // the appropriate
bool f3(Widget* pw); // mutex is locked
Calling code that wants to pass null pointers could look like this:
std::mutex f1m, f2m, f3m; // mutexes for f1, f2, and f3
using MuxGuard = std::lock_guard<std::mutex>;
{
MuxGuard g(f1m); // lock mutex for f1
auto result = f1(0); // pass 0 as null ptr to f1
} // unlock mutex
{
MuxGuard g(f2m); // lock mutex for f2
auto result = f2(NULL); // pass NULL as null ptr to f2
} // unlock mutex
{
MuxGuard g(f3m); // lock mutex for f3
auto result = f3(nullptr); // pass nullptr as null ptr to f3
} // unlock mutex
The failure to use nullptr in the first two calls in this code is sad, but the code works, and that counts for something. However, the repeated pattern in the calling code—lock mutex, call function, unlock mutex—is more than sad. It’s disturbing. This kind of source code duplication is one of the things that templates are designed to avoid, so let’s templatize the pattern:
template<typename FuncType, typename MuxType, typename PtrType>
auto lockAndCall(FuncType func, MuxType& mutex, PtrType ptr) -> decltype(func(ptr))
{
MuxGuard g(mutex);
return func(ptr);
}
If the return type of this function auto … -> decltype(func(ptr) has you scratching your head, you’ll see that in C++14, the return type could be reduced to a simple decltype(auto):
template<typename FuncType, typename MuxType, typename PtrType>
decltype(auto) lockAndCall(FuncType func, MuxType& mutex, PtrType ptr)
{
MuxGuard g(mutex);
return func(ptr);
}
Given the lockAndCall template (either version), callers can write code like this:
auto result1 = lockAndCall(f1, f1m, 0); // error!
auto result2 = lockAndCall(f2, f2m, NULL); // error!
auto result3 = lockAndCall(f3, f3m, nullptr); // fine
The fact that template type deduction deduces the “wrong” types for 0 and NULL (i.e., their true types, rather than their fallback meaning as a representation for a null pointer) is the most compelling reason to use nullptr instead of 0 or NULL when you want to refer to a null pointer. With nullptr, templates pose no special challenge. Combined with the fact that nullptr doesn’t suffer from the overload resolution surprises that 0 and NULL are susceptible to, the case is ironclad. When you want to refer to a null pointer, use nullptr, not 0 or NULL.
So I've solved this problem, but I need your opinion if what I did is best practice.
A simple class holds a vector of unique_ptrs to order objects. I will explain the member variable null_unique below.
class order_collection {
typedef std::unique_ptr<order> ord_ptr;
typedef std::vector<ord_ptr> ord_ptr_vec;
ord_ptr_vec orders;
ord_ptr null_unique;
public:
...
const ord_ptr & find_order(std::string);
....
So I need the users of this class to get access to the order unique_ptr if found. However I'm not going to move the object out of the vector so I'm returning the unique_ptr as const ref. My implementation of the find_order method:
const order_collection::ord_ptr & order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return null_unique; // can't return nullptr here
return *it;
}
Since I'm returning by reference I can't return a nullptr. If I try to do so, I get warning : returning reference to a temporary. And if nothing is found the program crashes. So I added a unique_ptr<order> member variable called null_unique and I return it when find doesn't find an order. This solves the problem and warning is gone and doesn't crash when no order is found.
However I'm doubting my solution as it make my class ugly. Is this the best practice for handling this situation?
You should only return and accept smart pointers when you care about their ownership semantics. If you only care about what they're pointing to, you should instead return a reference or a raw pointer.
Since you're returning a dummy null_unique, it is clear that the caller of the method doesn't care about the ownership semantics. You can also have a null state: you should therefore return a raw pointer:
order* order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return nullptr;
return it->get();
}
It doesn't really make sense to return a unique_ptr here, reference or otherwise. A unique_ptr implies ownership over the object, and those aren't really the semantics being conveyed by this code.
As suggested in the comments, simply returning a raw pointer is fine here, provided that your Project Design explicitly prohibits you or anyone on your team from calling delete or delete[] outside the context of the destructor of a Resource-owning object.
Alternatively, if you either have access to Boost or C++17, a std::optional<std::reference_wrapper<order>> might be the ideal solution.
std::optional<std::reference_wrapper<order>> order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return {}; //empty optional object
return **it; //will implicitly convert to the correct object type.
}
/*...*/
void func() {
auto opt = collection.find_order("blah blah blah");
if(!opt) return;
order & ord = opt->get();
/*Do whatever*/
}
(EDIT: In testing on the most recent version of MSVC 2017, it looks like std::reference_wrapper<T> will happily do an implicit conversion to T& if you tell it to. So replacing opt->get() with *opt should work exactly the same.)
As long as I'm here, I might point out that a std::vector<std::unique_ptr<type>> object has a very "Code Smell" sense to it. std::vector<type> implies ownership of the object as is, so unless you have a good reason to prefer this (maybe the objects are large, unmovable/uncopyable, and you need to insert and remove entries frequently? Maybe this is a polymorphic type?), you're probably better off reducing this to a simple std::vector.
EDIT:
The boost version is subtly different, because boost::optional has no restrictions against "optional references", which are specifically forbidden by the C++ Standard Library's version of std::optional. The boost version is actually going to be slightly simpler:
//return type changes, nothing else changes
boost::optional<order&> order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return {}; //empty optional object
return **it; //will implicitly convert to the correct object type.
}
/*...*/
//Instead of calling opt->get(), we use *opt instead.
void func() {
auto opt = collection.find_order("blah blah blah");
if(!opt) return;
order & ord = *opt;
/*Do whatever*/
}
The following test code demonstrates an issue that I am having in a much larger application. In the application I have a service that "provides" several servers that are all derived from one base class. I then use createInstance to get "access" to a specific server based on a server type ('n' used below). dynamic_cast is then used to cast as the appropriate server. This all works fine.
The problem is when I try to use the deleteInstance to go back to the service and delete it, cleaning up any internal server related data. I cannot seem to find a good passing mechanism or if it is even valid way of achieving what I am doing.
#include <iostream>
#include <string>
class MM
{
public:
virtual ~MM() {}
virtual void start() = 0;
};
class M1 : public MM
{
public:
void start()
{
std::cout << "M1 start" << std::endl;
}
};
class M2 : public MM
{
public:
void start()
{
std::cout << "M2 start" << std::endl;
}
void start( const std::string strName )
{
std::cout << "M2 start - " << strName << std::endl;
}
};
MM * createInstance( int n )
{
if( 2 == n )
{
return new M2;
}
else
{
return new M1;
}
}
void deleteInstance( MM * & pInstance )
{
delete pInstance;
pInstance = NULL;
}
void deleteInstance2( MM ** ppInstance )
{
delete *ppInstance;
*ppInstance = NULL;
}
int main( int argc, char *argv[] )
{
M1 *pM1 = dynamic_cast<M1 *>( createInstance( 1 ) );
M2 *pM2 = dynamic_cast<M2 *>( createInstance( 2 ) );
pM1->start();
pM2->start();
pM2->start( "test" );
deleteInstance( pM1 );
deleteInstance( pM2 );
//deleteInstance2( &pM1 );
//deleteInstance2( &pM2 );
return 0;
}
To complete the info, the error that I am receiving for deleteInstance implementation:
68:25: error: invalid initialization of reference of type ‘MM*&’ from expression of type ‘M1*’
46:6: error: in passing argument 1 of ‘void deleteInstance(MM*&)’
69:25: error: invalid initialization of reference of type ‘MM*&’ from expression of type ‘M2*’
46:6: error: in passing argument 1 of ‘void deleteInstance(MM*&)’
and for deleteInstance2:
70:27: error: invalid conversion from ‘M1**’ to ‘MM**’
70:27: error: initializing argument 1 of ‘void deleteInstance2(MM**)’
71:27: error: invalid conversion from ‘M2**’ to ‘MM**’
71:27: error: initializing argument 1 of ‘void deleteInstance2(MM**)’
The problem is that binding a pointer to the derived type with a reference to a pointer to the base type would break the type system. Consider this motivating example:
void resetPtr( base*& b ) {
static base instance;
b = &instance;
}
int main() {
derived *d;
resetPtr( d ); // Now d points to a base, not a derived object!!!!
}
While you can work around this as some other answer points out (for example through the use of templates that will infer the appropriate type and so on), I would recommend that you redesign and pass the pointer by value.
Why is it a bad idea to reset the pointer to NULL after deletion?
The problem with reseting the pointer to NULL is that it does not really solve any problem, and adds problems of its own.
It does not solve the problem of knowing whether pointers are valid in your application, as in the general case you can have more than one pointer to a given object, and because you only delete one of them, only one of the pointers will be reset to NULL, and you are left (at least in most cases) with the same situation you had in the beginning.
It can help hide bugs in the logic of your application: after you reset the pointer to NULL, any potential issue in your application by which you delete the pointer twice will be hidden, as it is safe to delete a NULL pointer. While you might think that this is a good idea --after all, it avoids crashing your application-- in the long term it is a bad idea, since the core issue is still there: the design fails to provide proper ownership semantics.
The problem has nothing to do with base class vs. derived class pointers; the problem is simply that you've declared your method to accept a pointer to pointer to MM as an argument, and you're passing just a pointer to MM.
You could pass a pointer to MM by reference -- i.e.,
void deleteInstance( T* &pInstance ) ...
I'm not sure I like what you're trying to do, but I can't put my finger on why - I think the idea is fine. .. but heres a way you could implement it .
template<typename T>
void deleteInstance( T * & pInstance )
{
// This conversion is here so you get a nice error if
// you try to use it on a type that isn't derived from MM.
MM* tmp = pInstance;
delete tmp;
pInstance = NULL;
}
The reason why deleteInstance is not working is that you are taking a non-const reference to a temporary created by the conversion of M1* or M2* to MM*.
The reason why deleteInstance2 is not working is that Derived** is not convertible to Base**. This faq explains it very well.
This is a homework assignment. The Field container was the assignment from a week ago, and now I'm supposed to use the Field container to act as a dynamic array for a struct NumPair which holds two char * like so:
struct NumPair
{
char *pFirst, *pSecond;
int count;
NumPair( char *pfirst = "", char *psecond = "", int count = 0)
: pFirst(strdup(pfirst)), pSecond(strdup(psecond)), count(count)
{ }
NumPair( const NumPair& np )
: count(np.count), pFirst(strdup(np.pFirst)), pSecond(strdup(np.pSecond))
{ }
NumPair& operator=( const NumPair& np )
{
if(this != &np)
{
pFirst = strdup(np.pFirst);
pSecond = strdup(np.pSecond);
count = np.count;
}
return *this;
}
and the Field container
Field<NumPair> dict_;
The homework requires the use of char *, and not string, so that we can get better with all this low-level stuff. I've already had some question about char to wchar_t conversions, etc.
Now I have a question as to whether or not I'm destructing the NumPair properly. The scenario is as follows:
1) Field destructor gets called
template <class T>
Field<T>::~Field()
{
delete[] v_;
}
2) Delete calls the destructor of every element NumPair in v_;
~NumPair()
{
free(pFirst);
free(pSecond);
}
Is this okay? I haven't really read too many articles about mixing and matching elements created on the heap and free-store as we wish. I figure as long as I don't use delete on an improper malloc'ed element, I should be fine.
However, I don't know the entire intricacies of the delete command, so I'm wondering whether or not this is valid design, and what I could do to make it better.
Also, of course this isn't. I'm getting an error of the type:
This may be due to a corruption of the heap and points to dbgheap
extern "C" _CRTIMP int __cdecl _CrtIsValidHeapPointer(
const void * pUserData
)
{
if (!pUserData)
return FALSE;
if (!_CrtIsValidPointer(pHdr(pUserData), sizeof(_CrtMemBlockHeader), FALSE))
return FALSE;
return HeapValidate( _crtheap, 0, pHdr(pUserData) ); // Here
}
Again, how could I improve this without the use of string?
FIELD CTOR/Copy Ctor/Assignment
template <class T>
Field<T>::Field()
: v_(0), vused_(0), vsize_(0)
{ }
template <class T>
Field<T>::Field(size_t n, const T &val)
: v_(0), vused_(n), vsize_(0)
{
if(n > 0)
{
vsize_ = 1;
while(vsize_ < n)
vsize_ <<= 1;
v_ = new T[vsize_];
std::fill(v_, (v_ + vused_), val);
}
}
template <class T>
Field<T>::Field(const Field<T> &other)
: v_(new T[other.vsize_]), vsize_(other.vsize_), vused_(other.vused_)
{
std::copy(other.v_, (other.v_ + other.vused_), v_);
}
template <class T>
Field<T>& Field<T>::operator =(const Field<T> &other)
{
this->v_ = other.v_;
this->vused_ = other.vused_;
this->vsize_ = other.vsize_;
return *this;
}
FIELD MEMBERS
T *v_;
size_t vsize_;
size_t vused_;
Your copy constructor (of Field<>) seems OK, but the operator= is problematic.
Not only does it leak memory (what happens to the original v_?), but after that, two instances of Field<> hold a pointer to the same block of memory, and the one that is destructed first will invalidate the others v_ - and you can't even tell whether that has happened.
It's not always easy to decide how to deal with operator= - some think that implicit move semantics are okay, but the rest of us see how that played out with the majority of people, with std::auto_ptr. Probably the easiest solution is to disable copying altogether, and use explicit functions for moving ownership.
Your string handling in NumPair looks ok (strdup + free) and your Field container delete[] looks okay but it's hard to say because you don't show what v_ is.
eq mentions in a comment that you should also beware of how you are copying NumPairs. By default, C++ will give you an implicit member-wise copy constructor. This is where a RAII type like std::string makes your life easier: Your std::string containing struct can be copied without any special handling on your part and memory referenced in the string will be taken care of by the string's copy. If you duplicate your NumPair (by assigning it or returning it from a function for example) then the destruction of the temporary will free your strings out from under you.
Your copy constructor for Field just copies the pointers in v_. If you have two copies of a Field, all of the NumPairs in v_ will be deleted when the first Field goes out of scope, and then deleted again when the second one does.