Re: [Jocr-devels] Is the C++ transition still in the pipeline?

[Rupert S. <rup...@li...>]

Joerg Schulenburg wrote:
> Hi,
> 
> Conversion of C++ is not in my pipeline.
> I am not against C++ in general. Its more due to the fact, that my time is 
> limited and I dont want to spend lot of them for rearranging code and fix 
> new bugs (Am I probably to old?).
> I also see it as a problem that object oriented code needs a careful 
> design. Gocr isnt designed that way, because I still not know what a good 
> design would be. I still learning (by doing), how OCR could be made 
> better.
> If we change to C++ we have to choose one design and I 
> think its more difficult to through it away, if it was choosen bad.
> Also I dont believe that C++ code would involve more people who contribute
> better algorithm than C code would do.
> I think bad OCR is a problem of missing good concepts and clever 
> algorithms than bad OO design.
> I have also less experiences in searching bugs in OO code.
> That are my main reasons against C++.

OK. That makes sense, I suppose.

> (b.t.w.: Why linux kernel isnt C++ code?)

Linus being reactive? Also there's a huge body of code there, which is 
_very_ well organised. I also think that C++ can hit performance if one 
makes a small mistake in the coding, and that sort of sensitivity could 
be disastrous to the kernel, maybe?

> 
> So I think its simply to early (especially for me) to make such a one way 
> decission to C++.
> 
> But its open source code, if you want to have a C++ version you can do it 
> but probably without me. I have really no time for it as long as my child
> is young and needs 90% of my attention after work. 
> Its a bit similar to the libgocr part, where I did not find the time to
> get inolved in.
> Student time is gone unfortunately where I could spent 12 hours per day 
> for progging.

I also have no wish to go it alone - I'd like to contribute to the 
project, not detract from it! However, would you be interested in, for 
example, me refactoring the pnm code - which seems to be a little buggy 
in places?

If the problem is purely not wanting to make such a huge shift, it might 
still be worth switching across the more modular parts at least - we can 
always make the interface via the header files identical with extern "C" 
functions, but it might make the thing simpler?

The only question is are you willing to have a compile-time dependency 
on a c++ compiler?

> I have no problems to make it C++ compatible (remove C++ warnings) or 
> create C compatible C++ interfaces to help a bit.
> I also want to add more explanations and comments to the code for easier
> understanding. Thats all I am able to do.

Well, I don't want to start coding if you won't use the result, but I 
could always try porting across a self-contained bit and submit the 
(fully documented?) .cc alternative?

Rupert