|
C versus C++ with regard to MAME
#258995 - 07/04/11 07:09 PM
|
|
|
A discussion on another forum about MAME brought this comment from someone:
"C++ is a truly horrible incoherent bloated mess of a language.
If you want maximum portability and readability combined with speed then I still think it's best to stick with pure C, making sure your code conforms rigidly to the C89 standard. The C99 standard (which isn't properly supported by most compilers) introduced a lot of pointless bloat without adding significantly to the power of the language."
What does this mean, in technical terms?
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259011 - 07/04/11 10:16 PM
|
|
|
> What does this mean, in technical terms?
Those aren't the droids you are searching for.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259013 - 07/04/11 10:54 PM
|
|
|
> A discussion on another forum about MAME brought this comment from someone:
>
> "C++ is a truly horrible incoherent bloated mess of a language.
>
> If you want maximum portability and readability combined with speed then I still
> think it's best to stick with pure C, making sure your code conforms rigidly to the
> C89 standard. The C99 standard (which isn't properly supported by most compilers)
> introduced a lot of pointless bloat without adding significantly to the power of the
> language."
>
>
>
I agree 100%
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: CrapBoardSoftware]
#259015 - 07/04/11 11:02 PM
|
|
|
|
|
Tafoid |
|
I keep on testing.. testing.. testing... into the future!
|
|
|
|
|
Reged: 04/19/06
|
|
Posts: 3135
|
|
Loc: USA
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259016 - 07/04/11 11:09 PM
|
|
|
> > A discussion on another forum about MAME brought this comment from someone:
> >
> > "C++ is a truly horrible incoherent bloated mess of a language.
> >
> > If you want maximum portability and readability combined with speed then I still
> > think it's best to stick with pure C, making sure your code conforms rigidly to the
> > C89 standard. The C99 standard (which isn't properly supported by most compilers)
> > introduced a lot of pointless bloat without adding significantly to the power of
> the
> > language."
> >
> >
> >
>
> I agree 100%
If one is to understand the great mystery, one must study all its aspects, not just the dogmatic, narrow view of regular C programmers.
|
|
|
| italie |
|
MAME owes italie many thank yous, hah
|
|
|
|
|
Reged: 09/20/03
|
|
Posts: 15246
|
|
Loc: BoomTown
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259023 - 07/04/11 11:57 PM
|
|
|
> A discussion on another forum about MAME brought this comment from someone:
>
> "C++ is a truly horrible incoherent bloated mess of a language.
>
> If you want maximum portability and readability combined with speed then I still
> think it's best to stick with pure C, making sure your code conforms rigidly to the
> C89 standard. The C99 standard (which isn't properly supported by most compilers)
> introduced a lot of pointless bloat without adding significantly to the power of the
> language."
>
>
> What does this mean, in technical terms?
If one codes properly one does not need worry about this. Compendium absolutum
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259037 - 07/05/11 06:05 AM
|
|
|
> What does this mean, in technical terms?
It's dogma uber alles. I've actually written CPU, sound, and general device cores under each of MAME's major stages of development and it has *never* been cleaner, easier, or more elegant than it is now. Abolishing fixed device types ("CPU", "sound", "video", "general") in favor of being able to inherit the precise fine-grained capabilities you need from a set of base classes is something like a fucking revolution, and makes it far, far easier to write and maintain devices. (It also makes them easier to use outside of MAME because you know exactly what the interface contract is and everything else is private).
Elsewhere on that thread someone complains that most of the devices are still old-style C with a wrapper class around them. True. But converting them is exactly the sort of no-experience-necessary work that someone who knows some C++ and wants to break into emulation could really crank on with minimal guidance from the existing devs. I converted the Namco C352 for 0.143 in about an hour start to finish, for example, and I'd never done that type of conversion before.
Oh, and if he's getting the vapors over C99, he'd probably pop a vein looking at bsnes - byuu's fully embraced C++0x including lambda expressions, and it's made bsnes actually a few ticks faster in addition to easier to maintain.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: Tafoid]
#259044 - 07/05/11 10:17 AM
|
|
|
> the dogmatic, narrow view of regular C programmers.
There are benefits to C++ even for the casual programmer or for the new student to the language. But I cannot see any benefits for the professional or the serious student.
I studied C in college and found it difficult at first, then as I progressed, the language taught me how to be more methodical, focused and structured in my programming tasks.
Roll on five years later when I went back to college and studied C++ and was baffled yet again on it's use. Luckily I was able resort to standard C to finish the course, due to the constraints imposed by C++ at the time (i.e. poor exception handling). Even my lecturers advised resorting to C to resolve the problems experienced with C++.
Now exploring the OOP part of college with C#, it amazes me why coders are so lazy today, true we are all standing on the shoulders of giants but lazy giants at that.
Granted I am not a Jedi C coder by any wide margin, but it is clear where the bloat comes from. If not the coder but from the language. We can argue Moore's two laws, but it irks me to think that it should be an excuse for bloat.
I think C therefore I code C should be maintained, and all these other derivatives of C should be ignored.
If MAME reverted back to C, I'm sure there would be less bloat and more efficiency without having resort to Moore's poor excuse, as I have seen it so many times, posted here.
IMHO.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259045 - 07/05/11 10:27 AM
|
|
|
> If MAME reverted back to C, I'm sure there would be less bloat and more efficiency
> without having resort to Moore's poor excuse, as I have seen it so many times, posted
> here.
You've just proven your incompetence.
OG.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: Olivier Galibert]
#259051 - 07/05/11 11:52 AM
|
|
|
> > If MAME reverted back to C, I'm sure there would be less bloat and more efficiency
> > without having resort to Moore's poor excuse, as I have seen it so many times,
> posted
> > here.
>
> You've just proven your incompetence.
>
> OG.
Elaborate.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259053 - 07/05/11 12:26 PM
|
|
|
> > the dogmatic, narrow view of regular C programmers.
>
> There are benefits to C++ even for the casual programmer or for the new student to
> the language. But I cannot see any benefits for the professional or the serious
> student.
>
> I studied C in college and found it difficult at first, then as I progressed, the
> language taught me how to be more methodical, focused and structured in my
> programming tasks.
>
> Roll on five years later when I went back to college and studied C++ and was baffled
> yet again on it's use. Luckily I was able resort to standard C to finish the course,
> due to the constraints imposed by C++ at the time (i.e. poor exception handling).
> Even my lecturers advised resorting to C to resolve the problems experienced with
> C++.
>
> Now exploring the OOP part of college with C#, it amazes me why coders are so lazy
> today, true we are all standing on the shoulders of giants but lazy giants at that.
>
> Granted I am not a Jedi C coder by any wide margin, but it is clear where the bloat
> comes from. If not the coder but from the language. We can argue Moore's two laws,
> but it irks me to think that it should be an excuse for bloat.
>
> I think C therefore I code C should be maintained, and all these other derivatives of
> C should be ignored.
>
> If MAME reverted back to C, I'm sure there would be less bloat and more efficiency
> without having resort to Moore's poor excuse, as I have seen it so many times, posted
> here.
>
> IMHO.
I think you're just sorry because you couldn't set everything as global variables to solve your problems. :P At least that's what most C# programmers use to call a constraint. The good code is not made by the language you use (though it helps) but the programmer.
Now you will tell us everyone should still use assembler to speed up emulation after year 2000. Good luck maintaining code through SVN like that.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259057 - 07/05/11 02:29 PM
|
|
|
> > > If MAME reverted back to C, I'm sure there would be less bloat and more
> efficiency
> > > without having resort to Moore's poor excuse, as I have seen it so many times,
> > posted
> > > here.
> >
> > You've just proven your incompetence.
>
> Elaborate.
MAME was 100% C until about a year ago, and it was equally slow then. All of the top slowest drivers (Naomi, Model 3, System 2x) are *still* 100% C (although OG's restructuring Naomi as device classes now, which will finally make it readable). QED.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: BIOS-D]
#259059 - 07/05/11 03:25 PM
|
|
|
Quote:
I think you're just sorry because you couldn't set everything as global variables to solve your problems. :P At least that's what most C# programmers use to call a constraint. The good code is not made by the language you use (though it helps) but the programmer.
Now you will tell us everyone should still use assembler to speed up emulation after year 2000. Good luck maintaining code through SVN like that.
No the die is cast and the MAME project already committed on its chosen path and impractical to deviate.
Assembler? Yes for speed & No for maintenance. Yes for a closed project, No for every Tom, Dick & Robert.
C# is great for the beginner for what it does and lol at your global gag.
Good code is not my argument. Only intelligent code and methods to achieve it, is.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259064 - 07/05/11 03:42 PM
|
|
|
Quote:
MAME was 100% C until about a year ago
Was that about the time of .139 or a coincidence?
I cannot understand where you are going with that. If it was such a superior improvement, why the 20% odd slow down in the core? Easier to read was it?
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259067 - 07/05/11 04:13 PM
|
|
|
> I cannot understand where you are going with that. If it was such a superior
> improvement, why the 20% odd slow down in the core? Easier to read was it?
There's not a 20% slowdown in the core (there was a bench run about the time the core was first converted to C++ and the results were identical), and you edited out my entire point: all of the Moore's Law cites you disparage were made when MAME was still 100% C. By your theory, Naomi should've been running full speed on a Pentium 3 in 0.128.
You're stuck in the dogmatic dead end of thinking the implementation language and other details are more important to the results (including performance) than the algorithm. I've said it before, I'll say it again: start up DEMUL, change the CPU to "interpreter" and the graphics to "software", and marvel at the identical-to-MAME framerates.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259071 - 07/05/11 04:39 PM
|
|
|
> > I cannot understand where you are going with that. If it was such a superior
> > improvement, why the 20% odd slow down in the core? Easier to read was it?
>
> There's not a 20% slowdown in the core (there was a bench run about the time the core
> was first converted to C++ and the results were identical), and you edited out my
> entire point: all of the Moore's Law cites you disparage were made when MAME was
> still 100% C. By your theory, Naomi should've been running full speed on a Pentium 3
> in 0.128.
>
> You're stuck in the dogmatic dead end of thinking the implementation language and
> other details are more important to the results (including performance) than the
> algorithm. I've said it before, I'll say it again: start up DEMUL, change the CPU to
> "interpreter" and the graphics to "software", and marvel at the identical-to-MAME
> framerates.
Can you please provide the link to the bench results?
Naomi on a P3....I would have settled for Dkong on a P3.
I'll do as you suggest and check out DEMUL out of pure curiosity.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259072 - 07/05/11 04:45 PM
|
|
|
> Naomi on a P3....I would have settled for Dkong on a P3.
So run an old version with the wrong colors and the samples. Change the algorithm - analog circuit simulation is expensive. Ask the folks who run SPICE for a living.
> I'll do as you suggest and check out DEMUL out of pure curiosity.
I'll throw in that all of ElSemi's emulators are 100% C++ as an additional example (I have the source for his Model 2). I don't think anyone's complaining about their performance.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259077 - 07/05/11 05:39 PM
|
|
|
So let me get this straight. The Mamedevs changed the core of MAME from C to C++ just to make it easier to read?
Your (unreferenced) benchmarks says that the core speed was the same.....
Why waste all that time and effort to fix something that wasn't broke? Just to make it easier on the eye?
Oh boy.
|
|
|
| AeroCityMayor |
|
Entity formerly known as alien_mame
|
|
|
|
|
Reged: 11/11/03
|
|
Posts: 2438
|
|
Loc: Wakefield, West Yorks, UK.
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259079 - 07/05/11 05:44 PM
|
|
|
>
> What does this mean, in technical terms?
I'll bet you're glad you asked now, eh?
|
Coherance of posts inversely proportional to Foster's consumption!!!
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259081 - 07/05/11 06:03 PM
|
|
|
> Why waste all that time and effort to fix something that wasn't broke? Just to make
> it easier on the eye?
You once again have just proven your incompetence. Impressive.
OG.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259082 - 07/05/11 06:07 PM
|
|
|
> 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.
People complain that (for instance) working on driver A can instigate core tampering that hurts driver B. That's no longer possible - the core protect: and private:s its implementation details now, so the compiler won't let you touch them.
> Your (unreferenced) benchmarks says that the core speed was the same.....
Go to John IV's benchmarks page. The relevant one is 0.128 vs 0.128u4. (The ST-V result there was because of a bug that's since been fixed; everything else is in the statistical noise).
> Why waste all that time and effort to fix something that wasn't broke? Just to make
> it easier on the eye?
Let me put this in a way even the "but it doesn't improve the emulation" crowd can understand: the C++ conversion made it immediately possible to bring in classes from pSX, which greatly improved PSX emulation on both the MAME and MESS sides. Similarly we've brought in pieces of bsnes and improved both MAME and MESS (one of the NEC DSPs was also used in arcade games). And I have the (C++) source for ElSemi's Model 2 emulator. Guess what will happen to the quality of MAME's emulation when I drop that in?
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259086 - 07/05/11 06:51 PM
|
|
|
> > 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.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: Olivier Galibert]
#259088 - 07/05/11 07:18 PM
|
|
|
Quote:
You once again have just proven your incompetence. Impressive.
And your impressive and endless supply of repetitive irrelevant one-liners. Congratulations.
++++++
So the MameDevs changed Mame to implement code from others' work (the hard part of the project) rather than create the code from scratch. I can see now that this wasn't just a Mame requirement but a necessity for MESS. I would further a guess that C++ was chosen for cross platform compatibility?
Mame is to faithfully emulate the machine board of a game like Tekken, than to use a PSX port. Mr Belmont's explanation makes complete sense.
I owe an apology to a certain somebody.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259091 - 07/05/11 07:34 PM
|
|
|
> So the MameDevs changed Mame to implement code from others' work (the hard part of
> the project) rather than create the code from scratch.
Wow. That is so not the takeaway I was trying to convey. Bryan got it - read his reply and you might start to understand.
Caveman version for people with no significant life experience as professional programmers: MAME easier to read, to write, to bugfix, and to share with other emulators. All of those are good things, not just one. Zug zug.
|
|
|
| TheGuru |
|
MAMEDev Dumper
|
|
|
|
|
|
Reged: 06/13/04
|
|
Posts: 1226
|
|
Loc: Dumpville
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259106 - 07/05/11 11:25 PM
|
|
|
> I'll throw in that all of ElSemi's emulators are 100% C++ as an additional example (I
> have the source for his Model 2). I don't think anyone's complaining about their
> performance.
are you sure about that? I'm pretty sure he mentioned to me that some important bits or whatever are ASM. I could be wrong, it was a long time ago when it was discussed.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: mogli]
#259116 - 07/06/11 12:14 AM
|
|
|
"The C99 standard (which isn't properly supported by most compilers) introduced a lot of pointless bloat without adding significantly to the power of the language."
Oh god, I'd kill myself before going back to having to declare all variables at the top of the function again >.>
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259117 - 07/06/11 12:20 AM
|
|
|
> byuu's fully embraced C++0x including lambda expressions
Hell yes I have.
Code:
systemLoadCartridge.onTick = []() {
fileBrowser.fileOpen(FileBrowser::Mode::Cartridge, [](string filename) {
cartridge.loadNormal(filename);
});
};
When clicking or using keyboard to activate the menu item System::LoadCartridge, invoke the file browser's FileOpen functionality in cartridge browsing mode. If a file were chosen, pass the selected file name onto the Cartridge loading class to begin playing the game.
I provide a callback function inline from within another inline callback function. You can literally pass anonymous functions around as function arguments inside of anonymous functions. If that's not the coolest thing you've ever seen, then you suck :P
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259120 - 07/06/11 01:00 AM
|
|
|
> People complain that (for instance) working on driver A can instigate core tampering that hurts driver B. That's no longer possible - the core protect: and private:s its implementation details now, so the compiler won't let you touch them.
They're not as safe as you might think
http://byuu.org/articles/programming/public_cast
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: byuu]
#259123 - 07/06/11 01:36 AM
|
|
|
> > People complain that (for instance) working on driver A can instigate core
> tampering that hurts driver B. That's no longer possible - the core protect: and
> private:s its implementation details now, so the compiler won't let you touch them.
>
> They're not as safe as you might think
>
> http://byuu.org/articles/programming/public_cast
Nobody is going to bother with the template crap in that article to 'defeat' C++ class access restrictions. And nobody ever claimed that C++'s class access restrictions were some magic way to prevent programmers from writing code to break them. There are a multitude of ways to 'work around' access restrictions, but every single one of them is clearly just that and wouldn't pass even the most lax code review.
So what R. Belmont says is true: it's not possible to bypass these class restrictions, not in the framework of code that would be accepted into the MAME source tree.
|
|
|
| italie |
|
MAME owes italie many thank yous, hah
|
|
|
|
|
|
Reged: 09/20/03
|
|
Posts: 15246
|
|
Loc: BoomTown
|
|
|
|
Send PM
|
|
|
Re: C versus C++ with regard to MAME
[Re: byuu]
#259125 - 07/06/11 02:43 AM
|
|
|
> > byuu's fully embraced C++0x including lambda expressions
>
> Hell yes I have.
>
> systemLoadCartridge.onTick = []() {
> fileBrowser.fileOpen(FileBrowser::Cartridge, [](string filename) {
> cartridge.loadNormal(filename);
> });
> };
>
> When clicking or using keyboard to activate the menu item System::LoadCartridge,
> invoke the file browser's FileOpen functionality in cartridge browsing mode. If a
> file were chosen, pass the selected file name onto the Cartridge loading class to
> begin playing the game.
>
> I provide a callback function inline from within another inline callback function.
> You can literally pass anonymous functions around as function arguments inside of
> anonymous functions. If that's not the coolest thing you've ever seen, then you suck
> :P
It's like the epoxy block of C++....
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: R. Belmont]
#259131 - 07/06/11 04:03 AM
|
|
|
> > So the MameDevs changed Mame to implement code from others' work (the hard part of
> > the project) rather than create the code from scratch.
>
> Wow. That is so not the takeaway I was trying to convey. Bryan got it - read his
> reply and you might start to understand.
>
> Caveman version for people with no significant life experience as professional
> programmers: MAME easier to read, to write, to bugfix, and to share with other
> emulators. All of those are good things, not just one. Zug zug.
Well said. The project should have been C++ a long time ago. This was starting to show its ugly head way back in the .3x era. Wholesale copying of code between drivers and cpu cores. Where the only difference between the two sets of code was some small revision in some call. Like a cpu instruction missing in one core but not another but a game relying on the behavior of the missing instruction. So many things ended up with switchs and jump tables. For something that would be a simple derivation in C++. It got better with sharing. But I still see blog posts where 'merged code and used newer implementation xyz number of bugs fixed'. That is just one symptom of the problem of sticking to C dogmatically. Another one was having to retrofit savestates into all of the drivers. Where it could in theory be inherited into everything.
I have had a couple of projects where I was constrained to C only. After awhile it is 'if only I had C++ this is would be much easier to do'. Its not then you write 30-60 lines for something C++ does naturally.
Also it is C++ and does everything C does... So you can in theory still do it the 'C way'. But why do it? Why limit yourself?
If done properly you could even see how different devices/boards/etc were 'born' from other ones and provide better documentation.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259135 - 07/06/11 04:44 AM
|
|
|
> MAME was 100% C until about a year ago
>
> Was that about the time of .139 or a coincidence?
>
> I cannot understand where you are going with that. If it was such a superior
> improvement, why the 20% odd slow down in the core? Easier to read was it?
Where's the 20% slowdown? My piece of crap Celeron still runs Tekken 2 at the exact same speed as it does in my 0.136 build. No faster, no slower. MDEC is a little screwed up in the later builds though, but that has nothing to do with speed.
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259149 - 07/06/11 06:12 AM
|
|
|
> Why waste all that time and effort to fix something that wasn't broke? Just to make
> it easier on the eye?
Just to make it easier on the eye? Your joking right?
Sounds to me that you have never worked in a team dev environment, or at least appreciate the issues with a demanding large scale project.
OOP was designed mainly to standardise coding practices with the idea to re-use as much of the code as possible in an organised object based fashion.
How can that be a bad thing for a large scale and complex project such as MAME or MESS?
Where this benefits most for the existing devs, is by making the code more attractive for new devs to take part and to be able to re-use code from other sources (as already mentioned).
Edited by zambr (07/06/11 06:21 AM)
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: byuu]
#259161 - 07/06/11 06:52 AM
|
|
|
> > byuu's fully embraced C++0x including lambda expressions
>
> Hell yes I have.
>
> systemLoadCartridge.onTick = []() {
> fileBrowser.fileOpen(FileBrowser::Cartridge, [](string filename) {
> cartridge.loadNormal(filename);
> });
> };
>
> When clicking or using keyboard to activate the menu item System::LoadCartridge,
> invoke the file browser's FileOpen functionality in cartridge browsing mode. If a
> file were chosen, pass the selected file name onto the Cartridge loading class to
> begin playing the game.
>
> I provide a callback function inline from within another inline callback function.
> You can literally pass anonymous functions around as function arguments inside of
> anonymous functions. If that's not the coolest thing you've ever seen, then you suck
> :P
I have not kept very current on state of the art in C++ but I like what I am seeing. I'm happy that C++ features are being added that aren't just more template un-debuggable, un-readable garbage (to put my own strong opinion out there!) ...
|
|
|
|
Re: C versus C++ with regard to MAME
[Re: AeroCityMayor]
#259163 - 07/06/11 06:56 AM
|
|
|
Quote:
I'll bet you're glad you asked now, eh?
Indeed I am. In particular, seeing things like these:
((emphasis added is mine))
Quote:
Like a cpu instruction missing in one core but not another but a game relying on the behavior of the missing instruction. So many things ended up with switchs and jump tables. For something that would be a simple derivation in C++. It got better with sharing. But I still see blog posts where 'merged code and used newer implementation xyz number of bugs fixed'. That is just one symptom of the problem of sticking to C dogmatically. Another one was having to retrofit savestates into all of the drivers. Where it could in theory be inherited into everything.
Quote:
It's dogma uber alles. I've actually written CPU, sound, and general device cores under each of MAME's major stages of development and it has *never* been cleaner, easier, or more elegant than it is now. Abolishing fixed device types ("CPU", "sound", "video", "general") in favor of being able to inherit the precise fine-grained capabilities you need from a set of base classes is something like a fucking revolution, and makes it far, far easier to write and maintain devices. (It also makes them easier to use outside of MAME because you know exactly what the interface contract is and everything else is private).
If only this kind of infrastructure existed within the collective unconscious of humanity.....
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
|
Re: C versus C++ with regard to MAME
[Re: ]
#259167 - 07/06/11 08:38 AM
|
|
|
> You once again have just proven your incompetence. Impressive.
>
> And your impressive and endless supply of repetitive irrelevant one-liners.
> Congratulations.
With ungrounded convictions such as "mame is bloated" and "C++ is always slower that C", you don't deserve any better.
OG.
|
|
|
Previous 
Index 
Next 
Threaded 
C versus C++ with regard to MAME
Reply
[Re: 
