Compile test-core in C++

[John Ralls]

> On Nov 22, 2014, at 7:02 AM, Chenxiong Qi <qcxhome at gmail.com> wrote:
> 
> 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.

Qi,

You can protect C++ code from being seen by the C compiler by wrapping it in #ifdef __cplusplus ... #endif.

IIRC the only instance of a collection is on QofBook, but it's accessed widely outside of QOF by getting a GList* and operating on it directly. You'll need to verify that, and if I'm right provide a C wrapper to your new QofCollection class and replace all of that GList code with calls to your wrapper functions.

Regards,
John Ralls