When you start programming complex ContRap wrappers the most difficult issue will be the smart pointers running out of control. It is very easy to write programs which violate the general smart pointer requirement: Do not create two smart pointers pointing to the same memory frame.
First of all you should be aware of the main reason why you create illegal smart pointers: You (accidentally) dereference a smart pointer by assigning it to a regular pointer. Then you pass this regular pointer back to the smart pointer constructor. This way you create a second smart pointer to the same data. The above behaviour is demonstrated by the following simple piece of code:
int* b = a;
SPtr<int> c = b;
After the execution it is a matter of time when one of the pointers ''a'' or ''c'' runs out of scope first and is deleted. The deletion of the second pointer causes a segmentation fault.
Of course the real situations are much more tricky to detect. A typical example of a more complex situation is the following code:
return a;
}
Here ''a'' comes from the outside of the function as a smart pointer. It is dereferenced by the wrapper procedure automatically generated by ContRap. The output is again wrapped by a smart pointer. Passing ''a'' to the output creates an illegal smart pointer.
ContRap provides a means of tracking the smart pointer behaviour on a compile level. There exists a compiler flag ''--ptrdbg'' or CMake flag ''CMAKE_POINTER_DEBUG'' which you can pass to the configure script (on Unix) and to the CMake on Windows respectively. With this flags on, ContRap tries to keep track on created smart pointers and reports violations by writing to the standard output. On both above examples you will get something like the following message when running ContRap in smart pointer debugging mode:
The code, which prints this message is encapsulated in the method outside the ''crp''-namespace
Set a breakpoint to this method in smart pointer debugging mode. The backtrace will likely lead you the point where you have created an invalid smart pointer (more precisely, since both pointers are illegal, you will see the location where the second invalid pointer is created).
The smart pointer debugging mode does not protect you from writing code, which creates smart pointers to parts of data carried by an other smart pointer. The illegal code fragment below will not cause a smart pointer warning, not even in the debug mode.
return &a[2];
}
A correct version of the above code is
return SPtr<int>(&a[2], a);
}