Model Object Memory management about cyclus HOT 2 CLOSED

1:29 PM 
me: I've been working on implementing the use of intrusive_ptr for memory management of models and have run into some issues...
1:30 PM 
Katy: ok..

me: Because of the tight integration of Message and Model class (via transactions) there is a great deal of casting between Model* and Communicator* (and vice versa)
1:31 PM 
This makes memory management via smart pointers very difficult because Model doesn't inherit from Communicator (or vice versa).

So we are basically casting between parallely inherited classes.

Katy: the model class shouldn't hold the transactions stuff.. only the communicator class should.
1:32 PM 
me: the model class doesn't hold any transactions stuff.

Katy: so then, your problem "Because of the tight integration of Message and Model class (via transactions) " is a little confusing for me..

me: sorry
1:33 PM 
message class has methods that accept/return both communicator and model pointers.
1:34 PM 
and uses both in its implementation because of the interior Transaction struct.

I just had an idea - thanks for being a sound board.
17 minutes
1:51 PM 
me: In order for us to effectively reference count concrete models, they can only have one reference count instance variable. So I can't put a separate instance var for ref counting in both the message and communicator classes - which is the only solution I could come up with - because then we would have two separate ref counts for each object. The real solution I can think of is basically to have the Model class absorb the Communicator class.
1:53 PM 
thoughts

?
1:55 PM 
Katy: hm.

I think I'm understanding your problem.

The model class pointers in the transactions should just be communicator pointers, then.
1:56 PM 
me: There was a need to use intrusive pointers because of the leaking of the this pointer.

- yes but

Katy: so too with the methods that return models

me: they WILL need to be casted to model pointers eventually anyway

Katy: that's fine.

oh.

it's not.

right.
1:57 PM 
you'll have the same problem with time agent's wont you?

me: I don't think so...

I'd have to think about it.
1:59 PM 
Katy: I don't really like the idea of the model class absorbing the communicator class.

... but i can see why that's the solution you're coming to.
2:01 PM 
me: The time agent interface is only every used by the timer - but yes it would also be a problem.

Because the idea with smart pointers is if you don't use them everywhere, then you are going to get segfaults.
2:03 PM 
I can think of some nasty round about solutions - but having the model class absorb communicator class is still the most elegant by far. The communicator class is only 2 virtual/abstract methods anyway.
2:05 PM 
I don't think I like multiple inheritance anymore.

Katy: hm. i can see why it feels that way... but ...

you know it solves so many other ills.

i'm sure there's a good solution. keep googling? maybe talk to paul?
2:06 PM 
his research office hours might have just ended, but I'm sure you could grab him...

me: k

Katy: steve would know too.

actually

me: going to check now

Katy: being a c++ genius, steve is always my go-to man.
2:07 PM 
me: they are both gone

Katy: bummer.

you can probably grab steve via email.
2:08 PM 
it's worth thinking through, so I'm sure a full solution can wait until monday in the worst case.

good luck!
51 minutes
3:00 PM 
me: I talked with steve - the only case where an object inherits from model but not communicator is converters.

We could easily make Model class just inherit from Communicator.

But...
3:01 PM 
As far as memory management goes - my discussion with steve has shifted me toward using a manual managment strategy for Models. For messages and resource objects though, smart pointers are the better solution.