Is there some good example code to show poor memory management (e.g. the programmer assumes there is garbage collection)?
I would like to demonstrate this during class. The VM we're using has 16 available hardware threads.
Recent work in Chapel has been trying to reduce the number of cases where a programmer might unwittingly leak memory (for example, see the section on delete-free programming in the release notes for Chapel 1.18). That said, allocating instances of unmanaged classes is a way to generate an intentional memory leak:
// run with --memTrack in order for the memoryUsed() call to work
use Memory;
class C {
var A: [1..1000000] real;
}
for i in 1..1000000 {
var myC = new unmanaged C();
writeln(memoryUsed());
}
Specifically, the compiler is not responsible for freeing instances of unmanaged classes; the user must do so via the delete statement. Failure to do so will cause the memory for that class to be leaked.
Therefore, a leak-free version of the above would be:
// run with --memTrack in order for the memoryUsed() call to work
use Memory;
class C {
var A: [1..1000000] real;
}
for i in 1..1000000 {
var myC = new unmanaged C();
writeln(memoryUsed());
delete myC;
}
Related
I am a beginner to programming and I am trying to find a way to create a dynamic storage of objects of my pigeon class. Here is my code:
class pigeon {
public:
pigeon(std::string nameI);
void outputInfo();
private:
std::string name;
};
The idea is that I want to be able to add a new object, have a place to store its information, then be able to add another object, and so on. I have no idea where to start with this or even what data structure to use, I have no experience storing objects.
As it was already pointed out in the comments, you should preferably use a container that handles its resources following the RAII/RDID-idiom ( "Resource Acquisition Is Initialisation" / "Resource Destruction is Deletion") so you don't have to worry about it yourself. This is also a simple way of preventing resource leaks when an exception is thrown.
One of the commonly used containers of the C++ standard library is std::vector<>.
You'd use it like this (just to give you an initial idea, please refer to the documentation for further explanation and examples):
#include <vector>
// ...
{
std::vector<pigeon> pigeons;
pigeons.push_back("Karl"); // add three pigeons
pigeons.push_back("Franz"); // at the end of the
pigeons.push_back("Xaver"); // vector
pigeons[1]; // access "Franz"
for(auto /* maybe const */ &p : pigeons) { // iterate over the vector
// do something with pigeon p
}
} // pigeons goes out of scope, its destructor is called which
// takes care of deallocating the memory used by the vector.
Make vector with pointer of your class:
std::vector<pigeon*> pigeons;
Then allocate new pigeon object and push it into your vector:
pigeon * pig = new pigeon("pigeon");
pigeons.push_back(pig);
I have a scenario where I need to create different objects in each iteration of a 'for' loop.
The catch here is the synthesizer I am working does not support the "new" keyword. The Synthesizer I am using translates C/C++ code to RTL code (Hardware). So many of the constructs in C++ is not supported by the compiler.
I want to implement something like this:
test inst[5];
for(int i=0;i<5;i++)
inst[i].test_func();
I googled this problem, but all the solutions i have come across use "new" keyword.
I need a way to create different objects on every iteration of the loop without the "new" keyword. Is there a way to do so?
Essentially I am trying to emulate the behavior of 'For-generate' construct in VHDL.
Any help or suggestions is greatly appreciated.
If you can't allocate memory dynamically, you'd have to resort to redefining operator new and new[] to use memory from statically allocated pool. You will also have to implement operator delete and delete[] as well. Quite a daunting task, I'd say, unless you have something to relax some requirements for such allocators in general.
I have a suspicion you may be better off forgetting about strange subsets of C++ as a means of generating hardware, and simply writing what you want in VHDL, which, being a hardware description language, has the tools for the job.
While VHDL supports new for simulation, naturally new cannot be used for synthesis, as it implies the dynamic allocation of hardware resources ... not supported by any ASIC or FPGA toolchain in existence today.
So as far as I can see, you simply want an array of 488 objects of whatever type test is, and to operate on all of them simultaneously with the test_func() operation (whatever that is). For which you probably want a for ... generate statement.
I'm not sure if this is what you are looking for, but you could do something like this:
class Test {};
class Test0 : public Test {};
class Test1 : public Test {};
class Test2 : public Test {};
class Test3 : public Test {};
class Test4 : public Test {};
static Test0 test0;
static Test1 test1;
static Test2 test2;
static Test3 test3;
static Test4 test4;
int main(int, char **)
{
Test * tests[5] = {&test0, &test1, &test2, &test3, &test4};
for (int i=0; i<5; i++)
{
Test * t = tests[i];
// t->init_func(); // or etc
}
return 0;
}
You could have all objects preallocated and reusable. I mean, suppose you know you will only need at most 10 objects living concurrently. You then create 10 objects and push them to a list of unused objects
Whenever you need to "create" an object, just take it from the unused objects list. When you no longer need it, you can push it back to that list.
If you know the constant size of each object, you could just allocate an array of chars, and then when you need object #i, take the pointer.
int const size_of_obj_in_bytes = 20;
int const num_of_objects_to_allocate = 488;
char c[const num_of_objects_to_allocate*size_of_obj_in_bytes];
obj* get_ptr_to_obj_at_index(int i) {
return (obj*)(&c[i*size_of_obj_in_bytes]);
}
if the object is to live in the context of a function, you might be able to utilize stack allocation (alloca) to handle it. Stack allocations should be supported in your subset. You can override the 'new' method to use this function (or whatever is available for stack manipulations).
Just remember, as soon as you leave the parent function, all will be destroyed. You will need to take extra care to call a destructor, if needed.
The purpose of the PIMPL idiom is to hide implementation, including methods, structures, and even sizes of structures. One downside is it uses the heap.
However, what if I didn't want to hide the size requirements of anything. I just wanted to hide methods, the formatting of the structure and the variable names. One way would be to allocate an array of bytes of the perfect size, have the implementation constantly cast that to whatever structure and use that. But manually find the size of the bytes to allocate for the object? And do casts all the time? Obviously not practical.
Is there an idiom or general way of handling this case that is advantageous to PIMPL or opaque pointers.
A rather different approach could be to rethink the nature of what your objects really represent. In traditional OOP it's customary to think of all objects as self-contained entities that have their own data and methods. Some of those methods will be private to the class because they're just required for that class's own housekeeping, and so these are the kind of thing you usually move the 'impl' of a Pimpl class.
In a recent project I've been favouring the Domain-Driven Design approach where one of the desirables is to separate the data from the logic that does things with it. The data classes then become little more than structs, and the complex logic that previously was hidden in the Pimpl now can go in a Service object that has no state of its own.
Consider a (rather contrived) example of a game loop:
class EnemySoldier : public GameObject
{
public:
// just implement the basic GameObject interface
void updateState();
void draw(Surface&);
private:
std::unique_ptr<EnemySoldierImp> m_Pimpl;
};
class EnemySolderImpl
{
public:
// 100 methods of complex AI logic
// that you don't want exposed to clients
private:
StateData m_StateData;
};
void runGame()
{
for (auto gameObject : allGameObjects) {
gameObject->updateState();
}
}
This could be restructured so that instead of the GameObjects managing their data and their program logic, we separate these two things out:
class EnemySoldierData
{
public:
// some getters may be allowed, all other data only
// modifiable by the Service class. No program logic in this class
private:
friend class EnemySoldierAIService;
StateData m_StateData;
};
class EnemySoldierAIService
{
public:
EnemySoldierAIService() {}
void updateState(Game& game) {
for (auto& enemySoldierData : game.getAllEnemySoldierData()) {
updateStateForSoldier(game, enemySoldierData);
}
}
// 100 methods of AI logic are now here
// no state variables
};
We now don't have any need for Pimpls or any hacky tricks with memory allocation. We can also use the game programming technique of getting better cache performance and reduced memory fragmentation by storing the global state in several flat vectors rather than needing an array of pointers-to-base-classes, eg:
class Game
{
public:
std::vector<EnemySoldierData> m_SoldierData;
std::vector<MissileData> m_MissileData;
...
}
I find that this general approach really simplifies a lot of program code:
There's less need for Pimpls
The program logic is all in one place
It's much easier to retain backwards compatibility or drop in alternate implementations by choosing between the V1 and V2 version of the Service class at runtime
Much less heap allocation
The information you are trying to hide is exactly the same information the compiler needs in order to calculate the size. Which is to say, no, there is no idiom for finding the size without knowing the number and data types of the non-static members, because it isn't even possible.
On the other hand, you can hide the existence of helper functions just fine. Simply declare a nested type (this gives the nested members access to the private members of the outer class) and define that type only inside your private implementation file, putting your helper logic in static member functions of the nested type. You'll have to pass a pointer to the object instance to operate on as a parameter, but then you can access all members.
Example:
class FlatAPI
{
void helperNeedsPublicAccess();
void helperNeedsFullAccess();
T data;
public:
void publicFunction();
};
becomes
class PublicAPI
{
struct helpers;
T data;
public:
void publicFunction();
};
and implementation code
#include <public.h>
static void helperNeedsPublicAccess(PublicAPI* pThis) { pThis->publicFunction(); }
struct PublicAPI::helpers
{
static void helperNeedsFullAccess(PublicAPI* pThis) { std::cout << pThis->data; }
};
void PublicAPI::publicFunction()
{
helpers::helperNeedsFullAccess(this);
}
So here's a possible alternative that doesn't have the downsides of constant casting but improves the memory layout to make it similar to if you hadn't used PIMPL at all.
I'm going to assume that you application isn't really using just one pimpl, but actually you are using the pimpl for many classes, so its like, the impl of the first pimpl holds pimpls for many children classes, and the impls of those hold pimpls to many third-tier classes etc.
(The kinds of objects I'm envisioning are like, all the managers, the schedulers, the various kinds of engines in your app. Most likely not all the actual data records, those are probably in a standard container owned by one of the managers. But all the objects that you generally only have a fixed number of in the course of the application.)
The first idea is, similar to how std::make_shared works, I want to allocate the main object right along-side the "helper" object so that I get the "fast" memory layout without breaking encapsulation. The way I do this is allocate a contiguous block of memory big enough for both, and use placement new, so that the pimpl is right next to the impl.
By itself, that's not really any improvement, because the pimpl is just the size of a pointer, and whoever owns the pimpl now needs a pointer to the pimpl since it's now heap allocated.
However, now we basically try to do this for all of the layers at once.
What is needed to actually make this work:
Each pimpl class needs to expose a static member function which is available at run time which indicates its size in bytes. If the corresponding impl is simple, this might just be return sizeof(my_impl). If the corresponding impl contains other pimpls, then this is return sizeof(my_impl) + child_pimpl1::size() + child_pimpl2::size() + ....
Each pimpl class needs a custom operator new or similar factory function that will allocate to a given block of memory of the appropriate size
The pimpl and its impl (minus the pimpl children you are handling recursively)
Each of the pimpl children in succession, using their corresponding operator new or similar function.
Now, at the beginning of your app, you make one gigantic heap allocation which holds the "root" manager object or whatever corresponding object. (If there isn't one then you would introduce one just for this purpose.) And you use its factory function there, allocating all of these objects contiguously.
I think this gives essentially the same benefits as if you made all the pimpls hold char[] of the exactly right size and constantly casted things. It will only work well though if you really only need a fixed number of these guys, or never too many. If you need to tear down and rebuild these objects often, that's okay, since you'll just manually call the destructors and use placement new to reconstruct. But you won't really be able to give any of the memory back until the end of the application, so there's some trade-off involved.
The purpose of the PIMPL idiom is to hide implementation, including
methods, structures, and even sizes of structures.
See also, http://herbsutter.com/gotw/_100/
One downside is it uses the heap.
I consider the use of the heap an upside. Stack is much more valuable and
much more limited (8Mbytes vs 3GBytes on my hw).
However, what if I didn't want to hide the size requirements of
anything.
My imagination has failed me many times. I will try to assume you know
what you want, and why you want it.
IMHO, failing to hide size info is of no consequence.
I just wanted to hide methods, and the formatting of the structure and
the variable names.
I think you still need to expose ctor and dtor
(or named alternatives i.e. createFoo/removeFoo )
One way would be to allocate an array of bytes of the perfect size,
this is easily done.
have the implementation constantly cast that to whatever structure and
use that.
IMHO no casting is required (I have never needed it - see MCVE below.)
But, even if you cast for some reason I can't guess at,
remember that casting (without conversion) causes no code,
and thus no performance issue.
But manually find the size of the bytes to allocate for the object?
Pragmatically this is only a minor challenge during development
(when the size might change). In my earlier career, I have
initially guessed for a dozen efforts, typically using a somewhat bigger than necessary data size estimate to accommodate growth.
I then add a run time assert (you might prefer to use "if clause")
to generate notices when the size is bigger than the goal. It has been my experience that the data size has always stabilized very quickly.
It is trivial to make the size info exact (if you want).
And do casts all the time? Obviously not practical.
I do not understand why you think casts are involved. I do not use
any in the pimples I create (nor in the MCVE below).
I do not understand why you (and at least 1 other) think casts are not
practical. non-conversion casts cost nothing (at runtime) and are
completely handled by the compiler. Maybe I will ask SO some related question someday. Even my editor can automate the cast prefix.
I do not understand why at least 1 comment thinks there are void
pointers to cast. I have used none.
Is there an idiom or general way of handling this case that is
advantageous to PIMPL or opaque pointers.
I know of no such idiom. I have found several examples that I think
conform to my expectations of handling pimpl, does that make them
general? Probably not.
Note, however, that from my many years in embedded systems work I
consider the below listed summarized ideas / requirements as relatively simple
challenges.
Feed back welcome.
Summary Requirements:
cancel size information hiding. Size info exposure is acceptable.
hide methods (exception: ctor and dtor or named ctor/dtor alternatives)
allocate array of bytes (implBuff) as location for pimple attribute.
manually provide pimple size info
provide output to cout the current impl size (to simplify development)
assert when manual size of implBuff is too small to hold actual impl
assert when manual size of implBuff is too wasteful of space
demonstrate why casting is not required
(hmmm, negative proofs are difficult.how about I simply show code with no casting needed)
Make note of pathological dependencies, show pragmatic solution if easy
NOTE:
These choices are sometimes not without 'pathological dependencies',
I have found 2, which I think are easily handled or ignored. See below.
The following MCVE builds and runs on my Ubuntu 15.04, g++ ver 4.9.2-10ubuntu13
An example output follows the code:
#include <iostream>
#include <sstream>
#include <vector>
#include <cassert>
// ///////////////////////////////////////////////////////////////////////
// ///////////////////////////////////////////////////////////////////////
// file Foo.hh
class Foo // a pimple example
{
public:
Foo();
~Foo();
// alternative for above two methods: use named ctor/dtor
// diagnostics only
std::string show();
// OTHER METHODS not desired
private:
// pathological dependency 1 - manual guess vs actual size
enum SizeGuessEnum { SizeGuess = 24048 };
char implBuff [SizeGuess]; // space inside Foo object to hold FooImpl
// NOTE - this is _not_ an allocation - it is _not_ new'd, so do not delete
// optional: declare the name of the class/struct to hold Foo attributes
// this is only a class declaration, with no implementation info
// and gives nothing away with its name
class FooImpl;
// USE RAW pointer only, DO NOT USE any form of unique_ptr
// because pi does _not_ point to a heap allocated buffer
FooImpl* pi; // pointer-to-implementation
};
// ///////////////////////////////////////////////////////////////////////
// ///////////////////////////////////////////////////////////////////////
// top of file Foo.cc
typedef std::vector<std::string> StringVec;
// the impl defined first
class Foo::FooImpl
{
private:
friend class Foo; // allow Foo full access
FooImpl() : m_indx(++M_indx)
{
std::cout << "\n Foo::FooImpl() sizeof() = "
<< sizeof(*this); // proof this is accessed
}
~FooImpl() { m_indx = 0; }
uint64_t m_indx; // unique id for this instance
StringVec m_stringVec[1000]; // room for 1000 strings
static uint64_t M_indx;
};
uint64_t Foo::FooImpl::M_indx = 0; // allocation of static
// Foo ctor
Foo::Foo(void) : pi (nullptr)
{
// pathological dependency 1 - manual guess vs actual size
{
// perform a one-time run-time VALIDATE of SizeGuess
// get the compiler's actual size
const size_t ActualSize = sizeof(FooImpl);
// SizeGuess must accomodate entire FooImpl
assert(SizeGuess >= ActualSize);
// tolerate some extra buffer - production code might combine above with below to make exact
// SizeGuess can be a little bit too big, but not more than 10 bytes too big
assert(SizeGuess <= (ActualSize+10));
}
// when get here, the implBuff has enough space to hold a complete Foo::FooImpl
// some might say that the following 'for loop' would cause undefined behavior
// by treating the code differently than subsequent usage
// I think it does not matter, so I will skip
{
// 0 out the implBuff
// for (int i=0; i<SizeGuess; ++i) implBuff[i] = 0;
}
// pathological dependency 2 - use of placement new
// --> DOES NOT allocate heap space (so do not deallocate in dtor)
pi = new (implBuff) FooImpl();
// NOTE: placement new does not allocate, it only runs the ctor at the address
// confirmed by cout of m_indx
}
Foo::~Foo(void)
{
// pathological dependency 2 - placement new DOES NOT allocate heap space
// DO NOT delete what pi points to
// YOU MAY perform here the actions you think are needed of the FooImpl dtor
// or
// YOU MAY write a FooImpl.dtor and directly invoke it (i.e. pi->~FooImpl() )
//
// BUT -- DO NOT delete pi, because FOO did not allocate *pi
}
std::string Foo::show() // for diagnostics only
{
// because foo is friend class, foo methods have direct access to impl
std::stringstream ss;
ss << "\nsizeof(FooImpl): " << sizeof(FooImpl)
<< "\n SizeGuess: " << SizeGuess
<< "\n this: " << (void*) this
<< "\n &implBuff: " << &implBuff
<< "\n pi->m_indx: " << pi->m_indx;
return (ss.str());
}
int t238(void) // called by main
{
{
Foo foo;
std::cout << "\n foo on stack: " << sizeof(foo) << " bytes";
std::cout << foo.show() << std::endl;
}
{
Foo* foo = new Foo;
std::cout << "\nfoo ptr to Heap: " << sizeof(foo) << " bytes";
std::cout << "\n foo in Heap: " << sizeof(*foo) << " bytes";
std::cout << foo->show() << std::endl;
delete foo;
}
return (0);
}
Example output:
// output
// Foo::FooImpl() sizeof() = 24008
// foo on stack: 24056 bytes
// sizeof(FooImpl): 24008
// SizeGuess: 24048
// this: 0x7fff269e37d0
// &implBuff: 0x7fff269e37d0
// pi->m_indx: 1
//
// Foo::FooImpl() sizeof() = 24008
// foo ptr to Heap: 8 bytes
// foo in Heap: 24056 bytes
// sizeof(FooImpl): 24008
// SizeGuess: 24048
// this: 0x1deffe0
// &implBuff: 0x1deffe0
// pi->m_indx: 2
I use shared_ptr as an instance variable in Objective-C class. So I want to know if memory management is correct.
#interface MyClass () {
#private
std::shared_ptr<vector<pair<pair<float, float>, pair<float, float>>>> _periods; // In real code I use typedefs
}
Objects of this class lives long and happy life. But I must overwrite _periods often.
First I create initial _periods in init with helper function which looks like this.
shared_ptr<vector<pair<pair<float, float>, pair<float, float>>>> periodsScaled(...)
{
auto periods = std::make_shared<RALG::periods>();
// ... fill pairs of points
return periods;
}
Then in MyClass I have generatePeriods function which overwrites instance variable.
- (void)generatePeriods
{
_periods.reset(); // Should I really use reset here to delete existing periods?
_periods = periods(...);
}
Also I have -dealloc implementation
- (void)dealloc;
{
_periods.reset(); // Should I reset shared pointer in dealloc?
// other class-specific routines
}
Is my code correct in terms of shared_ptr memory management? I am quite new to C++
My application uses a large amount of Panda objects. Each Panda has a list of Bamboo objects. This list does not change once the Panda is initialized (no Bamboo objects are added or removed). Currently, my class is implemented as follows:
class Panda
{
int a;
int b;
int _bambooCount;
Bamboo* _bamboo;
Panda (int count, Bamboo* bamboo)
{
_bambooCount = count;
_bamboo = new Bamboo[count];
// ... copy bamboo into the array ...
}
}
To alleviate the overhead of allocating an array of Bamboo objects, I could implement this class as follows -- basically, instead of creating objects via the regular constructor, a construction method allocates a single memory block to hold both the Panda object and its Bamboo array:
class Panda
{
int a;
int b;
Panda ()
{
// ... other initializations here ...
}
static Panda *createPanda (int count, Bamboo* bamboo)
{
byte* p = new byte[sizeof(Panda) +
sizeof(Bamboo) * count];
new (p) Panda ();
Bamboo* bamboo = (Bamboo*)
p + sizeof(Panda);
// ... copy bamboo objects into the memory
// behind the object...
return (Panda*)p;
}
}
Can you foresee any problems with the second design, other than the increased maintenance effort? Is this an acceptable design pattern, or simply a premature optimization that could come back to bite me later?
C++ gives you another option. You should consider using std::vector.
class Panda
{
int a;
int b;
std::vector<Bamboo> bamboo;
// if you do not want to store by value:
//std::vector< shared_ptr<Bamboo> > bamboo;
Panda (int count, Bamboo* bamb) : bamboo( bamb, bamb+count ) {}
}
If you want to store Panda and Bamboos in continuous memory you could use solution from this article. The main idea is to overload operator new and operator delete.
How do we convince people that in programming simplicity and clarity --in short: what mathematicians call 'elegance'-- are not a dispensable luxury, but a crucial matter that decides between success and failure?
-- Edsger W. Dijkstra
You'll be bitten if someone takes a Panda by value e.g.
//compiler allocates 16-bytes on the stack for this local variable
Panda panda = *createPanda(15, bamboo);
It may be acceptable (but is very probably a premature and horrible optimization) if you only ever refer to things by pointer and never by value, and if you beware the copy constructor and assignment operator.
Based on my experience, premature optimization is most always "premature".. That is to say you should profile your code and determine whether or not there is a need for optimization or you are just creating more work for yourself in the long run.
Also, it seems to me that the questions as to whether the optimization is worth it or not depends a lot on the size of the Bamboo class and the average number of Bamboo objects per Panda.
This was find in C.
But in C++ there is no real need.
The real question is why do you want to do this?
This is a premature optimization, just use a std::vector<> internally and all your problems will disappear.
Because you are using a RAW pointer internally that the class owns you would need to override the default versions of:
Default Constructor
Destructor
Copy Constructor
Assignment operator
If you're that desperate, you can probably do something like this:
template<std::size_t N>
class Panda_with_bamboo : public Panda_without_bamboo
{
int a;
int b;
Bamboo bamboo[N];
}
But I believe you're not desperate, but optimizing prematurely.
You use "new" look of new operator. It is fully correct relative Panda, but why don't you use Bamboo initializer?