Compile test-core in C++

Chenxiong Qi qcxhome at gmail.com
Sat Nov 22 10:02:13 EST 2014


On Fri, Nov 21, 2014 at 3:51 AM, Aaron Laws <dartme18 at gmail.com> wrote:
> 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?

Hi,

In my implementation, do not share qof_collection_* interfaces.
Original C interfaces are not changed at all, no break to any features
calling these C interfaces. The new C++ class is standalone totally.
Initialization, destroy and member function calls only go to the class
QofCollection.

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

Sorry for confusion, pls let me try to explain again to make it more clear.

I converted QofCollection_s to a C++ class named QofCollection placed
in same header file src/libqof/qof/qofid.h, and the original
QofCollection_s is replaced with this new class. Module src/libqof/qof
is compiled successfully, but failed to compile src/test-core due to C
compiler is the one used to compile, and
src/test-core/unittest-support.h includes qof.h, then *includes
qofid.h*. This is why I considered to compile src/unit-core to solve
the problem. After guidance in previous mails from both of you, I
realizd that's not a good idea.

Then, by seeing KvpFrameImpl, I was thinking to keep QofCollection's C
and C++ implementation existing at the same time. Because

1. reach the very first step of the goal to implement a C++ version of
QofCollection
2. new C++ class is just used in the scope of src/libqof/qof, whereas
the original C version can still be used by the features outside of
src/libqof/qof. In this case, my problem mentioned above disappears.
3. unit tests and all test works can be done within src/libqof/qof
only. No any side-effects to outside.
4. When migrate to C++ compiler to build the whole GnuCash
application, it's the time to make features outside of src/libqof/qof
make use of QofCollection class.

Thanks for both of your guidance and great patience. :)

>
> 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
>
>



-- 
Regards,
Chenxiong Qi


More information about the gnucash-devel mailing list