MAMEWorld Forums - EmuChat - Re: C versus C++ with regard to MAME

> > So let me get this straight. The Mamedevs changed the core of MAME from C to C++
> just
> > to make it easier to read?
>
> And also to make it easier to write, maintain, and share. Subclassing a device was a
> few dozen lines of switch statements with impenetrable macros before, and there were
> arcane rules where a CPU couldn't also do audio I/O, even though many games use DSPs
> that do just that. Now it's simpler, cleaner, more flexible, and everything works
> exactly like your CS professor (hopefully) taught you.

I have to agree that C++ is a better choice than C for large projects built using modern tools. In large projects you need exactly the protections that R. Belmont talks about here; while individual programmers may be disciplined and smart enough to write maintainable code and to not break contracts where it is convenient, groups of programmers for some reason cannot. I've never worked in any group of any significant size where the value of putting handcuffs on everyone didn't outweigh the disadvantages thereof. It sucks to be a good, disciplined programmer (or at least to think that you are one) and to be subject to what seem like unnecessary restrictions on your freedom to do whatever you want in the code; but allowing everyone free reign to do whatever they want just never works out. For this reason, locking down implementation details using C++ features is valuable. In addition, the extra expressivity of interface that C++ provides over C can be of great value as R. Belmont has pointed out, if used correctly.

C++ is way, way more than enough rope to hang yourself with, and that's why it takes a strong set of core developers to set the rules and conventions for how C++ will be used in any particular project. To be honest I can't speak about MAME source personally because I am not as familiar with the device driver architecture as I would like to be, but I think we ought to take R. Belmont's word for it.

Also can I just say that I detest the idea of sticking to lowest common denominator tools. C98? Are you serious? Everyone should be restricted to a language definition that is 13 years old because some retarded tool chains still haven't implemented C99 properly? This is absolutely ridiculous. Every developer should demand conformance to all language specs that are 5 years old or older. Tool chain maintainers should not be let off the hook this easily; any tool chain that can't be bothered to support language definitions from the last 5 years doesn't deserve to be used at all, in my estimation.