Re: [hatari-devel] WinUAE emulation bugs in 2013 / use of C++ compiler for Hatari build?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


On 05/02/2013 22:34, Eero Tamminen wrote:
Hi,

On tiistai 05 helmikuu 2013, Thomas Huth wrote:
I remember some people trying to compile the Hatari C code with a
C++-only compiler a couple of years ago, and that did not work very
well or at all. So I really would like to avoid that if possible.

That was with with (nowadays obsolete) Visual Studio 6 from 90's,
but latest C++ compilers actually support C99.  And C++ vs C wasn't
the only issue with VS 6, there were also Windows API related ones.
:-)

C++ compilers are stricter, so they might also find some new bugs
in the code.  The main ugly thing is malloc return values, C++ likes
things to be nicely typed and doesn't like pointers to be assigned
to pointers of another type, so void* return values need explicit
casts.  Otherwise C++ compiler should be fine I think.

But if there are no real benefits for WinUAE porting, then it
doesn't make sense. :-/


	- Eero

Hello

I agree with Thomas, I don't think that using C++ in the cpu core for Hatari will have immediate benefit. The main issue is more about spotting differences between consecutive WinUAE releases and integrating them in the Hatari's version. Even if we were using C++ in Hatari for this part, there're several Atari's specific codes that would still require "manual" merging of WinUAE's code into Hatari.

As for the UI part in C++, all Hatari's code is in C. So using a C++ cpu core would still require that the UI can interact with the rest of the code in C. As long as some parts of Hatari are in C, keeping the cpu core in C and merging WinUAE's code seems easier to me (also, I don't consider WinUAE's core to be C++ in the object sense of the term, it's more about using try/catch to avoid C's goto/longjmp ; I'd rather have a WinUAE's core written in portable C by Toni Wilen :) ).

Nicolas






Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/