The big issue is whether Gecode/J is really the right thing to use for you. Yes, it is fairly open but no match to Gecode. All requests can be instantly satisified for Gecode or do not even arise.
I know that C++ sounds less appealing but Gecode is first and foremost geared to be good as a C++ library. Gecode/J is a bastard between something that is just a Java interface to Gecode and something that can be extended. Here the extension mechanisms had been designed to be good enough for classroom use. We are not really clear ourselves what the future of Gecode/J will be. I myself plan to use Gecode directly in the next run of the CP course I teach (this year I did not have enough time to rework the course material) as it is actually more accessible and less trouble to install than Gecode/J. And, it has a version of Gist that is way better than the one which ships with Gecode/J. The most popular route might be to castrate Gecode/J that it just becomes an ordinary Java interface to Gecode but that functionality for writing propagators in Java, etc will be removed. Christian On 4/8/08 4:30 AM, "Malcolm Ryan" <[EMAIL PROTECTED]> wrote: > Is there any reason why JavaBranchingDesc is final in Gecode/J? My > problem naturally has a number of different kinds of branch > descriptions depending on what variable they apply to. It is annoying > to have to encode this into some arbitrary integer and then decode it > again when I commit. It would be much nice to have a collection of > different BranchingDesc classes each with their own commit method. > > Malcolm > > _______________________________________________ > Gecode users mailing list > [EMAIL PROTECTED] > https://www.gecode.org/mailman/listinfo/gecode-users -- Christian Schulte, web.ict.kth.se/~cschulte/ _______________________________________________ Gecode users mailing list [EMAIL PROTECTED] https://www.gecode.org/mailman/listinfo/gecode-users
