For the love of all things holy, people, please trim the quotes!
[quote name='antiHUMANDesigns' timestamp='1340549821' post='4952326']
Oh, you're right, I'm known to suffer from over-engineering complex. Might be my asperger acting up. But I'm sorry, I just can't agree that using OOP ever makes for bad C++, even in small applications. We might have different viewpoints on this, and I think neither of us would go as far as to shout "Truth!™". Properly formatted and divided into separate files, even small programs look and feel so much better to work with in OOP. And I still think it makes them easier to update and whatnot.
But in this very thread, to me it's about advocating abstraction.
It's not that you just over-engineered stuff. It's that it's not very good code. You wrote an empty constructor (why?), you used a C header (<time.h> (the C++ version is <ctime>)), you're using C-style casts (instead of C++ style casts), you're not including the header to use [font=courier new,courier,monospace]s/rand()[/font], you're using the [font=courier new,courier,monospace]s/rand()[/font] from C (and not the [font=courier new,courier,monospace]s/rand()[/font] from C++), etc. You're being hypocritical of the "you're using C, not C++." And as rip-off showed, you're using OOP wrong. There is
no need for SlotMachine to be a class (it's got
one function, and no member variables). There's no need for the Application class either, as idiomatic C++ wouldn't be using classes like that. If you want evidence that not everything needs to be in a class, take a look at the <algorithm> header. Some programming languages have done the disservice of teaching people that Everything Is An Object And Belongs In A Class, which is so far from true it's not even funny. OOP is great, but it's unfortunate that it's so misunderstood, and teaching a beginner to over engineer isn't doing him/her any favors.
For what it's worth, I commend you for trying to help. The reason I'm being a bit harsher than normal though is because you're being quite stubborn and this is in For Beginners, where details matter.
And for the record, you can do OOP in C. It's not just a C++ thing. C++ never meant for everything to be wrapped up in a class, and it intended for free standing functions to be used in addition to its other features that complement OOP.
[/quote]
Ah, man, I tried to re-write the OP's code as quickly as possible, and I made the constructor thinking I would put something there, and ended up not doing so, but leaving it like that. I didn't know it would come under scrutiny. Most people just write small snippets of code (or even pseudo-code) to show something, but I undertook to re-write it all as an example for a beginner, but it ended up being scrutinized by professionals instead. Had I known...
<time.h> instead of <ctime>, once again an honest mistake from trying to rush it. Doesn't change the point I was trying to make, though. If you look back, it's about the C++ way of thinking, not which libraries you use.
I disagree that SlotMachine shouldn't be a class. This is a quick prototype, or a first-version of the "game". If I wanted to add things to the slot machine, having it as a class already is a good thing. You might not like it, but to be completely frank and brutally literal, I don't give a shit, because it wasn't written for your enjoyment. It's C++, it compiles without errors, I like it, it allows for further development nicely... I'm happy with it.
In OOP, the slot machine is an object. I stand by that. I don't see how it matters what the class contains. The slot machine is an object, and when I pull it's lever, that's a method for that object (or, member function). Making it a function is not OOP, making it a variable won't work, so what would you make it? I chose to make it a class, and until until you can change my mind as to why it shouldn't be (performance is not an issue in this application, for example), I stand firm.
And I don't put everything in a class either. In my own projects, I have "lose" functions for getting random floating point values, for example. I never said everything needs to be a class, but I do claim that some things should be classes, because it makes logical sense if you consider how they are being handled. I can probably find some way to make a getRandomFloat() function to become an object, by looking at it like a pseudo-random number generator, but I don't see how I would make an actual slot machine into a function or a variable, and not feel silly about it.