Compile test-core in C++
dartme18 at gmail.com
Tue Nov 18 11:53:28 EST 2014
On Tue, Nov 18, 2014 at 10:10 AM, Chenxiong Qi <qcxhome at gmail.com> wrote:
> I've converted QofCollection to a C++ class. A side-effect is that I
> have to make src/test-core be able to compile in C++.
Although QofCollection will be a C++ class, you should be retaining the C
interface! The existing tests (src/libqof/qof/test/*.c) should be working
with the C interface, and you should write up new gtests
(src/libqof/qof/test/*.cpp) to test the C++ object that you created.
This has been done on the master branch in kvp-value. See kvp-value.cpp,
kvp-value.hpp, test/test-kvp-value.cpp, and the C interface in kvp_frame.h,
and implementations of the C interface in kvp_frame.cpp.
I hope that makes sense?
I'm an absolute
> newbie to autotools, still not get a workable solution so far after
> doing some research on this. Could you give some guide how to
> accomplish this conversion. Conversion only involves the compiler
> changed to a C++ compiler, and the file's extension changed to cpp if
> necessary. Nothing else if src/test-core/* are compiled in C++ without
There are more subtle errors that can occur when changing the compiler and
extension of code files. Since c++ introduces the idea of function
overloading, it can be that an external entry point of a library will have
an unexpected name. Our build process creates a good deal of "intermediate"
libraries and actually ships "modules" as dynamic libraries. If those
dynamic libraries are compiled in c++, the function name can be mangled
beyond C recognition. So, although compilation will succeed, and perhaps
even launching the application will succeed, when that function is called
from C (but can't be found because its name has been mangled), an error can
> BTW, besides the conversion to C++ class, I will write unit tests to
> ensure new QofCollection class works as expected.
> Chenxiong Qi
Thanks and good luck!
More information about the gnucash-devel