My Wish List - convert to c++?

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Browder schrieb:
> On 8/8/06, Christian Stimming <stimming at tuhh.de> wrote:
>> >   -convert the whole C code base to C++
>>
>> The programming language itself doesn't change any of our current
>> problems. This won't happen.
> 
> I must politely ask, why not?  I have volunteered to do it, and there
> should be very little, if any, impact on current code (may have to
> watch out for some keywords like 'class' ) but for future refactoring
> and efficiency there should be a win.  C programmers could still
> pretty much do their own thing as long as they want to.

You suggest to convert the code to C++ without changing any of the
structure so far? Sounds... interesting, maybe.

However, I can think of a few downsides of this transition, mainly
concerning portability: Currently gnucash can compiler on a *lot* of
platforms (*BSD, Solaris, Mac OSX), which is clearly one benefit of
using only C. I doubt whether c++ compilers are around as much as are c
compilers on these platforms. So that's something you would loose.

What would be the benefit, then? The class and structure conventions are
mostly not freely decided by us, but instead they are enforced by the
currently used GUI toolkit. The GUI toolkit happens to be gtk, which
does OO programming in the C language, and we have to stick with that
unless the project switches to a different GUI toolkit. As explained a
different GUI toolkit is not an option, so I just don't see where we
should get any advantage of programming gtk code in c++ instead of C.

There might be a little benefit in terms of the basic gnucash
structures, which could then be grouped as classes, but OTOH this is
really very limited. The structures aren't as bad at all; much worse is
the handling of containers, which are all GList's of void* pointers.
Getting rid of *these* would be a benefit. I'd prefer a
std::vector<Account> over a GList /** of Account pointers */ any day.
But again, it's impossible as long as we use the gtk toolkit because
that one needs to be able to directly use even the lists through
callbacks and such.

In summary: There are (probably) real disadvantages in terms of
portability. And advantages in terms of refactoring can (probably) not
at all be used because of the gtk toolkit. That's why I said this
(probably) won't happen.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRNig22XAi+BfhivFAQJo+QP+OczPkXeSxT8wVcT19ovlphSd8elLtand
nX2Ve2t69FgzO5LvzqLSbXzZ6HBnQpMBe9D5Vj1U0v6KeEw2Z/RGqyh+Alam0cQL
48W5ERsfUEgYT+E9ZWk7GPTVB4kmzB9EaqMQUObxahau4xkpbHzsnFLGaIsHINNp
DROkUOqfDqg=
=vsiw
-----END PGP SIGNATURE-----