Simplest way to count instances of an object - c++

I would like to know the exact number of instances of certain objects allocated at certain point of execution. Mostly for hunting possible memory leaks(I mostly use RAII, almost no new, but still I could forget .clear() on vector before adding new elements or something similar). Ofc I could have an
atomic<int> cntMyObject;
that I -- in destructor, ++ increase in constructor, cpy constructor(I hope I covered everything :)).
But that is hardcoding for every class. And it is not simple do disable it in "Release" mode.
So is there any simple elegant way that can be easily disabled to count object instances?

Have a "counted object" class that does the proper reference counting in its constructor(s) and destructor, then derive your objects that you want to track from it. You can then use the curiously recurring template pattern to get distinct counts for any object types you wish to track.
// warning: pseudo code
template <class Obj>
class CountedObj
{
public:
CountedObj() {++total_;}
CountedObj(const CountedObj& obj) {++total_;}
~CountedObj() {--total_;}
static size_t OustandingObjects() {return total_;}
private:
static size_t total_;
};
class MyClass : private CountedObj<MyClass>
{};

you can apply this approach
#ifdef DEBUG
class ObjectCount {
static int count;
protected:
ObjectCount() {
count++;
}
public:
void static showCount() {
cout << count;
}
};
int ObjectCount::count = 0;
class Employee : public ObjectCount {
#else
class Employee {
#endif
public:
Employee(){}
Employee(const Employee & emp) {
}
};
at DEBUG mode, invoking of ObjectCount::showCount() method will return count of object(s) created.

Better off to use memory profiling & leak detection tools like Valgrind or Rational Purify.
If you can't and want to implement your own mechanism then,
You should overload the new and delete operators for your class and then implement the memory diagnostic in them.
Have a look at this C++ FAQ answer to know how to do that and what precautions you should take.

This is a sort of working example of something similar: http://www.almostinfinite.com/memtrack.html (just copy the code at the end of the page and put it in Memtrack.h, and then run TrackListMemoryUsage() or one of the other functions to see diagnostics)
It overrides operator new and does some arcane macro stuff to make it 'stamp' each allocation with information that allow it to count how many instances of an object and how much memory they're usingusing. It's not perfect though, the macros they use break down under certain conditions. If you decide to try this out make sure to include it after any standard headers.

Without knowing your code and your requirements, I see 2 reasonable options:
a) Use boost::shared_ptr. It has the atomic reference counts you suggested built in and takes care of your memory management (so that you'd never actually care to look at the count). Its reference count is available through the use_count() member.
b) If the implications of a), like dealing with pointers and having shared_ptrs everywhere, or possible performance overhead, are not acceptable for you, I'd suggest to simply use available tools for memory leak detection (e.g. Valgrind, see above) that'll report your loose objects at program exit. And there's no need to use intrusive helper classes for (anyway debug-only) tracking object counts, that just mess up your code, IMHO.

We used to have the solution of a base class with internal counter and derive from it, but we changed it all into boost::shared_ptr, it keeps a reference counter and it cleans up memory for you. The boost smart pointer family is quite useful:
boost smart pointers

My approach, which outputs leakage count to Debug Output (via the DebugPrint function implemented in our code base, replace that call with your own...)
#include <typeinfo>
#include <string.h>
class CountedObjImpl
{
public:
CountedObjImpl(const char* className) : mClassName(className) {}
~CountedObjImpl()
{
DebugPrint(_T("**##** Leakage count for %hs: %Iu\n"), mClassName.c_str(), mInstanceCount);
}
size_t& GetCounter()
{
return mInstanceCount;
}
private:
size_t mInstanceCount = 0;
std::string mClassName;
};
template <class Obj>
class CountedObj
{
public:
CountedObj() { GetCounter()++; }
CountedObj(const CountedObj& obj) { GetCounter()++; }
~CountedObj() { GetCounter()--; }
static size_t OustandingObjects() { return GetCounter(); }
private:
size_t& GetCounter()
{
static CountedObjImpl mCountedObjImpl(typeid(Obj).name());
return mCountedObjImpl.GetCounter();
}
};
Example usage:
class PostLoadInfoPostLoadCB : public PostLoadCallback, private CountedObj<PostLoadInfoPostLoadCB>

Adding counters to individual classes was discussed in some of the answers. However, it requires to pick the classes to have counted and modify them in one way or the other. The assumption in the following is, you are adding such counters to find bugs where more objects of certain classes are kept alive than expected.
To shortly recap some things mentioned already: For real memory leaks, certainly there is valgrind:memcheck and the leak sanitizers. However, for other scenarios without real leaks they do not help (uncleared vectors, map entries with keys never accessed, cycles of shared_ptrs, ...).
But, since this was not mentioned: In the valgrind tool suite there is also massif, which can provide you with the information about all pieces of allocated memory and where they were allocated. However, let's assume that valgrind:massif is also not an option for you, and you truly want instance counts.
For the purpose of occasional bug hunting - if you are open for some hackish solution and if the above options don't work - you might consider the following: Nowadays, many objects on the heap are effectively held by smart pointers. This could be the smart pointer classes from the standard library, or the smart pointer classes of the respective helper libraries you use. The trick is then the following (picking the shared_ptr as an example): You can get instance counters for many classes at once by patching the shared_ptr implementation, namely by adding instance counts to the shared_ptr class. Then, for some class Foo, the counter belonging to shared_ptr<Foo> will give you an indication of the number of instances of class Foo.
Certainly, it is not quite as accurate as adding the counters to the respective classes directly (instances referenced only by raw pointers are not counted), but possibly it is accurate enough for your case. And, certainly, this is not about changing the smart pointer classes permanently - only during the bug hunting. At least, the smart pointer implementations are not too complex, so patching them is simple.

This approach is much simpler than the rest of the solutions here.
Make a variable for the count and make it static. Increase that variable by +1 inside the constructor and decrease it by -1 inside the destructor.
Make sure you initialize the variable (it cannot be initialized inside the header because its static).
.h
// Pseudo code warning
class MyObject
{
MyObject();
~MyObject();
static int totalObjects;
}
.cpp
int MyObject::totalObjects = 0;
MyObject::MyObject()
{
++totalObjects;
}
MyObject::~MyObject()
{
--totalObjects;
}
For every new instance you make, the constructor is called and totalObjects automatically grows by 1.

Related

Is it mandatory to delete a pointer variable within a structure, before deleting the structure?

I have started to C++ and need some clarifications regarding memory management in C++. I have come across smart pointers, but I wish to understand some basic concepts.
Here's a sample structure
struct A
{
private:
int a;
void* b;
public:
A(int i, void* m) { a=i; b=m; }
};
main()
{
A * a1 = new A(10, 0);
//
//Some Code
if(on some condition) {
delete a1;
a1=nullptr;
}
}
When I delete a1, will m also be deleted automatically or should i explicitly delete m before deleting a1 as given below?
delete a1->b;
a1->b = nullptr;
delete a1;
a1=nullptr;
When I delete a1, will m also be deleted automatically
No, it won't (your code probably has a memory leak). You need an explicit destructor deleting it.
BTW, using a void*b; pointer field is poor taste. You should prefer some more explicit type (e.g. double*b; or SomeClass* b;) if you know it. This makes your code more readable, and give more opportunities for helpful type checking at compile time.
// inside struct A
~A() { delete b; };
Read about the rule of five.
Notice that struct-s are very similar to class-es in C++.
Avoid memory leaks. Tools like valgrind could be helpful. And using systematically smart pointers and standard containers should help to avoid them. If your field b was declared std::shared_ptr<std::string> b; the default destructor would have freed it appropriately. And perhaps you want it to be some std::vector<std::string> (again, the default destructor is releasing memory appropriately).
A good coding hint is to avoid, when possible, declaring raw pointers (prefer smart pointers and containers). When you have to declare one, you need to code its delete appropriately.
Welcome to C++, a very powerful language that requires you to take responsibility of the details to achieve the flexibility that allows such power. If you like, you can make it very complex, however for most constructs their is an easy way as well.
First of all, you ain't required to release memory, if your program exits, it will clean it. However, as you don't call delete, the Dtor will not be called which might cause specific code to not be executed.
So in general, it's good practice to clean up the allocated memory.
If you don't need the heap, don't use it
new A(10, 0) will allocate memory on the heap. If you don't want that, this can as well be created on the stack. Which causes auto cleanup: A a{10, nullptr};
Use RAII
As soon as you decide, you need heap allocated memory, you should default to std::unique_ptr. Which changes the code to: auto a = std::make_unique<A>(10, nullptr); With this, ownership is within the unique_ptr, which can be moved around (std::move). If you don't want to transfer ownership, you can dereference it or call the method get.
Applying these 2 practices, including for members, will prevent a lot of memory leaks and will reduce the time you need to think about it.
Don't use void*
void* is evil, don't use it unless you have to (and you only have to when interfacing with C). There are many ways of avoiding it. The best one is introducing an interface.
class I {
public:
virtual ~I() = default;
};
class M : public I
{
// ...
};
class A
{
// ...
std::unique_ptr<I> m;
// ...
};
Need something special?
Some times, you need something special in the Dtor, only in that case you should implement the Dtor explicitly. Given your question, I'm gonna assume you are a beginner and as such don't need to know about more details for now.

Task ownership in Factory-Processor model

Factory supplies Tasks of different types to Processor asynchronously. Processor doesn't know details of Tasks and executes them via known Interface. Dynamic allocation is prohibited due to performance reasons. Factory should not own Tasks because otherwise Processor would need to inform Factory when he finishes execution of Task to do the cleanup. Processor should know only Interface, but not Tasks themselves. Processor may own Tasks as opaque objects while he processes them.
One possible solution is: store all kinds of Tasks inside the union of "Interface & padding buffer". Please, consider the following working example (C++11):
#include <iostream>
struct Interface
{
virtual void execute() {}
};
union X
{
X() {}
Interface i;
char padding[1024];
template <class T>
X& operator= (T &&y)
{
static_assert (sizeof(T) <= sizeof(padding), "X capacity is not enough!");
new (padding) T(y);
}
};
struct Task : public Interface
{
Task() : data(777) {}
virtual void execute() { std::cout << data << std::endl; }
int data;
};
int main()
{
Task t;
X x;
x = std::move(t);
Interface *i = &x.i;
i->execute();
};
The snippet works well (prints 777). But are there any dangers (like virtual inheritance) in such approach? Maybe any better solution is possible?
Your solution seems to involve both an unnecessary copy operation, and making assumptions about the layout of your objects in memory that are not guaranteed to be correct in all circumstances. It further invokes undefined behaviour by using memcpy to copy an object with virtual methods, which is explicitly disallowed by the c++ spec. It also has the potential to cause confusion over when object destructors run.
I would use an arrangement like this:
class Processor has an array of buffers, each of which is large enough to contain any defined subclass of your task interface. It has two methods used in submitting tasks:
one to return a pointer to a currently available buffer
one to submit a job
The job interface is extended with a requirement to track the pointer to the buffer that contains it (which will be supplied as a constructor parameter), and has a method to return that pointer.
Submitting a new task is now done like this:
void * buffer = processor.getBuffer();
Task * task = new (buffer) Task(buffer);
processor.submitJob(task);
(this could be simplified using a template method in Processor if required). Then, the processor simply executes jobs, and when it's done with them it asks them for their buffer, runs their destructor, and adds the buffer back into its free buffer list.
Updated answer.
See: std::aligned_union (en.cppreference.com). It is designed to be used together with placement new and explicit destructor call.
Below is the earlier answer, now retracted.
From the design perspective,
Avoiding dynamic allocation seems a drastic requirement. It requires some extraordinary justification.
In case one does not trust the standard allocator for any reason, one could still implement a custom allocator, in order to have full control of its behavior.
If there is a class or method that "owns" all instances of everything: all Factories, all Processors, and all Tasks (as is the case in your main() method), then it is not necessary to copy anything. Just pass references or pointers around, since this "class or method that owns everything" will take care of object lifetime.
My answer is only applicable to the question about "memcpy".
I do not try to cover the issue of memcpy-ing between "Task which has Interface as base class, and X which has Interface as member". This doesn't seem universally valid for all of the C++ compilers, but I don't know offhand which C++ compilers would fail this code.
Short answer, which is applicable to all C++ compilers:
To use memcpy on a type, the type needs to be trivially copyable.
Currently, trivially copyable lists "no virtual functions" as one of the necessary conditions, so the "according to the spec" answer is that your struct Task is not trivially copyable.
The longer, non-standard answer is whether your particular compiler will synthesize the struct and the machine code that would be effectively copyable (i.e. without ill-effects), despite the C++ specification saying no. Obviously this answer will be compiler-specific, and will depend on a lot of circumstances (such as optimization flags and minor code changes).
Remember that compiler optimization and code generation can change from version to version. There is no guarantee that the next version of the compiler will behave exactly the same.
To give an example of something that would be likely to be unsafe for memcpy-ing between two instances, consider:
struct Task : public Interface
{
Task(std::string&& s)
: data(std::move(s))
{}
virtual void execute() { std::cout << data << std::endl; }
std::string data;
};
The reason this is problematic is that, for sufficiently long strings, std::string will allocate dynamic memory to store its content. If there are two instances of Task, and memcpy is used to copy its bytes from one instance to another instance (which would have copied over the internal fields of the std::string class), their pointers will point to the same address, and therefore their destructors will both try to delete the same memory, leading to undefined behavior. In addition, if the instance that was being overwritten had an earlier string value, the memory will not be freed.
Since you have said that "dynamic allocation is prohibited", my guess is that you will not be using std::string or anything similar, instead opting to write C-like code exclusively. So this concern may not be relevant to you.
Speaking of "low level C-like code", here is my idea:
struct TaskBuffer
{
typedef void (*ExecuteFunc) (TaskBuffer*);
ExecuteFunc executeFunc;
char padding[1024];
};
void ProcessMethod(TaskBuffer* tb)
{
(tb->executeFunc)(tb);
}

Pointers to stack-allocated object and move-contruction

Note: This is a complete re-wording of a question I posted a while ago. If you find they are duplicate, please close the other one.
My problem is quite general but it seems that it could be explained more easily based on a concrete simple example.
So imagine I want to simulate the electricity consumption in an office throught time. Let's assume that there is only a light and heating.
class Simulation {
public:
Simulation(Time const& t, double lightMaxPower, double heatingMaxPower)
: time(t)
, light(&time,lightMaxPower)
, heating(&time,heatingMaxPower) {}
private:
Time time; // Note : stack-allocated
Light light;
Heating heating;
};
class Light {
public:
Light(Time const* time, double lightMaxPower)
: timePtr(time)
, lightMaxPower(lightMaxPower) {}
bool isOn() const {
if (timePtr->isNight()) {
return true;
} else {
return false;
}
}
double power() const {
if (isOn()) {
return lightMaxPower;
} else {
return 0.;
}
private:
Time const* timePtr; // Note : non-owning pointer
double lightMaxPower;
};
// Same kind of stuff for Heating
The important points are:
1.Time cannot be moved to be a data member Light or Heating since its change does not come from any of these classes.
2.Time does not have to be explicitly passed as a parameter to Light. Indeed, there could be a reference to Light in any part of the program that does not want to provide Time as a parameter.
class SimulationBuilder {
public:
Simulation build() {
Time time("2015/01/01-12:34:56");
double lightMaxPower = 42.;
double heatingMaxPower = 43.;
return Simulation(time,lightMaxPower,heatingMaxPower);
}
};
int main() {
SimulationBuilder builder;
auto simulation = builder.build();
WeaklyRelatedPartOfTheProgram lightConsumptionReport;
lightConsumptionReport.editReport((simulation.getLight())); // No need to supply Time information
return 0;
}
Now, Simulation is perfectly find as long as it is not copy/move constructed. Because if it is, Light will also get copy/move constructed and by default, the pointer to Time will be pointing to the Time in the old Simulation instance which is copied/moved from.
However, Simulation actually is copy/move constructed in between the return statement in SimulationBuilder::build() and the object creation in main()
Now there are a number of ways to solve the problem:
1: Rely on copy elision. In this case (and in my real code) copy elision seems to be allowed by the standard. But not required, and as a matter of fact, it is not elided by clang -O3. To be more precise, clang elides Simulation copy, but does call the move ctor for Light. Also notice that relying on an implementation-dependent time is not robust.
2: Define a move-ctor in Simulation:
Simulation::Simulation(Simulation&& old)
: time(old.time)
, light(old.light)
, heating(old.heating)
{
light.resetTimePtr(&time);
heating.resetTimePtr(&time);
}
Light::resetTimePtr(Time const* t) {
timePtr = t;
}
This does work but the big problem here is that it weakens encapsulation: now Simulation has to know that Light needs more info during a move. In this simplified example, this is not too bad, but imagine timePtr is not directly in Light but in one of its sub-sub-sub-member. Then I would have to write
Simulation::Simulation(Simulation&& old)
: time(old.time)
, subStruct(old.subStruct)
{
subStruct.getSubMember().getSubMember().getSubMember().resetTimePtr(&time);
}
which completly breaks encapsulation and the law of Demeter. Even when delegating functions I find it horrible.
3: Use some kind of observer pattern where Time is being observed by Light and sends a message when it is copy/move constructed so that Light change its pointer when receiving the message.
I must confess I am lazy to write a complete example of it but I think it will be so heavy I am not sure the added complexity worth it.
4: Use a owning pointer in Simulation:
class Simulation {
private:
std::unique_ptr<Time> const time; // Note : heap-allocated
};
Now when Simulation is moved, the Time memory is not, so the pointer in Light is not invalidated. Actually this is what almost every other object-oriented language does since all objects are created on the heap.
For now, I favor this solution, but still think it is not perfect: heap-allocation could by slow, but more importantly it simply does not seems idiomatic. I've heard B. Stroustrup say that you should not use a pointer when not needed and needed meant more or less polymorphic.
5: Construct Simulation in-place, without it being return by SimulationBuilder (Then copy/move ctor/assignment in Simulation can then all be deleted). For instance
class Simulation {
public:
Simulation(SimulationBuilder const& builder) {
builder.build(*this);
}
private:
Time time; // Note : stack-allocated
Light light;
Heating heating;
...
};
class SimulationBuilder {
public:
void build(Simulation& simulation) {
simulation.time("2015/01/01-12:34:56");
simulation.lightMaxPower = 42.;
simulation.heatingMaxPower = 43.;
}
};
Now my questions are the following:
1: What solution would you use? Do you think of another one?
2: Do you think there is something wrong in the original design? What would you do to fix it?
3: Did you ever came across this kind of pattern? I find it rather common throughout my code. Generally though, this is not a problem since Time is indeed polymorphic and hence heap-allocated.
4: Coming back to the root of the problem, which is "There is no need to move, I only want an unmovable object to be created in-place, but the compiler won't allow me to do so" why is there no simple solution in C++ and is there a solution in another language ?
If all classes need access to the same const (and therefore immutable) feature, you have (at least) 2 options to make the code clean and maintainable:
store copies of the SharedFeature rather than references - this is reasonable if SharedFeature is both small and stateless.
store a std::shared_ptr<const SharedFeature> rather than a reference to const - this works in all cases, with almost no additional expense. std::shared_ptr is of course fully move-aware.
EDIT: Due to the class naming and ordering I completely missed the fact that your two classes are unrelated.
It's really hard to help you with such an abstract concept as "feature" but I'm going to completely change my thought here. I would suggest moving the feature's ownership into MySubStruct. Now copying and moving will work fine because only MySubStruct knows about it and is able to make the correct copy. Now MyClass needs to be able to operate on feature. So, where needed just add delegation to MySubStruct: subStruct.do_something_with_feature(params);.
If your feature needs data members from both sub struct AND MyClass then I think you split responsibilities incorrectly and need to reconsider all the way back to the split of MyClass and MySubStruct.
Original answer based on the assumption that MySubStruct was a child of MyClass:
I believe the correct answer is to remove featurePtr from the child and provide a proper protected interface to feature in the parent (note: I really do mean an abstract interface here, not just a get_feature() function). Then the parent doesn't have to know about children and the child can operator on the feature as needed.
To be completely clear: MySubStruct will not know that the parent class even HAS a member called feature. For example, perhaps something like this:
1: What solution would you use? Do you think of another one?
Why not apply a few design patterns? I see uses for a factory and a singleton in your solution. There are probably a few others that we could claim work but I am way more experienced with applying a Factory during a simulation than anything else.
Simulation turns into a Singleton.
The build() function in SimulationBuilder gets moved into Simulation. The constructor for Simulation gets privatized, and your main call becomes Simulation * builder = Simulation::build();. Simulation also gets a new variable static Simulation * _Instance;, and we make a few changes to Simulation::build()
class Simulation
{
public:
static Simulation * build()
{
// Note: If you don't need a singleton, just create and return a pointer here.
if(_Instance == nullptr)
{
Time time("2015/01/01-12:34:56");
double lightMaxPower = 42.;
double heatingMaxPower = 43.;
_Instance = new Simulation(time, lightMaxPower, heatingMaxPower);
}
return _Instance;
}
private:
static Simulation * _Instance;
}
Simulation * Simulation::_Instance = nullptr;
Light and Heating objects get provided as a Factory.
This thought is worthless if you are only going to have 2 objects inside of simulation. But, if you are going to be managing 1...N objects and multiple types, then I would strongly encourage you utilize a factory, and a dynamic list (vector, deque, etc.). You would need to make Light and Heating inherit from a common template, set things up to register those classes with the factory, set the factory so that it is templated and an instance of the factory can only create objects of a specific template, and initialize the factory for the Simulation object. Basically the factory would look something like this
template<class T>
class Factory
{
// I made this a singleton so you don't have to worry about
// which instance of the factory creates which product.
static std::shared_ptr<Factory<T>> _Instance;
// This map just needs a key, and a pointer to a constructor function.
std::map<std::string, std::function< T * (void)>> m_Objects;
public:
~Factory() {}
static std::shared_ptr<Factory<T>> CreateFactory()
{
// Hey create a singleton factory here. Good Luck.
return _Instance;
}
// This will register a predefined function definition.
template<typename P>
void Register(std::string name)
{
m_Objects[name] = [](void) -> P * return new P(); };
}
// This could be tweaked to register an unknown function definition,
void Register(std::string name, std::function<T * (void)> constructor)
{
m_Objects[name] = constructor;
}
std::shared_ptr<T> GetProduct(std::string name)
{
auto it = m_Objects.find(name);
if(it != m_Objects.end())
{
return std::shared_ptr<T>(it->second());
}
return nullptr;
}
}
// We need to instantiate the singleton instance for this type.
template<class T>
std::shared_ptr<Factory<T>> Factory<T>::_Instance = nullptr;
That may seem a bit weird, but it really makes creating templated objects fun. You can register them by doing this:
// To load a product we would call it like this:
pFactory.get()->Register<Light>("Light");
pFactory.get()->Register<Heating>("Heating");
And then when you need to actually get an object all you need is:
std::shared_ptr<Light> light = pFactory.get()->GetProduct("Light");
2: Do you think there is something wrong in the original design? What would you do to fix it?
Yeah I certainly do, but unfortunately I don't have much to expound upon from my answer to item 1.
If I were to fix anything I start "fixing" by seeing what a Profiling session tells me. If I was worried about things like time to allocate memory, then profiling is the best way to get an accurate idea about how long to expect allocations to take. All the theories in the world cannot make up for profiling when you are not reusing known profiled implementations.
Also, if I were truly worried about the speed of things like memory allocation then I would take into consideration things from my profiling run such as the number of times that an object is created vs the objects time of life, hopefully my profiling session told me this. An object like your Simulation class should be created at most 1 time for a given simulation run while an object like Light might be created 0..N times during the run. So, I would focus on how creating Light objects affected my performance.
3: Did you ever came across this kind of pattern? I find it rather common throughout my code. Generally though, this is not a problem since Time is indeed polymorphic and hence heap-allocated.
I do not typically see simulation objects maintain a way to see the current state change variables such as Time. I typically see an object maintain its state, and only update when a time change occurs through a function such as SetState(Time & t){...}. If you think about it, that kind of makes sense. A simulation is a way to see the change of objects given a particular parameter(s), and the parameter should not be required for the object to report its state. Thus, an object should only update by single function and maintain its state between function calls.
// This little snippet is to give you an example of how update the state.
// I guess you could also do a publish subscribe for the SetState function.
class Light
{
public:
Light(double maxPower)
: currPower(0.0)
, maxPower(maxPower)
{}
void SetState(const Time & t)
{
currentPower = t.isNight() ? maxPower : 0.0;
}
double GetCurrentPower() const
{
return currentPower;
}
private:
double currentPower;
double maxPower;
}
Keeping an object from performing its own check on Time helps alleviate multithreaded stresses such as "How do I handle the case where the time changes and invalidates my on/off state after I read the time, but before I returned my state?"
4: Coming back to the root of the problem, which is "There is no need to move, I only want an unmovable object to be created in-place, but the compiler won't allow me to do so" why is there no simple solution in C++ and is there a solution in another language ?
If you only ever want 1 object to be created you can use the Singleton Design Pattern. When correctly implemented a Singleton is guaranteed to only ever make 1 instance of an object, even in a multithreaded scenario.
In the comment to your second solution, you're saying that it weakens the encapsulation, because the Simulation has to know that Light needs more information during move. I think it is the other way around. The Light needs to know that is being used in a context where the provided reference to the Time object may become invalid during Light's lifetime. Which is not good, because it forces a design of Light based on how it is being used, not based on what it should do.
Passing a reference between two objects creates (or should create) a contract between them. When passing a reference to a function, that reference should be valid until the function being called returns. When passing a reference to an object constructor, that reference should be valid throughout the lifetime of the constructed object. The object passing a reference is responsible for its validity. If you don't follow this, you may create very hard to trace relationships between the user of the reference and an entity maintaining lifetime of the referenced object. In your example, the Simulation is unable to uphold the contract between it and the Light object it creates when it is moved. Since the lifetime of the Light object is tightly coupled to the lifetime of the Simulation object, there are 3 ways to resolve this:
1) your solution number 2)
2) pass a reference to the Time object to constructor of the Simulation. If you assume the contract between the Simulation and the outer entity passing the reference is reliable, so will be the contract between Simulation and Light. You may, however, consider the Time object to be internal detail of the Simulation object and thus you would break encapsulation.
3) make the Simulation unmovable. Since C++(11/14) does not have any "in-place constructor methods" (don't know how good a term that is), you cannot create an in-place object by returning it from some function. Copy/Move-elision is currently an optimalization, not a feature. For this, you can either use your solution 5) or use lambdas, like this:
class SimulationBuilder {
public:
template< typename SimOp >
void withNewSimulation(const SimOp& simOp) {
Time time("2015/01/01-12:34:56");
double lightMaxPower = 42.;
double heatingMaxPower = 43.;
Simulation simulation(time,lightMaxPower,heatingMaxPower);
simOp( simulation );
}
};
int main() {
SimulationBuilder builder;
builder.withNewSimulation([] (Simulation& simulation) {
WeaklyRelatedPartOfTheProgram lightConsumptionReport;
lightConsumptionReport.editReport((simulation.getLight())); // No need to supply Time information
}
return 0;
}
If none fits your needs, then you either have to reevaluate your needs (might be a good option, too) or use heap allocation and pointers somewhere.

Detecting memory leak in reference counted objects

I am trying to print on which line addref and release is called.Here is code
In code below I have created on ReferenceCount class whose main functionality to increase and decrease refernce count.
Referencemanager class keeps track of reference count and deletes the object once it reaches 0.
Test1 is test class .In main I am creating Test1 pointer and wrapping it with CReferenceManager class. Now during creation of CReferenceManager class AddRef is called and while destruction Release would be called.
If there is memory leak then it would be easier to detect if I can print out FILE and LINE numbers when AddRef and Release called with reference counts at that point.
If there a way that I can print FILE and LINE number from where AddRef and Release gets called. One way is that I can overwrite AddRef and Release in derived classes and prinf FILE and LINE numbers
//ReferenceCount.h
#include <string>
#include <Windows.h>
using namespace std;
class CReferenceCount
{
public:
CReferenceCount();
virtual ~CReferenceCount();
virtual void AddRef();
virtual bool Release();
private:
LONG m_ref;
};
// RefCount.cpp
//
#include "stdafx.h"
#include "ReferenceCount.h"
CReferenceCount::CReferenceCount():m_ref(0)
{
AddRef();
}
CReferenceCount::~CReferenceCount()
{
}
void CReferenceCount::AddRef()
{
InterlockedIncrement(&m_ref);
}
bool CReferenceCount::Release()
{
if (InterlockedDecrement(&m_ref) == 0)
{
delete this;
return true;
}
return false;
}
//ReferenceManager.h
#include <string>
#include <Windows.h>
using namespace std;
class CReferenceCount
{
public:
CReferenceCount();
virtual ~CReferenceCount();
virtual void AddRef();
virtual bool Release();
private:
LONG m_ref;
};
//test.cpp
#include "stdafx.h"
#include "ReferenceCount.h"
#include "RefManager.h"
#include <iostream>
using namespace std;
class Test1: public CReferenceCount
{
public:
Test1(){}
~Test1(){}
private :
int m_i;
};
void main()
{
Test1 *pTest= new Test1();
CReferenceManager<Test1> testRef(pTest);
}
Similare questions I have posted
finding who creates object via smart pointer
Design pattern to detect memory leaks for reference counted smart pointers
but non of the answers give right explanation to tackle this proble,
The only way is to define macros for calling AddRef and Release, since there is no way for the functions to know internally from where they are being called. So you could use something like.
#define RELEASE(obj) cout << __LINE__ << ":" << __FILE__ << endl; (obj).Release();
Also, different compilers have different pre-defined macros; if portability is a concern, it's something you should look into when writing code like the above. MSDN reference (2003)
Given your comments below, i might offer another somewhat hackish solution. You may not be able to see where your reference is being released, but you can get more information about where it was created, and which are not being released properly.
template <typename T>
struct CReferenceManager
{
CReferenceManager(const T & _obj, const string & _file, int _line) : mObj(_obj), mFile(_file), mLine(_line)
{
cout << "Constructing from " << _file << ":" << _line << endl;
CReferenceManager::sObjects[make_pair(mFile, mLine)]++;
mObj.addRef();
}
~CReferenceManager()
{
cout << "Destructing object created at " << mFile << ":" << mLine << endl;
CReferenceManager::sObjects[make_pair(mFile, mLine)]--;
mObj.Release();
}
static map<pair<string, int>, int> sObjects;
string mFile;
int mLine;
T obj;
}
int main()
{
...
// Cycle through sObjects before return, note any unreleased entries
return 0;
}
Note this is just pseudo-code; I doubt it compiles or works out of the box!
You should never allocate or release references explicitly in your own code, so storing the source file and line where references are incremented or decremented isn't going to help you at all, since those will (should!) always be inside the reference counting management code.
You did not include the source code to your CReferenceManager class, but based on your description it is a wrapper to a referenced counted object. Is this correct? The correct implementation of this CReferenceManager object should ensure that:
a constructor that takes a naked pointer stores the pointer and does not change the reference count (since your CReferenceCount class creates object with one reference)
reference is always decremented in the destructor
reference is incremented in the copy-constructor
reference for the right side object is incremented, and reference for the left side object is decremented in the assignment operator
no explicit increment/decrement reference methods should be exposed
the operator->() method should return the pointer to the object
there should be no direct way to detach the reference counted object from a CReferenceManager instance that owns it. The only way is via assignment of a new reference counted object.
Also, you'd want to make the AddRef() and Release() methods in your CReferenceCount class private, and make them accessible only to the CReferenceManager class via class friendship.
If you follow the above rules in your CReferenceManager class, then you can avoid leaks or other memory problems by ensuring that everybody accesses the object via a CReferenceManager wrapper allocated on the stack. In other words:
To create a new referenced counted object, passed a newly created object (with one reference) to a stack allocated CReferenceManager object. Example:
CReferenceManager<Test1> testRef(new Test1());
To pass the object as an argument to another function or method, always pass a CReferenceManager object by value (not by reference, and not by pointer). If you do it this way the copy constructor and the destructor will take care of maintaining the reference counts for you. Example:
void someFunction(CReferenceManager<Test1> testObj)
{
// use testObj as if it was a naked pointer
// reference mananagement is automatically handled
printf("some value: %d\n", testObj->someValue());
}
int main()
{
CReferenceManager<Test1> testRef(new Test1());
someFunction(testRef);
}
If you need to stick the reference counted object in a container, then insert a CReferenceManager wrapper by value (not its pointer, and not the object's naked pointer). Example:
std::vector< CReferenceManager<Test1> > myVector;
CReferenceManager<Test1> testRef(new Test1());
myVector.push_back(testRef);
myVector[0]->some_method(); // invoke the object as if it was a pointer!
I believe if you strictly follow the above rules the only problems you will find are bugs in your reference counting implementation.
An example implementation that follows these rules is in this page, though that solution lacks any support for multi-threading protection.
I hope this helps!
There is some way of doing this, but first let me ask you one thing. Why you want to manage references by hand and provide an opportunity for memory leaks? you can easily use boost::intrusive_ptr to do the job for you?( if you don't want the boost, there is no problem, see implementation of intrusive_ptr and implement your own class or just copy it to your own file ) and then you don't have a memory leak to search for it!!
But as an answer for your question you could have 2 AddRef/Release one for debug version and another for release and you should add AddRef positions to an structure like std::stack and on Release pop them from stack and at very end you see how much references from witch positions remained in the stack! but if this is for COM implementation remember that COM may call AddRef multiple time and then remove them at later time and thus you can't understand which AddRef have no corresponding Release.
For the projects I am involved in I had similar needs. We have our own smart-pointer template class and from time to time memory leaks appeared due to circular references.
To know which smart-pointer referencing a leaked object still is alive (2 or more), we compile the sources with a special pre-processor define which enables special debugging code in the smart-pointer implementation. You can have a look at our smart-pointer class.
In essence, each smart-pointer and reference counted object get a unique id. When we get the id for the leaked object (usually using valgrind to identify the source location of the memory allocation for the leaked object), we use our special debugging code to get all smart-pointer ids which reference the object. Then we use a configuration file where we write down the smart-pointer ids and at next application start-up, this file is read by our debugging tool which then knows for which newly created smart-pointer instance it should trigger a signal for entering the debugger. This reveals the stack trace where that smart-pointer instance was created.
Admittedly, this involves some work and might only pay off for larger projects.
Another possibility would be to record a stack trace inside your AddRef method at runtime. Have a look at my ctkBackTrace class to create a stack trace at runtime. It should be easy to replace the Qt specific types by standard STL types.
I guess that with a bit of work and using libunwind you could probably try to get what you need (which would be a really appreciated).
http://www.nongnu.org/libunwind/docs.html
The principle of reference counting is to increase the counter when the user link to the object and to decrease when they break the link.
So you have to:
manipulate smart pointers, not pointers to make increase/decrease transparent
overload copy constructor and assign operator of the smart_pointer
Symbolic exemple:
A a = new A(); refcount = 0, nobody use it
Link<A> lnk( a ); refcount = 1
obj.f( lnk ); obj stores lnk, refcount = 2
this method may returns since the ownership has been transfered to obj
So, take a look at parameter passing (may do automatic copies) and at copy into foreign objects.
Good tutorials exists on that in the CORBA nebulae.
You may see also ACE or ICE, or 0MQ.
One way to do what you asked, is to pass AddRef and Release this information using something like this:
void CReferenceCount::AddRef(const char *file=0, int line=-1) { if (file) cout << "FILE:" << file; if (line>0) count << " LINE: " << line; .... do the rest here ... }
Then when you call the function, you can use a macro similar to what Rollie suggested above, like this:
#define ADDREF(x) x.AddRef(__FILE__, __LINE__)
This will pass the file and line where the call is made, which I believe is what you asked for. You can control what you want to do with the information within the methods. Printing them out, as I did above, is just an example. You may want to collect more information beyond this, and log it to another object, so you have a history of your calls, write them to a log file, etc. You may also pass more information from the call points than just the file and line, according to the type and level of tracking you need. The default parameters also allow you to use them without passing anything (by a simple macro redefinition), just to see how the final version will behave, with the overhead of two stack pushes and two condition checks.
Short answer: you should use the ideas that others posted, namely making use of ADD/RELEASE macros and passing the predefined __FILE__ and __LINE__ macros that the compiler provides to your tracking class.
Slightly longer answer: You can also use functionality that allows you to walk the stack and see who called the function, which is somewhat more flexible and clean than using macros, but almost certainly slower.
This page shows you how to achieve this when using GCC: http://tombarta.wordpress.com/2008/08/01/c-stack-traces-with-gcc/.
In Windows you can use some compiler intrinsics along with symbol-lookup functionality. For details check out: http://www.codeproject.com/tools/minidump.asp
Note that in both cases your program would need to include at least some symbols for this to work.
Unless you have special requirements for doing this at runtime, I'd suggest you check out the short answer.

Accessing Members of Containing Objects from Contained Objects

If I have several levels of object containment (one object defines and instantiates another object which define and instantiate another object..), is it possible to get access to upper, containing - object variables and functions, please?
Example:
class CObjectOne
{
public:
CObjectOne::CObjectOne() { Create(); };
void Create();
std::vector<ObjectTwo>vObejctsTwo;
int nVariableOne;
}
bool CObjectOne::Create()
{
CObjectTwo ObjectTwo(this);
vObjectsTwo.push_back(ObjectTwo);
}
class CObjectTwo
{
public:
CObjectTwo::CObjectTwo(CObjectOne* pObject)
{
pObjectOne = pObject;
Create();
};
void Create();
CObjectOne* GetObjectOne(){return pObjectOne;};
std::vector<CObjectTrhee>vObjectsTrhee;
CObjectOne* pObjectOne;
int nVariableTwo;
}
bool CObjectTwo::Create()
{
CObjectThree ObjectThree(this);
vObjectsThree.push_back(ObjectThree);
}
class CObjectThree
{
public:
CObjectThree::CObjectThree(CObjectTwo* pObject)
{
pObjectTwo = pObject;
Create();
};
void Create();
CObjectTwo* GetObjectTwo(){return pObjectTwo;};
std::vector<CObjectsFour>vObjectsFour;
CObjectTwo* pObjectTwo;
int nVariableThree;
}
bool CObjectThree::Create()
{
CObjectFour ObjectFour(this);
vObjectsFour.push_back(ObjectFour);
}
main()
{
CObjectOne myObject1;
}
Say, that from within CObjectThree I need to access nVariableOne in CObjectOne. I would like to do it as follows:
int nValue = vObjectThree[index].GetObjectTwo()->GetObjectOne()->nVariable1;
However, after compiling and running my application, I get Memory Access Violation error.
What is wrong with the code above(it is example, and might contain spelling mistakes)?
Do I have to create the objects dynamically instead of statically?
Is there any other way how to achieve variables stored in containing objects from withing contained objects?
When you pass a pointer that points back to the container object, this pointer is sometimes called a back pointer. I see this technique being used all the time in GUI libraries where a widget might want access to its parent widget.
That being said, you should ask yourself if there's a better design that doesn't involve circular dependencies (circular in the sense that the container depends on the containee and the containee depends on the container).
You don't strictly have to create the objects dynamically for the back pointer technique to work. You can always take the address of a stack-allocated (or statically-allocated) object. As long as the life of that object persists while others are using pointers to it. But in practice, this technique is usually used with dynamically-created objects.
Note that you might also be able to use a back-reference instead of a back-pointer.
I think I know what's causing your segmentation faults. When your vectors reallocate their memory (as the result of growing to a larger size), the addresses of the old vector elements become invalid. But the children (and grand-children) of these objects still hold the old addresses in their back-pointers!
For the back-pointer thing to work, you'll have to allocate each object dynamically and store their pointers in the vectors. This will make memory management a lot more messy, so you might want to use smart pointers or boost::ptr_containers.
After seeing the comment you made in another answer, I now have a better idea of what you're trying to accomplish. You should research generic tree structures and the composite pattern. The composite pattern is usually what's used in the widget example I cited previously.
Maybe all your object can inherit from a common interface like :
class MyObject
{
public:
virtual int getData() = 0;
}
And after you can use a std::tree from the stl library to build your structure.
As Emile said, segmentation fault is caused by reallocation. Exactly speaking -- when the local stack objects' 'this' pointer was passed to create another object, which is then copied to the vector container. Then the 'Create()' function exits, the stack frame object ceases to exist and the pointer in the container gets invalid.