Re: Gnucash c++
On Thursday 14 August 2014 10:04:55 Gour wrote: > On Wed, 13 Aug 2014 17:20:51 -0700 > > John Ralls wrote: > > 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. > > It sounds good *in theory*, but I'm not so sure you're going to > rewrite engine and get rid of cruft this way. > > Still, as a happy GC user, I wish you all success. > > For the sake of experiment I briefly tried KMyMoney anticipating that > (maybe) KDE could fill the need, but *very* quickly I was back to > xfce/i3/Gnucash. :-) > Off topic for this thread - I'd love to hear what were the things you liked about KMyMoney and what you found missing. Can I ask you to share your experience in another e-mail thread on gnucash-user ? It would IMO be very valuable feedback for gnucash to learn about it's strengths and weaknesses. Feel free to mention I asked about this if you start such a topic. Thanks, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Wed, 13 Aug 2014 17:20:51 -0700 John Ralls wrote: > 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. It sounds good *in theory*, but I'm not so sure you're going to rewrite engine and get rid of cruft this way. Still, as a happy GC user, I wish you all success. For the sake of experiment I briefly tried KMyMoney anticipating that (maybe) KDE could fill the need, but *very* quickly I was back to xfce/i3/Gnucash. :-) Sincerely, Gour -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
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 wrote: > > On Aug 13, 2014, at 3:42 PM, Gour wrote: > > > On Wed, 13 Aug 2014 11:21:59 -0400 > > Derek Atkins 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 >> 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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 13, 2014, at 3:42 PM, Gour wrote: > On Wed, 13 Aug 2014 11:21:59 -0400 > Derek Atkins 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 > 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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins 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 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 the best! Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
Gour writes:
> On Tue, 5 Aug 2014 11:04:00 -0700
> John Ralls wrote:
>
> Hello all,
>
>> What is the motivation for compiling everything as C++ if it's still
>> really C and you have to wrap everything in extern "C" {} to get it
>> to link, especially in gnome and register directories, which can't be
>> converted to C++?
>
> when I visited #gnucash the other day I heard about the plan to (slowly) move
> to C++.
>
> Although I'm aware that I do not have 'currency' to influence the switch, I'd
> just like to give my 0.02hrk (1$ ~ 5.8hrk) and propose to (just) consider
> using
> Go language instead.
Ummm.. No.
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*. The same cannot be said for Go or any other
language.
Please read the FAQ entry on "Why don't you (re)write GnuCash in " at http://wiki.gnucash.org/wiki/FAQ
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Tue, 5 Aug 2014 11:04:00 -0700
John Ralls wrote:
Hello all,
> What is the motivation for compiling everything as C++ if it's still
> really C and you have to wrap everything in extern "C" {} to get it
> to link, especially in gnome and register directories, which can't be
> converted to C++?
when I visited #gnucash the other day I heard about the plan to (slowly) move
to C++.
Although I'm aware that I do not have 'currency' to influence the switch, I'd
just like to give my 0.02hrk (1$ ~ 5.8hrk) and propose to (just) consider using
Go language instead.
Here is nice article http://talks.golang.org/2012/splash.article explaining
about the reason to conceive the language which is solving some of the
performance problems encounted when building large C++ apps.
Moreover, it is meant to be easily approachable for the developers being
familiar with C (which is not really the case with C++) and we could say that
Go is kind of 'modern C'.
Not wanting to go deeper into any sort of argumentation being more than happy
that Gnucash is givne to me for free this is just attempt to my side in order
to provide some feedback to make GC even better developer-wise.
Sincerely,
Gour
--
The work of a man who is unattached to the modes of material
nature and who is fully situated in transcendental knowledge
merges entirely into transcendence.
http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 12, 2014, at 7:22 AM, Aaron Laws wrote:
> On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming
> wrote:
>
>> Hi Aaron,
>>
>> thanks for investing time in Gnucash and also in its development towards
>> more
>> future-proof programming technologies.
>
>
> The pleasure is mine.
>
>
>> I was a bit puzzled about the benefit
>> of switching the "normal compiling" from C to C++, just by itself. IMHO,
>> there
>> is of course an immediate benefit if the data structures move from plain C
>> structs to C++ classes, with constructor/destructor and such. If you plan
>> to
>> do such a transition with any of gnucash's data structures, of course every
>> code using those will have to be C++. However, just changing this into C++
>> doesn't also solve the problem here: The usage of the C structs in the
>> code is
>> just that: C structs, with foo_new() and foo_delete() functions and maybe
>> even
>> glib's reference counting. To really use C++ classes instead, every single
>> usage of those old C idioms will have to be replaced by proper C++
>> constructs.
>> IMHO, "just" switching the C compiling to C++ doesn't quite bring you much
>> gain here. Do you think it helps you much?
>
>
> Thanks for asking! You're right, changing the compiler from gcc to g++ does
> nothing to directly improve maintainability or performance of the code in
> question. As I see it, the gains come after that painful process. I'll go
> ahead and repeat the strategy I'm investigating for reference:
>
> 1) Make all code compile as c++ code
> 2) Add poison to make it idiomatic c++ code
> 3) Make higher level changes
>
> Part of the strategy includes this plan being followed rather strictly.
> Using this plan, step 3 brings with it the possibility of converting
> interfaces to c++ (giving classes constructors and destructors, making
> templated algorithms, etc.). Currently, for instance, the guid object is
> not usable as proper c++ code even if there were a client code file that
> could take advantage of it, because there is no c++ interface in the header
> file; if there were, all the C code would barf at compile-time.
>
>
>> [...snip...] I see some more
>> benefit when changing individual data structures to C++, then switching the
>> old C functions into wrappers that make the new C++ behaviour available to
>> the
>> C side.
>
>
> In a way, that's just what I'm going for. The only way to make typedef
> struct _gncGuid {...} GncGUID; into class GncGUID; is to make sure that
> every compilation unit (which uses GUID) knows what "class GncGUID;" means!
> At that point, it would be no problem to make GncGUID a class (or a typedef
> for a boost class), and even manage it with smart pointers or whatever.
> This can be done right alongside (for example) the existing glib date
> interface. With this kind of change, we're freed from the requirement that
> each code file communicates with the other code files "in C". We are now
> free to speak a different language as we desire, as we are able, and,
> importantly, at our liesure.
>
>
>> This means the existing C code can continue to compile in C, and the
>> next steps would rather be to open the possibility for new C++ code such as
>> unittests and maybe new GUI code in C++ (or python or something similar).
>
>
> So it sounds like you're talking about introducing new c++ code that uses
> the existing C interfaces, which I think is an obvious win. The next win
> that I'm striving to see is the existing C code start to use C++ idioms,
> data structures, etc.
>
> It would be nice if all that makes sense, but I know better than to even
> hope for that :-). Thanks again for asking, and please help me clarify by
> asking more questions!
When you compile a struct in C++, it gets a set of constructors and a
destructor regardless of whether you write them or not.
The GUI API that we're currently using is in C, as are all of the container
classes (GList mostly) and the GValue data-passing mechanism that's for the
moment central to KVP and the SQL backend. Quite a lot of those APIs work with
callbacks that must be in C linkage, and those callbacks are typically static
functions. Few of them are pre-declared, so it will be a tedious job to find
each one and create an extern "C" declaration for it. In the container case
it's wasted work: It gets thrown away when the using class is rewritten in C++
with std containers.
Take a look at the way I've wrapped GncNumeric with gnc_numeric in
https://github.com/jralls/gnucash/blob/libmpdecimal/src/libqof/qof/gnc-numeric.h
C++ code can use class GncNumeric directly (once the operator overloads are
added) while C code continues to use the gnc_numeric API.
I'm in favor of cleaning out the C++ reserved words (looks like namespace and
class are the primary offenders; the Gnome rubric is to use klass, so let's do
that instead of clas). Doing so will speed up the file-by-file conversion when
the time comes. I don't think that trying to make
Re: Gnucash c++
On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming
wrote:
> Hi Aaron,
>
> thanks for investing time in Gnucash and also in its development towards
> more
> future-proof programming technologies.
The pleasure is mine.
> I was a bit puzzled about the benefit
> of switching the "normal compiling" from C to C++, just by itself. IMHO,
> there
> is of course an immediate benefit if the data structures move from plain C
> structs to C++ classes, with constructor/destructor and such. If you plan
> to
> do such a transition with any of gnucash's data structures, of course every
> code using those will have to be C++. However, just changing this into C++
> doesn't also solve the problem here: The usage of the C structs in the
> code is
> just that: C structs, with foo_new() and foo_delete() functions and maybe
> even
> glib's reference counting. To really use C++ classes instead, every single
> usage of those old C idioms will have to be replaced by proper C++
> constructs.
> IMHO, "just" switching the C compiling to C++ doesn't quite bring you much
> gain here. Do you think it helps you much?
Thanks for asking! You're right, changing the compiler from gcc to g++ does
nothing to directly improve maintainability or performance of the code in
question. As I see it, the gains come after that painful process. I'll go
ahead and repeat the strategy I'm investigating for reference:
1) Make all code compile as c++ code
2) Add poison to make it idiomatic c++ code
3) Make higher level changes
Part of the strategy includes this plan being followed rather strictly.
Using this plan, step 3 brings with it the possibility of converting
interfaces to c++ (giving classes constructors and destructors, making
templated algorithms, etc.). Currently, for instance, the guid object is
not usable as proper c++ code even if there were a client code file that
could take advantage of it, because there is no c++ interface in the header
file; if there were, all the C code would barf at compile-time.
> [...snip...] I see some more
> benefit when changing individual data structures to C++, then switching the
> old C functions into wrappers that make the new C++ behaviour available to
> the
> C side.
In a way, that's just what I'm going for. The only way to make typedef
struct _gncGuid {...} GncGUID; into class GncGUID; is to make sure that
every compilation unit (which uses GUID) knows what "class GncGUID;" means!
At that point, it would be no problem to make GncGUID a class (or a typedef
for a boost class), and even manage it with smart pointers or whatever.
This can be done right alongside (for example) the existing glib date
interface. With this kind of change, we're freed from the requirement that
each code file communicates with the other code files "in C". We are now
free to speak a different language as we desire, as we are able, and,
importantly, at our liesure.
> This means the existing C code can continue to compile in C, and the
> next steps would rather be to open the possibility for new C++ code such as
> unittests and maybe new GUI code in C++ (or python or something similar).
So it sounds like you're talking about introducing new c++ code that uses
the existing C interfaces, which I think is an obvious win. The next win
that I'm striving to see is the existing C code start to use C++ idioms,
data structures, etc.
It would be nice if all that makes sense, but I know better than to even
hope for that :-). Thanks again for asking, and please help me clarify by
asking more questions!
In Christ,
Aaron
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 11, 2014, at 4:52 PM, Christian Stimming wrote: > thanks for investing time in Gnucash and also in its development towards more > future-proof programming technologies. I was a bit puzzled about the benefit > of switching the "normal compiling" from C to C++, just by itself. IMHO, > there > is of course an immediate benefit if the data structures move from plain C > structs to C++ classes, with constructor/destructor and such. If you plan to > do such a transition with any of gnucash's data structures, of course every > code using those will have to be C++. However, just changing this into C++ > doesn't also solve the problem here: The usage of the C structs in the code > is > just that: C structs, with foo_new() and foo_delete() functions and maybe > even > glib's reference counting. To really use C++ classes instead, every single > usage of those old C idioms will have to be replaced by proper C++ > constructs. > IMHO, "just" switching the C compiling to C++ doesn't quite bring you much > gain here. Do you think it helps you much? I have some doubts. I see some > more > benefit when changing individual data structures to C++, then switching the > old C functions into wrappers that make the new C++ behaviour available to > the > C side. This means the existing C code can continue to compile in C, and the > next steps would rather be to open the possibility for new C++ code such as > unittests and maybe new GUI code in C++ (or python or something similar). > IMHO > this would be more benefitial. What do others think? What you say is correct, of course, but I don’t think it’s a complete waste of time to switch over to C++ for most compiles. It has a few advantages I can think of: 1. C++ compilers enforce more strict standards for C code and will catch problems the C compiler may not catch. 2. When some data structure is converted to a C++ class then there’s a good chance that any code that uses it will already be C++ code. 3. Header files won’t have to have as many #ifdef __cplusplus ... endif constructs. These are all pretty minor, but they are useful, I think. There are probably other advantages too. On the other hand it will be a lot of work to get everything to work in C++. I think only the easy part has been done so far. The last time I worked on something like this we did what you suggest, Christian, and it worked well. Whether it’s worth doing this is not obvious to me. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
Hi Aaron, thanks for investing time in Gnucash and also in its development towards more future-proof programming technologies. I was a bit puzzled about the benefit of switching the "normal compiling" from C to C++, just by itself. IMHO, there is of course an immediate benefit if the data structures move from plain C structs to C++ classes, with constructor/destructor and such. If you plan to do such a transition with any of gnucash's data structures, of course every code using those will have to be C++. However, just changing this into C++ doesn't also solve the problem here: The usage of the C structs in the code is just that: C structs, with foo_new() and foo_delete() functions and maybe even glib's reference counting. To really use C++ classes instead, every single usage of those old C idioms will have to be replaced by proper C++ constructs. IMHO, "just" switching the C compiling to C++ doesn't quite bring you much gain here. Do you think it helps you much? I have some doubts. I see some more benefit when changing individual data structures to C++, then switching the old C functions into wrappers that make the new C++ behaviour available to the C side. This means the existing C code can continue to compile in C, and the next steps would rather be to open the possibility for new C++ code such as unittests and maybe new GUI code in C++ (or python or something similar). IMHO this would be more benefitial. What do others think? Regards, Christian Am Mittwoch, 6. August 2014, 13:26:14 schrieb Aaron Laws: > The motivation is to investigate a different strategy for migrating to C++. > I was skeptical that it would work at all, but, through argument, I > couldn't come up with any solid reasons why it couldn't work, so I decided > to give it a go. The strategy is: > Step 1) Get the project to compile as C++. Step 2) add poison to remove non > c++ idioms, etc. Step 3) Make higher level changes. > And the strategy entails that these steps are followed quite strictly. So > far, I don't consider Step 1 complete, because although the project > compiles and links, it's not shippable ... perhaps not even close :-). > Like... nothing works. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Wednesday 06 August 2014 19:15:35 John Ralls wrote:
> On Aug 6, 2014, at 2:16 PM, Geert Janssens wrote:
> > On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote:
> >> I tried to follow the directions at
> >> http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I
> >> couldn't
> >> find a Bugzilla issue encapsulating the Great C++ Refactor. Should
> >> I
> >> create one so there is a place to put patches?
> >>
> >> I learned on IRC that it is generally a goal not to have C++
> >> keywords
> >> in the Gnucash code base, and this patch is along those ends. I
> >> think
> >> I got all the C++11 keywords that would interfere with a C++11
> >> compile. If this is an inappropriate patch to submit, please let me
> >> know. After my signature, you can find the patch prepared using
> >> `git
> >> format-patch` (as specified in
> >> http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the
> >> advice of http://wiki.gnucash.org/wiki/Development_Process ("All
> >> development should target the *master* branch."). Please let me
> >> know
> >> if anything looks amiss (the amount of context, using unified diff
> >> format, perhaps I should be attaching instead of in-line quotation,
> >> etc.). Thanks!
> >>
> >> In Christ,
> >
> > Hi Aaron,
> >
> > Thank you for your patch. I haven't tested it yet but IMO the
> > intention is correct.
> >
> > As for bugzilla: you can create a new bugreport and attach your
> > patch there. Attaching it to a mailing list message risks that it
> > gets lost in the midst of the ongoing discussions. 'git format-
> > patch' is perfectly fine as format.
> >
> > As for the "All development should target the *master* branch", we
> > should change this. That's advice from the svn era. In git bugfixes
> > should target the *maint* branch. New features and enhancements
> > should target *master*.
>
> I clarified
> http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Featu
> res a bit and cleared out all of the old stuff about backports and
> audits. I'm not quite satisfied with it, so I'll let it percolate in
> my head for a day or two and have another go. If someone else has
> some thoughts, by all means dive in.
>
I altered some more parts that still wrongly suggested all bugfix development
should go on
master. But I still welcome more improvements and clarifications.
> Let's not have a generic "Convert GnuCash to C++" bug that will
> accumulate a zillion patches and a zillion comments. That will just
> become a headache. If you (Aaron) would rather attach the patch to a
> bug, make it "Remove C++11/14 Keywords"or something, but I'm
> perfectly happy using Github pull requests for C++ if that's more
> convenient. I don't really see that patch as a bug-fix; it's not a
> problem with maint that it doesn't compile in C++. OTOH, *not*
> applying it to maint will make it harder to merge into master sooner
> than otherwise, so I'm not opposed to it either as long as it passes
> `make distcheck`.
>
Fully agreed. It may be better to apply this one against maint in the hopes it
will result in
simple merges for a while longer. It has to pass make distcheck of course.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Aug 6, 2014, at 2:16 PM, Geert Janssens wrote:
> On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote:
>> I tried to follow the directions at
>> http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't
>> find a Bugzilla issue encapsulating the Great C++ Refactor. Should I
>> create one so there is a place to put patches?
>>
>> I learned on IRC that it is generally a goal not to have C++ keywords
>> in the Gnucash code base, and this patch is along those ends. I think
>> I got all the C++11 keywords that would interfere with a C++11
>> compile. If this is an inappropriate patch to submit, please let me
>> know. After my signature, you can find the patch prepared using `git
>> format-patch` (as specified in
>> http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the
>> advice of http://wiki.gnucash.org/wiki/Development_Process ("All
>> development should target the *master* branch."). Please let me know
>> if anything looks amiss (the amount of context, using unified diff
>> format, perhaps I should be attaching instead of in-line quotation,
>> etc.). Thanks!
>>
>> In Christ,
>
>
> Hi Aaron,
>
> Thank you for your patch. I haven't tested it yet but IMO the intention is
> correct.
>
> As for bugzilla: you can create a new bugreport and attach your patch there.
> Attaching it to a
> mailing list message risks that it gets lost in the midst of the ongoing
> discussions. 'git format-
> patch' is perfectly fine as format.
>
> As for the "All development should target the *master* branch", we should
> change this.
> That's advice from the svn era. In git bugfixes should target the *maint*
> branch. New
> features and enhancements should target *master*.
I clarified
http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Features a bit
and cleared out all of the old stuff about backports and audits. I'm not quite
satisfied with it, so I'll let it percolate in my head for a day or two and
have another go. If someone else has some thoughts, by all means dive in.
Let's not have a generic "Convert GnuCash to C++" bug that will accumulate a
zillion patches and a zillion comments. That will just become a headache. If
you (Aaron) would rather attach the patch to a bug, make it "Remove C++11/14
Keywords"or something, but I'm perfectly happy using Github pull requests for
C++ if that's more convenient. I don't really see that patch as a bug-fix; it's
not a problem with maint that it doesn't compile in C++. OTOH, *not* applying
it to maint will make it harder to merge into master sooner than otherwise, so
I'm not opposed to it either as long as it passes `make distcheck`.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote:
> I tried to follow the directions at
> http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't
> find a Bugzilla issue encapsulating the Great C++ Refactor. Should I
> create one so there is a place to put patches?
>
> I learned on IRC that it is generally a goal not to have C++ keywords
> in the Gnucash code base, and this patch is along those ends. I think
> I got all the C++11 keywords that would interfere with a C++11
> compile. If this is an inappropriate patch to submit, please let me
> know. After my signature, you can find the patch prepared using `git
> format-patch` (as specified in
> http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed the
> advice of http://wiki.gnucash.org/wiki/Development_Process ("All
> development should target the *master* branch."). Please let me know
> if anything looks amiss (the amount of context, using unified diff
> format, perhaps I should be attaching instead of in-line quotation,
> etc.). Thanks!
>
> In Christ,
Hi Aaron,
Thank you for your patch. I haven't tested it yet but IMO the intention is
correct.
As for bugzilla: you can create a new bugreport and attach your patch there.
Attaching it to a
mailing list message risks that it gets lost in the midst of the ongoing
discussions. 'git format-
patch' is perfectly fine as format.
As for the "All development should target the *master* branch", we should
change this.
That's advice from the svn era. In git bugfixes should target the *maint*
branch. New
features and enhancements should target *master*.
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash c++
I tried to follow the directions at
http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a
Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so
there is a place to put patches?
I learned on IRC that it is generally a goal not to have C++ keywords in
the Gnucash code base, and this patch is along those ends. I think I got
all the C++11 keywords that would interfere with a C++11 compile. If this
is an inappropriate patch to submit, please let me know. After my
signature, you can find the patch prepared using `git format-patch` (as
specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed
the advice of http://wiki.gnucash.org/wiki/Development_Process ("All
development should target the *master* branch."). Please let me know if
anything looks amiss (the amount of context, using unified diff format,
perhaps I should be attaching instead of in-line quotation, etc.). Thanks!
In Christ,
Aaron Laws
>From c58457879496a26031e7a412deb429c9ef572fb9 Mon Sep 17 00:00:00 2001
From: lmat
Date: Wed, 23 Jul 2014 17:47:02 -0400
Subject: [PATCH] Replacing c++ reserved keywords with clean alternatives
---
src/app-utils/gnc-component-manager.h | 2 +-
src/app-utils/test/test-option-util.c | 2 +-
src/engine/gnc-commodity.c | 152
src/engine/test-core/test-engine-stuff.c| 6 +-
src/engine/test/utest-Account.c | 22 ++--
src/engine/test/utest-Transaction.c | 62 +-
src/gnome-utils/assistant-xml-encoding.c| 10 +-
src/gnome-utils/dialog-commodity.c | 96 +++
src/gnome-utils/dialog-commodity.h | 4 +-
src/gnome-utils/dialog-preferences.c| 4 +-
src/gnome-utils/dialog-reset-warnings.c | 4 +-
src/gnome-utils/dialog-totd.c | 14 +--
src/gnome-utils/gnc-amount-edit.c | 2 +-
src/gnome-utils/gnc-cell-renderer-date.c| 12 +-
src/gnome-utils/gnc-cell-renderer-popup-entry.c | 2 +-
src/gnome-utils/gnc-cell-renderer-popup.c | 16 +--
src/gnome-utils/gnc-combott.c | 14 +--
src/gnome-utils/gnc-currency-edit.c | 2 +-
src/gnome-utils/gnc-date-delta.c| 2 +-
src/gnome-utils/gnc-date-format.c | 2 +-
src/gnome-utils/gnc-dense-cal.c | 2 +-
src/gnome-utils/gnc-general-select.c| 2 +-
src/gnome-utils/gnc-period-select.c | 2 +-
src/gnome-utils/gnc-plugin.c| 32 ++---
src/gnome-utils/gnc-tree-model-commodity.c | 92 +++---
src/gnome-utils/gnc-tree-model-commodity.h | 2 +-
src/gnome-utils/gnc-tree-model-price.c | 102
src/gnome-utils/gnc-tree-model-price.h | 2 +-
src/gnome-utils/gnc-tree-view-commodity.c | 6 +-
src/gnome-utils/gnc-tree-view-price.c | 6 +-
src/gnome-utils/search-param.c | 2 +-
31 files changed, 340 insertions(+), 340 deletions(-)
diff --git a/src/app-utils/gnc-component-manager.h
b/src/app-utils/gnc-component-manager.h
index 7de280f..45fc187 100644
--- a/src/app-utils/gnc-component-manager.h
+++ b/src/app-utils/gnc-component-manager.h
@@ -104,7 +104,7 @@ typedef gboolean (*GNCComponentFindHandler) (gpointer
find_data,
*
* Return: TRUE if the callback did something
*/
-typedef gboolean (*GNCComponentHandler) (const char *class,
+typedef gboolean (*GNCComponentHandler) (const char *component_class,
gint component_id,
gpointer user_data,
gpointer iter_data);
diff --git a/src/app-utils/test/test-option-util.c
b/src/app-utils/test/test-option-util.c
index dc99f32..8fef4c0 100644
--- a/src/app-utils/test/test-option-util.c
+++ b/src/app-utils/test/test-option-util.c
@@ -41,7 +41,7 @@ typedef struct
/* Expose a mostly-private QofInstance function to load options into
* the Book.
*/
-extern KvpFrame *qof_instance_get_slots (QofInstance*);
+extern KvpFrame *qof_instance_get_slots (const QofInstance*);
static void
setup (Fixture *fixture, gconstpointer pData)
diff --git a/src/engine/gnc-commodity.c b/src/engine/gnc-commodity.c
index d5f6eb0..554cbf6 100644
--- a/src/engine/gnc-commodity.c
+++ b/src/engine/gnc-commodity.c
@@ -68,7 +68,7 @@ struct gnc_commodity_s
typedef struct CommodityPrivate
{
-gnc_commodity_namespace *namespace;
+gnc_commodity_namespace *nmspace;
char* fullname;
char* mnemonic;
@@ -592,7 +592,7 @@ reset_unique_name(CommodityPrivate *priv)
gnc_commodity_namespace *ns;
g_free(priv->unique_name);
-ns = priv->namespace;
+ns = priv->nmspace;
priv->unique_name = g_strdup_printf("%s::%s",
ns ? ns->name : "",
priv->mnemonic ? priv->mnemonic :
"");
@@ -608,7 +608,7 @@ gnc_commodity_init(gnc_commodity* com)
priv = GET
Re: Gnucash c++
On Tue, Aug 5, 2014 at 2:04 PM, John Ralls wrote:
> Aaron,
>
> I've pulled and begun testing your guidcpp branch. It looks good, and I
> expect to merge it to master today or Thursday.
>
Excellent! :-)
> What is the motivation for compiling everything as C++ if it's still
> really C and you have to wrap everything in extern "C" {} to get it to
> link, especially in gnome and register directories, which can't be
> converted to C++?
>
The only extern "C"s in c++-debug branch are for SCM and module entry
points, and only the latter is for more than one declaration. That comes up
to 13 functions that are declared extern "C" ?
The motivation is to investigate a different strategy for migrating to C++.
I was skeptical that it would work at all, but, through argument, I
couldn't come up with any solid reasons why it couldn't work, so I decided
to give it a go. The strategy is:
Step 1) Get the project to compile as C++. Step 2) add poison to remove non
c++ idioms, etc. Step 3) Make higher level changes.
And the strategy entails that these steps are followed quite strictly. So
far, I don't consider Step 1 complete, because although the project
compiles and links, it's not shippable ... perhaps not even close :-).
Like... nothing works.
To be clear, I'm just answering your question, not actually proposing this
strategy. If it goes well, it is naturally up to the development team to
adopt such a strategy.
Thanks for the response! I kept my response brief, but anyone feel free to
ask more questions. I spent the last three days or so catching up on
gnucash mailing list items (you've perhaps seen my replies, etc.), and now
I can get back to looking at the code!
In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 5, 2014, at 8:05 AM, Aaron Laws wrote:
> I've been doing some work on gnucash with relation to c++. I'm "LMAT" on
> IRC. I got the project to compile, link, and run as c++ (no .c files I'm
> pretty sure). I think it doesn't load any backends, and there are other
> problems. I had to solve a problem with the module loading because c++
> "mangles" names (if you don't know what this is, it's much better than it
> sounds!). I added extern "C" to those entry points so that they could be
> found (in their unmangled form). I'm assuming the backend loading is
> similar, but having taken a look, I don't think it works in the same way.
>
> https://github.com/limitedAtonement/gnucash/tree/c++-debug is my "debug"
> tree. Don't count on it for anything, I may be doing "force-pushing" now
> and then. Currently, this is the version that "runs" if you want to take a
> look. (I think I'll put a tag here soon.)
>
> https://github.com/limitedAtonement/gnucash/tree/c++-work is where I plan
> on putting something that may e.g. actually be pullable into gnucash. For
> instance, the first commits I plan to put here are updates to names to
> remove c++ keywords, and changing c signatures to be c++ compatible (none
> of this func (one, two) char one; char * two; {} stuff).
>
> And, https://github.com/limitedAtonement/gnucash/tree/guidcpp is the boost
> guid branch on which I currently have issued a pull request.
>
> I've been learning a lot about the code base by doing this work, and I'm
> sure it would be *much* faster if I knew more about how certain things were
> configured. Let me know what you think if you get a chance to take a look
> around!
Aaron,
I've pulled and begun testing your guidcpp branch. It looks good, and I expect
to merge it to master today or Thursday.
What is the motivation for compiling everything as C++ if it's still really C
and you have to wrap everything in extern "C" {} to get it to link, especially
in gnome and register directories, which can't be converted to C++?
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash c++
I've been doing some work on gnucash with relation to c++. I'm "LMAT" on
IRC. I got the project to compile, link, and run as c++ (no .c files I'm
pretty sure). I think it doesn't load any backends, and there are other
problems. I had to solve a problem with the module loading because c++
"mangles" names (if you don't know what this is, it's much better than it
sounds!). I added extern "C" to those entry points so that they could be
found (in their unmangled form). I'm assuming the backend loading is
similar, but having taken a look, I don't think it works in the same way.
https://github.com/limitedAtonement/gnucash/tree/c++-debug is my "debug"
tree. Don't count on it for anything, I may be doing "force-pushing" now
and then. Currently, this is the version that "runs" if you want to take a
look. (I think I'll put a tag here soon.)
https://github.com/limitedAtonement/gnucash/tree/c++-work is where I plan
on putting something that may e.g. actually be pullable into gnucash. For
instance, the first commits I plan to put here are updates to names to
remove c++ keywords, and changing c signatures to be c++ compatible (none
of this func (one, two) char one; char * two; {} stuff).
And, https://github.com/limitedAtonement/gnucash/tree/guidcpp is the boost
guid branch on which I currently have issued a pull request.
I've been learning a lot about the code base by doing this work, and I'm
sure it would be *much* faster if I knew more about how certain things were
configured. Let me know what you think if you get a chance to take a look
around!
In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
