Memory management in Variants

[JulienDoerner]

fixes #493:

The abstractConditions added a property to the candidate on the rejection. Up to now it only adds the key Rejected. I added the module name as the default Value for the flag.

Also the variant (in which this key is stored), does not have the right destructor. If it is deleted, the type of the variant was not passed to the clear function. Therefore no deletion of the variant was possible. This leaded to the bug in the memory consumption.

[lukasmerten]

I have not yet checked if it fixes the actual bug, but in principle it looks good to me. When I have verified the fix and my comments are addressed, I am happy to merge.

[lukasmerten]

This would allow to check which module deactivated the candidate, right?

[JulienDoerner]

Yes, this is the idea. This function was already implemented earlier but the value was not set correctly. I think the module name as default is a good starting option, without going through all modules and set it by hand.

[JulienDoerner]

The error also occurred for setting a property to a candidate, but only if the property is of type STRING.

for i in range(10_000_000): 
  c = Candidate() 
  c.setProperty("k", "str")

will give the same issue as discussed before. With the explicit delete this issue is solved.

The only remaining point is related to the AssocVector.

Python gives the warning
swig/python detected a memory leak of type 'Loki::AssocVector< std::string,crpropa::Variant > *', no destructor found.
when running the following example:

 c = Candidate()
 c.properties 
 c.isActive() 

One solution could be to change the AssocVector to std::map which should have the same functionality, or does someone no a difference why we should keep the AssocVector?

[rafaelab]

Hi @JulienDoerner
In the last exchange you said there is a problem with AssocVector.
Is that fixed? Do you think the PR is good to go with this issue unaddressed?