> My point was that a different language (C++ in particular) might make
> it easier (and less error prone) to do many of the things that MAME does
> manually (tables of functions, structures with manual initialization
> routines/huge explicit initializers, etc). If you don't believe me, then I
> dare you to add a field to the GameDriver structure - you'd have to manually
> update hundreds of files with explicit structure initialization.
Well, I'd blame that on the implementation - not on the language. As
someone who has authored a multi-game emulator, I do know there are better
methods of organization. In Retrocade, to "plug in" a game to the main
architecture, you modify 1 file. One section is a structure that contains
platform information (as in Atari DVG, Atari System 1, etc..) and another
section points to a game's list of ROMs and to that platform (hence the
name 'platform extension'), so you can have several ROMsets point to the
same platform.
And yes, everything should be in a single, easy to manage place, not
spread out to 10 different files. I bumped my head on this in the VERY
early days of Retrocade development and rearchitechted to avoid that
problem. I looked at C++, but found that it offered me nothing. I'm doing
some of the same functions as C++ would do (such as
constructors/destructors), but all I'd be doing is just using different
syntax. It wouldn't gain me anything.
> >Sorry, but I've seen SOOOOO much C++ abuse in my professional career. I'm
> >not down on C++ - it has its place.
> Yep, gotta agree there. My last job was porting a huge hunk of legacy
> code to the PSX (The X-Files Game). I saw it all (virtual functions in template
> classes, mammoth do-it-all-in-one-class APIs - a 2000 line implementation of
> a *Rectangle* class!, overloaded copy constructors with bad side effects) - to
> be fair, I also saw some pretty good design. But giving some people a C++
> compiler is like letting a baby play with a gun.
Hence my .sig. ;-) Yeah, we had a guy that had a bit class which was
encapsulated by a byte class encapsulated by a dword class encapsulated
by a register class encapsulated by a operation class encapsulated by a
chip class encapsulated by a chipset class. I shit you not. This was to
write a single bit (or group of bits) in a chipset. Of course, what this
mental giant didn't figure out is that performance meant everything in
being able to generate tight traffic (chipset validation was the task) and
his tests never found any bugs. Talking about someone not knowing when to
(or not to) apply something!
> That said, there's a certain beauty to a properly implemented OO
> program. You can achieve it with any language (including C, which MAME does),
> but with some languages you just don't have to work quite so hard at it.
Hm.... well, I'm not sure I agree with you on the C/C++ thing. C++ Hides a
few things and makes things like operator overloading and automatic
variable assignment really handy and cleans up the formal parameters, but
as a whole, most of C++ is just done "differently". C Certainly has its
shortcomings.
-->Neil
-------------------------------------------------------------------------------
Neil Bradley Synthcom home : http://www.synthcom.com
Synthcom Systems, Inc. C++ - Where you can make your privates public!
ICQ # 29402898 Friends don't let newbie programmer friends do C++
Received on Mon Oct 4 14:50:31 1999
This archive was generated by hypermail 2.1.8 : Fri Aug 01 2003 - 00:32:44 EDT