On Fri, Nov 21, 2014 at 3:51 AM, Aaron Laws <dartm...@gmail.com> wrote:
> On Thu, Nov 20, 2014 at 9:58 AM, Chenxiong Qi <qcxh...@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@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > -- Regards, Chenxiong Qi _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
