RE: C++ tests (1/2)

[Patrik Stridvall]

> Patrik Stridvall  writes:
> > In the case of generated.c it is very useful since
> > alignment and that sort of thing might pontially be different
> > with C++. For other normal tests I'm not sure how useful
> > it is to tests with C++ as well. It can't hurt of course
> > but then it takes twice as long to run...
>
> I don't see what this buys us at all. If the C++ compiler generates
> different structure layouts from the same headers then it is broken,
> but that's not really a Wine problem.

First of all it was just an example what it could be used for.
It is the only thing that winapi_test (tests/generated.c) currently
tests for. However, there will be more tests in the future testing
for other things that might or might not be C++ dependent.

Secondly the test makes certain that you don't have a
#ifdef __cplusplus affecting some structure by mistake.

And yes, there are structure like that MONITORINFO that does.
And no, don't look in the Wine source, it doesn't implement
it yet.

Then we could have #ifdef __cplusplus that have
an "missing" #endif that matches some other #endif
in the wrong place or something.

We also have the COM interfaces that are different in C++...

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.

But it you don't like the .c.cxx hack I could generate C++
tests to a generated_cxx.cxx or whatever then we don't need
that part of the patch. It is a little ugly I admit. :-)

C++ tests (1/2)

[Alexandre Julliard]

Patrik Stridvall  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, not the
compilation. 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.
We just got rid of the Perl framework, please let's not add a new one.