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