C++ tests (1/2)

Patrik Stridvall ps at leissner.se
Fri Nov 15 06:32:44 CST 2002

> Patrik Stridvall <ps at leissner.se> writes:
> > Then of course we want normal C++ tests as well. Many (most?)
> > applications likely to be ported by Winelib are C++ application
> > so we really should have tests for possible C++ problems.
> The Wine tests are supposed to test the implementation, 

That is their primary use, yes. However I see no need to
limit it to that.

> not the
> compilation. 

If some code interfaces incorrectly with Winelib, because of
C++ problems or whatever, it doesn't really matter if the
implementation is correct, does it? The result will still
be wrong.

Interface problems are inherently compilation specific.
So yes, I really think we should have some tests for them.

Sure I don't have much hope of catching that many bugs
but then, it givens at least some confidence that the
interface is reasonable bug free.

> And building C++ apps with Winelib is a complex issue
> that you won't be able to test in the Wine framework, except with
> carefully tweaked code that won't match what real apps do anyway.
> Frankly, the likelihood of catching a real problem that way is much
> too small to justify the complexity of a whole new test environment.

What complexity? 

The patch is very small and half of it concerns the
.c.cxx hack to compile tests with both with C and C++, that
I can remove if you wish. Except for the file extension choping,
it is possible to do with only changing "Makefile:s".

Anyway if you don't accept the somewhat abstract argument above,
here are some more concrete ones:

How are we supposed to test specific C++ features in the Winelib
header. Sure we doesn't have many yet, primarily because only C++
Winelib application needs then and we don't have any in the tree
so we don't need that ourselves. But some (many?) C++ application
ports from Windows certainly does.

Sure we can add them to the Wine tree without any tests but if they are
neither used internal nor tested they are very likely to be wrong.

And yes, there are quite a lot of C++ only feature in the Microsoft SDK
that are not in Wine yet.

A FEW examples of C++ only features:
1. The D3D math classes (vector, matrices, quaternions, colors etc) in
   d3dvec.inl d3dx8math.inl d3dxmath.inl
2. The GDI+ API classes in gdiplus*.h
3. The DAO API classes in dbdao.h
4. STL compatible classes for accessing SAFEARRAY's in t_safevector.h

Then of course we have COM...
Sure we can test it in C to a large extent, but will it be enough?

So my questions to you:
1. Should we support the C++ only features meantion above?
2. If yes, should we just include it in the tree without tests
   and just hope it works or should we have C++ tests for them?

> We just got rid of the Perl framework, please let's not add a new one.

I see no relevent comparsion between them:
1. C++ is actually used by the Microsoft SDK. Perl is not. 
2. The Perl framework was big and required generated modules. 
   The C++ framework is very small and uses the Wine header files
   as they are (or should be in order to be Microsoft compatiable)

More information about the wine-devel mailing list