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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

I was reading WinUAE forum threads and noticed few new fixed
bugs mentioned against the latest version.

LINK instruction bug (comment #8):
	http://eab.abime.net/showthread.php?t=67210

MMU TBL flush in user mode (comment #164):
	http://eab.abime.net/showthread.php?t=46934&page=5
(page 4 mentions even more bugs fixed)


As WinUAE emulation seems still a fast moving target,
I was wondering would it make more sense to build
WinUAE CPU core version of Hatari with C++ compiler,
and just the old UAE core version with plain C-compiler?

I would assume that to ease the porting effort, hopefully
significantly [1], and it would make potential later Qt UI
integration easier as Qt is also C++.

[1] Exception handling and potential future C++ features used
	in WinUAE wouldn't need to be redone.  Issues that would
	need to be handled would then be "just" Windows & Amiga
	specific features, and adding Atari stuff.


Building one version of Hatari with C++ and another with C-compiler,
would require CMakefile updates and hopefully only trivial changes
to the current Hatari C code.  Hopefully with the new C++ standard
version that finally added C99 compatibility, there are less of those.

(I recently made one of my own programs compatible to both C++ and
C-compiler when trying building Qt UI for it, and it was rather
painless when I built the whole binary with same compiler.)



	- Eero

PS. I'm not sure what to do about other C++ projects from which Hatari
imports code.  We've changed Aranym Videl & DSP code already into
C code, and Aranym development is really slow, so I don't see
currently there any benefit in C++ use.  That would make also old
UAE CPU core to require C++ compiler which could be an issue on some
smaller platforms for which Hatari is / could be built (like MiNT).