Patrik Stridvall ps@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)
Patrik Stridvall ps@leissner.se writes:
So my questions to you:
- Should we support the C++ only features meantion above?
- 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?
When someone has an app that requires these features they can implement them, and test them by building their app. Or we can implement them and write a small test program to test them once. No need to build a new test environment for such uncommon features.
I see no relevent comparsion between them:
- C++ is actually used by the Microsoft SDK. Perl is not.
- 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)
The issue is not really the size of the framework, it's the extra dependencies. It would require everybody who wants to run tests to have a working, compatible C++ installation; given the various levels of brokenness of existing g++ versions that's far from trivial.
-
Alexandre Julliard -
Patrik Stridvall