Conversation
src/logics/ArithLogic.cc
Outdated
| #include <common/StringConv.h> | ||
| #include <common/TreeOps.h> | ||
| #include <common/numbers/FastRational.h> | ||
| #include <common/numbers/Number.h> |
There was a problem hiding this comment.
Do you really need to include the same file both in .h and the .cc file?
If it is included in the header, I would prefer to not include it again the the implementation file.
There was a problem hiding this comment.
I will remove Number.h.
FastRational.h is not necessarily included by ArithLogic.h if FAST_RATIONALS is not defined, but since it is hardcoded this way it would not work in the other case anyway.
So I will remove it as well ...
src/logics/BVLogic.h
Outdated
| #include <common/NumberUtils.h> | ||
| #include <common/numbers/NumberUtils.h> | ||
|
|
||
| #include <gmpxx.h> |
There was a problem hiding this comment.
I do not remember. Seems redundant. Removing.
src/tsolvers/lasolver/LASolver.cc
Outdated
| #include "CutCreator.h" | ||
|
|
||
| #include <models/ModelBuilder.h> | ||
| #include <common/numbers/Real.h> |
There was a problem hiding this comment.
I think not because it is not clear where Real comes from. I already experienced a few times that if not included explicitly, and if the order of the other included headers changes e.g. during a refactoring, the compilation may fail and even only on some platforms. Furthermore, it was not trivial to track down such compilation errors.
Hence I consider a better practice to not always rely on indirect inclusions by other headers. Here it would be probably better to move the inclusion into LASolver.h, though.
src/tsolvers/lasolver/Simplex.cc
Outdated
| #include "Simplex.h" | ||
|
|
||
| #include <common/InternalException.h> | ||
| #include <common/numbers/Number.h> |
There was a problem hiding this comment.
This should actually be Real.h, and moving it to Simplex.h
I am making changes in the handling of numbers according to PR #751.
As a first step, it will be useful to separate this kind of files into a separate directory.
I do not want to make these renaming changes in one PR because keeping track of the actual modifications would be difficult then.