summaryrefslogtreecommitdiff
path: root/src/generic/problemresolver/incremental_expression.h
AgeCommit message (Collapse)AuthorFilesLines
2012-05-11Fix build with g++ 4.7Adrian Lang1-1/+1
2010-04-19Uniformly treat NULL pointers to incremental expressions as incremental ↵Daniel Burrows1-6/+13
expressions that are always "true". I considered trying to optimize by stripping NULLs out of "and" and "or" expressions, but that seems a bit tricky. It might be more straightforward if I introduce "true" and "false" expressions explicitly, though (part of the trouble is that it's probably bad if creation routines return NULL, and they can't currently return false).
2010-04-19Fix a line that couldn't possibly have compiled.Daniel Burrows1-2/+2
I'm guessing that nothing was instantiating that method.
2009-09-09Don't crash when dumping information about a solver without a validity ↵Daniel Burrows1-1/+5
condition.
2009-07-07Make the constructor of var_e protected so that it can be subclassed.Daniel Burrows1-0/+1
2009-06-09Add 3-way comparisons to the resolver layer instead of using operator<.Daniel Burrows1-0/+23
A 3-way comparison is the traditional "return <0, =0, or >0" protocol. The implementation supports compile-time polymorphism to select the most appropriate comparison, defaulting to operator<. This yields a huge improvement in the program run-time, probably because the program compares lots of complex objects, especially things like imm::set objects that build their comparison from sub-comparisons. It would still be good to overload compare3<> on the types used in the aptitude resolver universe -- although the core types are simple enough that the compiler will probably be able to optimize the extra comparisons away (I hope, anyway).
2009-06-02Fix enough compile errors that the problem resolver subdirectory compiles.Daniel Burrows1-3/+1
The rest of the code still needs to be overhauled to take the changes into account, and it looks like there are bugs in code that's only instantiated from the client (e.g., reject_version()).
2009-05-26Add a convenience class for writing "expressions" that are mainly listeners.Daniel Burrows1-0/+39
2009-05-26Add a default implementation of dump() in expression_box.Daniel Burrows1-0/+11
2009-05-26Also be careful about NULL pointers in get_value().Daniel Burrows1-2/+10
2009-05-26Implement operator= for expression boxes.Daniel Burrows1-0/+8
2009-05-26Be more careful about NULL pointers.Daniel Burrows1-3/+6
I really meant to write this code in the last commit, but the cat distracted me by jumping on the keyboard and I forgot to do it.
2009-05-26Use the new box_expression to implement not_e.Daniel Burrows1-5/+2
2009-05-26Write a helper class that contains the code needed to manage a container ↵Daniel Burrows1-0/+44
that contains just one value.
2009-05-26Use a set, not a vector, to track the parents of an expression.Daniel Burrows1-25/+14
I was wrong when I said that removing parents would be uncommon, of course: we do it every time a parent is deleted!
2009-05-26Implement operator< for expression weak references.Daniel Burrows1-0/+5
2009-05-23Fix up parent lists by removing parents that are going away.Daniel Burrows1-0/+38
This could be used to avoid weak references, but it would be a bit costly. I don't expect this will actually be used much, but it will avoid a correctness violation if we need it.
2009-05-22Connect children to parents in the standard expression classes.Daniel Burrows1-0/+4
2009-05-22Fix the iteration in the container's dump routine to use typename where it's ↵Daniel Burrows1-1/+1
necessary.
2009-05-22Actually, take raw pointers in add_parent().Daniel Burrows1-2/+3
The reason here is that this will be invoked from constructors, which can't have smart pointers since the object isn't created yet.
2009-05-22Add a way for subclasses of container to register their children.Daniel Burrows1-0/+8
2009-05-22Allow expression weak references to be directly initialized from cwidget ↵Daniel Burrows1-0/+8
ref_ptrs.
2009-05-22Add support for dumping incremental expression trees.Daniel Burrows1-0/+40
Current values aren't dumped at the moment.
2009-05-17Commit a non-working, incomplete iteration of the incremental rewrite of the ↵Daniel Burrows1-0/+442
resolver. I don't normally commit broken code, but this is a huge rewrite, and I'd hate to lose it if my hard drive blew up.