Gnucash c++

Ted Creedon tcreedon at easystreet.net
Thu Aug 14 03:16:43 EDT 2014


Its very possible to begin he transition to C++ by writing C++ header files.

The real advantage of C++ is the ability to take a specification (in my
case the Intel IBIS electronic buffer modeling specification
http://www.eigroup.org/ibis/ibis.htm) and modelling it with  C++ header
files that compile.

This provides an unambiguous representation of a specification allowing
multiple vendors to create data structures that always run correctly. In
addition, the early on representation (i.e is this an iterator or whatever)
and class definition really tie the code writers down.

The particular project I mentioned took a summer grad student 3 months to
create the header files from a complicated spec.

Then the project was cancelled (because it worked)! As a result vendor A's
models might not work with vendor B's simulator...

As difficult as I find C++ to understand I highly recommend its use.

Tedc



On Wed, Aug 13, 2014 at 5:20 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Aug 13, 2014, at 3:42 PM, Gour <gour at atmarama.net> wrote:
>
> > On Wed, 13 Aug 2014 11:21:59 -0400
> > Derek Atkins <warlord at MIT.EDU> wrote:
> >
> >> Ummm.. No.
> >
> > OK.
> >
> >> The benefit of C -> C++ is that except for a few minor issues with
> >> keywords you can *generally* compile C code using the C++ compiler and
> >> it will *just work*.
> >
> > That's clear.
> >
> >> The same cannot be said for Go or any other language.
> >
> > Btw, Go team converts Go compiler from C to Go. ;)
> >
> >> Please read the FAQ entry on "Why don't you (re)write GnuCash in <your
> >> favorite language>" at http://wiki.gnucash.org/wiki/FAQ
> >
> > Well, being in #gnucash I got the feeling that there is plan to abandon
> > glib, rewrite the engine and possibly even to consider Qt 'cause
> > without glib, one is not tied so much to GTK any longer.
> >
> > Considering that C --> C++ (and taking advantage of it) might be more
> > strange than C --> Go which is created to be picked easily by C devs, I
> > did throw my suggestion.
> >
> > Otoh, I believe that C --> C++ is not to be done in order to just
> > increase build time.* :-)
> >
> > * Rob Bike from the Go team says that long build times (~45mins) for C++
> > * projects was the time when Go was conceived. ;)
> >
> > I'm aware of FAQ entry, but was thinking that GC is on the verge of
> > possible (partial) rewrite.
>
> All true, but you missed Derek's point. The advantage of C++ is that one
> can use it with C *in the same file*. That means I can take a C file, tell
> the compiler it's really a C++ file, and compile it almost as-is (that's
> what Aaron's change is about, cleaning up all of the almosts). Then I can
> make a C++ class and move the functionality into it one function at a time,
> converting the C function to a wrapper with C linkage. I can test that
> against the existing C tests, add C++ tests, and move on to the next
> function. The rest of GnuCash can't tell anything's changed; new work now
> has two versions of the API to use depending on whether it's completely new
> or a modification of existing. If it comes time to start the release cycle
> and the conversion isn't complete, we can ship it as-is because nothing's
> broken.
>
> There other languages like that, but they're all AFAIK tied to particular
> proprietary platforms to some extent: Objective C and Apple, C# and
> Microsoft, Vala and Gtk+. C++ is ISO-standard with an extremely active
> committee.
>
> Regards,
> John Ralls
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


More information about the gnucash-devel mailing list