Remove some unused local variables and functions #752
Conversation
This fixes a compiler warning: lstm/input.cpp:141:7: warning: unused variable 'width' [-Wunused-variable] Signed-off-by: Stefan Weil <sw@weilnetz.de>
This fixes a compiler warning: api/baseapi.cpp:1621:17: warning: variable 'font_name' set but not used [-Wunused-but-set-variable] Signed-off-by: Stefan Weil <sw@weilnetz.de>
This fixes a compiler warning: ccutil/scanutils.cpp:284:7: warning: variable 'sign' set but not used [-Wunused-but-set-variable] Signed-off-by: Stefan Weil <sw@weilnetz.de>
This fixes a compiler warning: classify/trainingsampleset.cpp:510:13: warning: 'Pix* tesseract::DebugSample(const UNICHARSET&, tesseract::TrainingSample*)' defined but not used [-Wunused-function] Signed-off-by: Stefan Weil <sw@weilnetz.de>
| @@ -507,22 +507,6 @@ bool TrainingSampleSet::DeleteableSample(const TrainingSample* sample) { | |||
| return sample == NULL || sample->class_id() < 0; | |||
| } | |||
|
|
|||
| static Pix* DebugSample(const UNICHARSET& unicharset, | |||
There was a problem hiding this comment.
The whole 'classify' directory will most likely be removed by Ray (it is part of the old engine). There is no point in applying any change to files under this directory.
I disagree. Maybe that directory will be removed in the future. That's not a good reason why unused code should not be removed now. Maybe we could support a Tesseract 4 with both old and new recognizer engine at least for the next year (thus eliminating the need to support Tesseract 3 for a longer time span). I'd appreciate that scenario, but if we prevent any code maintenance of the old engine in Tesseract 4, we'll never know whether that might be possible. See also #744 which I'd apply for the same reason. My code for big endian support (#703) also changes both recognizers. |
|
If you really want to piss @theraysmith off, then fine... |
|
I don't. As far as I have understood Ray, he wants a Tesseract which works really good. LSTM in Tesseract 4 is a large step forward. Nevertheless, there is obviously still some need for the old engine until we can be sure that LSTM outperforms it in all OCR applications (see issue #707). Based on my experience I'd try to keep both engines for some time to allow easy verification of the LSTM performance. In issue #518, Ray said that he wants to remove the old engine, but is open for a discussion based on facts, and he also said what would have to be done if the old engine were kept. |
|
I understand Ray's messages on this topic differently. Zdenko will decide... Peace :-) |
|
@egorpugin |
|
I don't know. |
|
IMO removing unused function from directory, that should be removed, is not big issue. |
|
OK, I only skimmed this to get the gist. I have a commit coming (next week?) that fulfills a long-standing request - to be able to load from a trainneddata file in memory (or via a file-reader function pointer). This involves a major edit to the dead code, but I had to do it to keep Android portability. |
This fixes several compiler warnings.