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 jra...@ceridwen.us wrote: On Aug 13, 2014, at 3:42 PM, Gour g...@atmarama.net wrote: On Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins warl...@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@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 Wed, 13 Aug 2014 17:20:51 -0700 John Ralls jra...@ceridwen.us 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++
On Thursday 14 August 2014 10:04:55 Gour wrote: On Wed, 13 Aug 2014 17:20:51 -0700 John Ralls jra...@ceridwen.us 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 Tue, 5 Aug 2014 11:04:00 -0700
John Ralls jra...@ceridwen.us 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++
Gour g...@atmarama.net writes:
On Tue, 5 Aug 2014 11:04:00 -0700
John Ralls jra...@ceridwen.us 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 your
favorite language 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 Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins warl...@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 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++
On Aug 13, 2014, at 3:42 PM, Gour g...@atmarama.net wrote: On Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins warl...@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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 11, 2014, at 4:52 PM, Christian Stimming christ...@cstimming.de 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++
On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming christ...@cstimming.de
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 12, 2014, at 7:22 AM, Aaron Laws dartm...@gmail.com wrote:
On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming christ...@cstimming.de
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 everything C++ linkage is a
good use of time because most of the work will be
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 janssens-ge...@telenet.be 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 Keywordsor 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 Tue, Aug 5, 2014 at 2:04 PM, John Ralls jra...@ceridwen.us 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 Cs 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 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
Re: gnucash c++
On Aug 6, 2014, at 2:16 PM, Geert Janssens janssens-ge...@telenet.be 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 Keywordsor 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 Aug 5, 2014, at 8:05 AM, Aaron Laws dartm...@gmail.com 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
