[gecode-users] Best practice: accessing IntArgs/IntVarArgs from multiple places?

[tommaso.urli]

Dear all,

I have a question about the memory handling of IntArgs and IntVarArgs, and I cannot find an answer in the MPG.

Let's start with the IntArgs: when I write a model, I often copy the input data inside some IntArgs objects, so that I can then use them through the matrix interface, or post element constraints on them. This is fine, because I am in the constructor, and I can access them until the end of the scope which is enough to post the model. Sometimes, however, I need to access the same set of data in the print method, or in a custom brancher. I seem to have two choices here: either I build them from scratch by reading the input again (which is verbose, expensive, and clutters the code), or I can store them somewhere so that they stay accessible even out of the constructor's scope. If I decide to store them, I can either store them as static members (which I don't like, but allows me to forget about updating them throughout the space copies) or I can update them in the copy constructor. My doubt is: what is the memory footprint of keeping the IntArgs in the space? Will they be deep- or shallow-copied if I use their copy constructor?

A similar question arises for IntVarArgs. I usually use them for temporary variables and the such, however sometimes I need to access them from a brancher. Should I just transform them in IntVarArrays in this case?

Thanks for the insight,


-

Dr. Tommaso Urli

Researcher, Optimisation Research Group

DATA61 | CSIRO
E tommaso.urli at nicta.com.au<mailto:name.surname at domain.au>
M +61 403 464 731
Tower A, Level 3
7 London Circuit,
Canberra ACT 2601
www.data61.csiro.au<http://www.data61.csiro.au/>

CSIRO's Digital Productivity business unit and NICTA have joined forces to create digital powerhouse Data61

[cid:image001.png at 01D0EFD9.052ECFC0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20151020/04211e4e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CEB6FFF4-AD8B-4410-A802-D02DCB6D6512[1].png
Type: image/png
Size: 4226 bytes
Desc: CEB6FFF4-AD8B-4410-A802-D02DCB6D6512[1].png
URL: <http://www.gecode.org/pipermail/users/attachments/20151020/04211e4e/attachment.png>