Compile test-core in C++

Aaron Laws dartme18 at gmail.com
Thu Nov 20 14:51:56 EST 2014


On Thu, Nov 20, 2014 at 9:58 AM, Chenxiong Qi <qcxhome at gmail.com> wrote:

> Is it acceptable that I rename the new class to
> another name temporarily, such as QofCollectionClass, and keep the new
> class implementation and original one's existing simultaneously. I
> know this looks strange, but the change only affects in src/libqof/qof
>

That doesn't sound acceptable, but I don't see the situation. Why would you
do that? Do take a look at the kvp-frame stuff? The cpp declaration is in
kvp_frame.hpp, and the C interface is in kvp_frame.h. For instance, take a
look at the .cpp file at kvp_frame_copy. This function used to have all the
logic for copying all the contents of the provided KvpFrame *, but now, a
new struct, KvpFrameImpl with a copy constructor is used from the C
implementation. This means that C code can use this copy constructor
through this thin interface, and cpp code can directly include the .hpp and
create a copy more directly.

As recently as commit 8a7f426, there was struct _KvpFrame { GHashTable *
hash; };. That was removed and struct KvpFrameImpl was introduced in commit
076f1fb25.

Trying to keep them both around at the same time doesn't sound like a good
idea. Which one will be pointed to by qof_collection_new? What happens if
the wrong one is sent to qof_collection_destroy?

I am interested in finding out why you would want to have both existing at
the same time if you feel up to explaining :-).

I'm heading out of town, so I might not be terribly responsive for the next
week and an half.



> Regards,
> Chenxiong Qi
> _______________________________________________
> 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