On Sat, Nov 22, 2014 at 10:02 AM, Chenxiong Qi <qcxh...@gmail.com> wrote:
> I converted QofCollection_s to a C++ class named QofCollection placed > in same header file src/libqof/qof/qofid.h, I would advise against putting the class declaration into this file. It can certainly be done by following Mr. Rall's suggestion of #ifdef __cplusplus, but it seems cleaner to me to have a separate .hpp file for several reasons. > 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. > Right. The C tests (using the gtest framework) shouldn't see any C++. Actually, the C tests shouldn't change at all (ideally) in response to your work. It sounds like your understanding is correct. > > 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. > Exactly. You're on the path to victory :-) In Christ, Aaron Laws _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel