Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Please simplify my code.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
43 replies to this topic

#21 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 23 June 2012 - 10:24 PM



OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


I think you are confused...
He uses an object of class osteam called "cout" instead of "printf".

Ok, let me say this clearly this is not C. This is C++
You can create a new file, and call it "main.c". Then copy the code above, and compile it... What do you get? A lot of errors!!
C can not use objects, and iostream isn't a C library!

Yes I think for something like this objects are just going to seem needlessly complicated really. Any time you're only making one instance of an object you're really just using it for categorization


Ye, that is absolutely true, from the viewpoint of scale. But if a beginner never uses classes, he won't learn the proper ways, and to think in OOP takes experience which you should try to garnish from the start.
I mean, most C++ programmers are still not taking full advantage of C++, but still mixes in C. That goes up to professional level, even. And that's an issue.

Sponsor:

#22 riverreal   Members   -  Reputation: 616

Like
1Likes
Like

Posted 23 June 2012 - 10:26 PM



OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


I think you are confused...
He uses an object of class osteam called "cout" instead of "printf".

Ok, let me say this clearly this is not C. This is C++
You can create a new file, and call it "main.c". Then copy the code above, and compile it... What do you get? A lot of errors!!
C can not use objects, and iostream isn't a C library!


You're going to start being snide? Can we not do that, please?

Ask mr Stroustroup (spelling?) if this is how C++ was designed to look. Yes, he may use one of C++'s objects, but if he still codes his programs as if it was C, then he gains no benefits of C++'s improvements. That is not something I should have to argue about.


You are wrong again...
The OOP is just one of the paradigms. C++ is multi-paradigm.
Look here: http://en.wikipedia.org/wiki/Multi-paradigm_programming_language#Multi-paradigm_programming_language
So, C++ can be structured like C.
OOP is not the only improvement.

You said the code ISN'T C++ and IS C...
So go and make a main.c file, copy the code, and compile it...

#23 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 23 June 2012 - 10:29 PM




OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


Sorry I've no clue what your talking about. Seems its advanced stuff.


I don't know about "advanced", it's what C++ was created for. It's pretty much the whole point of it, as an improvement upon C. If you want to learn C++, you need to start right away. If you want to use C instead, then that's a choice you need to make, but you need to be aware of the difference. I don't know if all these other guys thinks I'm just messing with you or something, but I think that once you look at the code example I attached to my other post, you'll understand that C++ is slightly different from C. Hopefully you other guys would care to listen to me and see the truth in what I'm saying instead of jsut downvoting me as if I was trolling. I, for one, am trying to teach a newbie the proper way to code, and good practices. I don't know what the rest of you are trying to do.


Your code works amazingly well Posted Image Actually I'm learning C++ as my first programming language. So I called your stuff advanced. I'm an altogether beginner programmer. I'm saving your code buddy. When I jump into these topics, I'll understand your code and would be able to admire it much more.


Hey, thanks a bunch, that warms the old heart. :)

See, C++ is an inherently "advanced" language, so you've got a lot on your plate. But I don't think it's right to try to dumb it down. I've walked this road myself, and I'd have loved someone to steer me in the right direction and save me some time trying to re-adjust later.

Take my code and improve it! It still lacks some stuff that would make the program more complete. And anything you don't understand about it, don't just skip it, ask and/or learn it instead.

#24 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 23 June 2012 - 10:32 PM




OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


I think you are confused...
He uses an object of class osteam called "cout" instead of "printf".

Ok, let me say this clearly this is not C. This is C++
You can create a new file, and call it "main.c". Then copy the code above, and compile it... What do you get? A lot of errors!!
C can not use objects, and iostream isn't a C library!


You're going to start being snide? Can we not do that, please?

Ask mr Stroustroup (spelling?) if this is how C++ was designed to look. Yes, he may use one of C++'s objects, but if he still codes his programs as if it was C, then he gains no benefits of C++'s improvements. That is not something I should have to argue about.


You are wrong again...
The OOP is just one of the paradigms. C++ is multi-paradigm.
Look here: http://en.wikipedia....amming_language
So, C++ can be structured like C.
OOP is not the only improvement.

You said the code ISN'T C++ and IS C...
So go and make a main.c file, copy the code, and compile it...


If you want to be picky, OK, you win. Technically, what I said was wrong, because it won't compile as C.

Now, listen to this: and see my point.

#25 riverreal   Members   -  Reputation: 616

Like
1Likes
Like

Posted 23 June 2012 - 10:37 PM

Yes, I see your point.
Voted

#26 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 23 June 2012 - 10:43 PM

Oh, do note that in the text file, I just put everything in there, which is not actually the way it should be.

Things should be split up in header files and source files. That can be a bit tricky to understand in the beginning aswell, because it's mostly a technical aspect for compiling, for example. But don't do like I did and just put it all in the main source file.

the part that says:

class Application {...}

should be in .h files, and included in your main.cpp file.

The parts that have the actual functions, such as..

int application::run()

...should be in source files. But you'll get a hang of that, it's not too complicated.

#27 antiHUMANDesigns   Members   -  Reputation: 58

Like
-1Likes
Like

Posted 23 June 2012 - 10:52 PM

There is one thing that I believe most people don't understand about C++, and it's hard to explain it. The easiest way to understand what C++ attempts to do is it you know the basic of Java. In Java, there is no "int main()" where the program starts, but instead you need to register a class that is the application itself. C++ wants to do this aswell, but because windows is written in C, not C++, it expects to call a function like "int main()" (which is actually WinMain() in windows, if I've understood that correctly).
So, by doing what I did in the code I supplied, I try to emulate this intended behaviour, by bypassing the "int main()" as seamlessly as possible. This allows you application to be a class also.

int main()
{
Application application;
return application.run();
}

...and application::run() will act the same way as "int main()", in the sense that it is the starting point of your program, and it returns the value that is also returned by "int main()" to the operating system.

I think that if Stroustrup had his way, C++ would've needed a "class Application" aswell (like Java does, which is truly OOP), but C++ does not run on a virtual machine like Java does.

Edited by antiHUMANDesigns, 23 June 2012 - 10:56 PM.


#28 CaptainMurphy   Members   -  Reputation: 262

Like
1Likes
Like

Posted 24 June 2012 - 12:58 AM

but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.

#29 rip-off   Moderators   -  Reputation: 8667

Like
1Likes
Like

Posted 24 June 2012 - 08:23 AM

antiHUMANDesigns, your program is actually a poor example of C++. Forcing object orientation into what can be more easily represented as a procedural program doesn't really gain you anything. Your code has some good ideas that would be relevant - splitting the program into smaller functions, but the artifical use of classes actually detracts from the program.

There is a tipping point where object orientation starts to make sense. For example, you might create a slot machine class when the slot machine has state - it might record how much money it has and the program would allow the casino operator to take the profits or replenish losses from the machines.

This program has almost no state - just the player's money. The money is such a simple concept that wrapping it in a class seems unnecessary - overengineering really.

For reference, here is the OP's program split into smaller functions without object orientation:
#include <iostream>
#include <ctime>
#include <cstdlib>

using namespace std;

int random(int low, int high)
{
	return low + rand() % ((high + 1) - low);
}

int determineBet(int money)
{
	while(true)
	{
		cout << "Enter your bet: ";
		int bet;
		cin >> bet;
		if(bet > 0 && bet <= money)
		{
			return bet;
		}
		cout << "Please enter a valid bet.\n";
	}
}

void playSlot(int &money)
{
	const int Low = 2;
	const int High = 7;

	while(money > 0)
	{
		cout << "Players chips: $" << money << endl;

		int bet = determineBet(money);

		int r0 = random(Low, High);
		int r1 = random(Low, High);
		int r2 = random(Low, High); 

		cout << r0 << " " <<  r1 << " " << r2 << endl;

		if (r0 == 7 && r1 == 7 && r2 == 7)
		{
			money += (10 * bet);
			cout << "Lucky Bucky!\n";
		}
		else if(r0 == r1 && r1 == r2)
		{
			money += (5 * bet);
			cout << "Not Bad!\n";
		}
		else if(r0 == r1 || r0 == r2 || r1 == r2)
		{
			money += (3 * bet);
			cout << "Go Happy!\n";
		}
		else
		{ 
			cout << "You Lose!\n";
			money -= bet;
		}
	}
}

int main()
{
	srand( time(NULL) );
	bool quit = false;
	int money = 1000;
	while(!quit && money > 0)
	{
		cout << "1) Play slot. 2) Exit. ";
		int choice;
		cin >> choice;
		if(choice == 1)
		{
			playSlot(money);
		}
		else if(choice == 2)
		{
			quit = true;
		}
		else
		{
			cout << "Please choose a valid option.\n";
		}
	}

	if(money == 0)
	{
		cout << "You just got flushed!\n";
	}
	cout << "Exiting\n";
}


#30 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 24 June 2012 - 08:23 AM


but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.


A very small wasted effort, in such a case. But if a language is meant for OOP, then I think it should be done that way, just like Java (though I don't like Java). In Java, you don' thave the option to stray outside the OOP path, and I don't think C++ benefits from doing so. If you want to write a small program, you can choose to do it in C, and that's a choice. But you can also chose to do it with "proper" C++, which I feel is by going OOP like it was intended.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.

#31 Tasaq   Members   -  Reputation: 1250

Like
0Likes
Like

Posted 24 June 2012 - 08:39 AM





OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


I think you are confused...
He uses an object of class osteam called "cout" instead of "printf".

Ok, let me say this clearly this is not C. This is C++
You can create a new file, and call it "main.c". Then copy the code above, and compile it... What do you get? A lot of errors!!
C can not use objects, and iostream isn't a C library!


You're going to start being snide? Can we not do that, please?

Ask mr Stroustroup (spelling?) if this is how C++ was designed to look. Yes, he may use one of C++'s objects, but if he still codes his programs as if it was C, then he gains no benefits of C++'s improvements. That is not something I should have to argue about.


You are wrong again...
The OOP is just one of the paradigms. C++ is multi-paradigm.
Look here: http://en.wikipedia....amming_language
So, C++ can be structured like C.
OOP is not the only improvement.

You said the code ISN'T C++ and IS C...
So go and make a main.c file, copy the code, and compile it...


If you want to be picky, OK, you win. Technically, what I said was wrong, because it won't compile as C.

Now, listen to this: https://www.youtube....h?v=JBjjnqG0BP8 and see my point.

If we start with Bjarne Stroustrup, in "Design and and evolution of C++" he wrote:
" In particular, I do not try to enforece a single style of design through a narrowly defined programming language. People's ways of thinking and working are so diverse that an attepmpt to force a single style would do more harm than good. Thus, C++ is deliberately designed to support a variety of styles rather than a would-be 'one-true way'. "
You try to push oop like the one-true way. This guy stated that he just started learnig C++, and if this is his first programming language, learning oop is like learning how to ride a bicycle befor learning how to walk. He should learn imperative programming first, and since C++ is hybrid, he is using it.

And by the way, I love OOP and that's why I use C#. But in my opinion people should start from basics.

#32 Matt-D   Crossbones+   -  Reputation: 1469

Like
1Likes
Like

Posted 24 June 2012 - 08:46 AM



but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.


A very small wasted effort, in such a case. But if a language is meant for OOP, then I think it should be done that way, just like Java (though I don't like Java). In Java, you don' thave the option to stray outside the OOP path, and I don't think C++ benefits from doing so. If you want to write a small program, you can choose to do it in C, and that's a choice. But you can also chose to do it with "proper" C++, which I feel is by going OOP like it was intended.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I disagree. As said above, C++ is a multi-paradigm programming language.
I actually mostly use GP (Generic Programming) with TMP (template metaprogramming) over OOP for code reuse and (static) polymorphism and find it much cleaner and more preferable.
Allowing to mix and choose is its strength over C# or Java (they have generics, but they're quite different, resolved at run-time, and rather limited). The whole idea of "pure OOP" where "everything is an object" is simply incompatible with GP or at best uninteresting; see interview with Stepanov, http://www.stlport.o...tepanovUSA.html

Of course that strength really shows when you mix in modern techniques, like GP and TMP, not meaning that you should stay with imperative programming / procedural programming for everything (with C-style code you'd have to deal with C-style errors).
And I find programs written in early style / "C with Classes" /* http://c2.com/cgi/wi...arlyCeePlusPlus */ to be a problem as well.
// IMVHO, OOP and some of its features are overused to the point of abuse -- I think you should learn templates and get used to static polymorphism/CRTP before you even begin to think about using the "virtual" keyword -- if you want to start with C++ the modern C++ way, learn templates, STL, and Boost first, picking GP and TMP as your main paradigms -- object-orientation second; the imperative & procedural stuff should just come to you in the meantime ;-) In the end: pick and choose what's optimal for your project (now you see why you should be aware of *all* the things to pick and choose from).

See:
http://www2.research...bs_faq.html#oop
http://www2.research...aq.html#generic
http://www2.research...l#multiparadigm
Why C++ isn't just an object-oriented programming language

Edited by Matt-D, 24 June 2012 - 08:51 AM.


#33 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 24 June 2012 - 08:50 AM






OK, let me start by saying this, very clearly: This is not C++. This is C. You should learn C++ instead. What book or reference are you using, which claims that this is C++? Throw it out the window, whether literal or virtual, and get a reference of C++ instead.

C++ is an object-oriented programming language. This means that you should look at things as real-world object, created from blueprints called classes (or structs). If you have a game with a slot-machine, then that slot machine is an object, I think you'd agree. (In fact, the game itself is an object, isn't it?) So what you need to do is to write a class called SlotMachine, and create an object from that class. And pulling the lever on a slot machine should be represented as a member function (or a "method", as it's called in some languages) of the SlotMachine class. So when you want to pull the lever, you write slotMachine.pullLever().

You have pretty much crammed everything into the main() function. That is not the C++ way, but the C way.

I'd love to re-write it all in C++ for you, but... well, I think you should do it, frankly. Otherwise you'd not be learning, I think.

EDIT:

Oh, don't get me wrong, I'll help you if you need it, and I'm sure others here will aswell. Just try some on your own, with a decent C++ reference in your back, and if you run into problems, we're here.
Just... start over, and do it in C++.


I think you are confused...
He uses an object of class osteam called "cout" instead of "printf".

Ok, let me say this clearly this is not C. This is C++
You can create a new file, and call it "main.c". Then copy the code above, and compile it... What do you get? A lot of errors!!
C can not use objects, and iostream isn't a C library!


You're going to start being snide? Can we not do that, please?

Ask mr Stroustroup (spelling?) if this is how C++ was designed to look. Yes, he may use one of C++'s objects, but if he still codes his programs as if it was C, then he gains no benefits of C++'s improvements. That is not something I should have to argue about.


You are wrong again...
The OOP is just one of the paradigms. C++ is multi-paradigm.
Look here: http://en.wikipedia....amming_language
So, C++ can be structured like C.
OOP is not the only improvement.

You said the code ISN'T C++ and IS C...
So go and make a main.c file, copy the code, and compile it...


If you want to be picky, OK, you win. Technically, what I said was wrong, because it won't compile as C.

Now, listen to this: https://www.youtube....h?v=JBjjnqG0BP8 and see my point.

If we start with Bjarne Stroustrup, in "Design and and evolution of C++" he wrote:
" In particular, I do not try to enforece a single style of design through a narrowly defined programming language. People's ways of thinking and working are so diverse that an attepmpt to force a single style would do more harm than good. Thus, C++ is deliberately designed to support a variety of styles rather than a would-be 'one-true way'. "
You try to push oop like the one-true way. This guy stated that he just started learnig C++, and if this is his first programming language, learning oop is like learning how to ride a bicycle befor learning how to walk. He should learn imperative programming first, and since C++ is hybrid, he is using it.

And by the way, I love OOP and that's why I use C#. But in my opinion people should start from basics.


You equate "style" or "style of design" to mean OOP vs non-OOP, when it could mean so many other things. Maybe it's taken out of context, but nothing in that piece of text say that what he's talking about is OOP vs procedural.

I push OOP as the one-true way for C++, yes. Maybe I'm at fault there, and if so I apologize. I guess that if that's not an accepted stand-point, I should keep it to myself.

And I agree that learning the basics in programming first may be a good idea, but then maybe learning C++ as a first language wasn't a good idea? I think that if you're going to learn C++, you should learn it properly without generating bad habits from the start. Now, as to what is actually bad habits, I don't claim to have the one true answer, I'm just throwing in my 50 cent, for free. If I was cherging for what I was saying, people would have more of a right to bash me for it. As of now, I'm only trying to help.

#34 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 24 June 2012 - 08:57 AM

antiHUMANDesigns, your program is actually a poor example of C++. Forcing object orientation into what can be more easily represented as a procedural program doesn't really gain you anything. Your code has some good ideas that would be relevant - splitting the program into smaller functions, but the artifical use of classes actually detracts from the program.

There is a tipping point where object orientation starts to make sense. For example, you might create a slot machine class when the slot machine has state - it might record how much money it has and the program would allow the casino operator to take the profits or replenish losses from the machines.

This program has almost no state - just the player's money. The money is such a simple concept that wrapping it in a class seems unnecessary - overengineering really.


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.

#35 antiHUMANDesigns   Members   -  Reputation: 58

Like
-1Likes
Like

Posted 24 June 2012 - 09:10 AM




but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.


A very small wasted effort, in such a case. But if a language is meant for OOP, then I think it should be done that way, just like Java (though I don't like Java). In Java, you don' thave the option to stray outside the OOP path, and I don't think C++ benefits from doing so. If you want to write a small program, you can choose to do it in C, and that's a choice. But you can also chose to do it with "proper" C++, which I feel is by going OOP like it was intended.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I disagree. As said above, C++ is a multi-paradigm programming language.
I actually mostly use GP (Generic Programming) with TMP (template metaprogramming) over OOP for code reuse and (static) polymorphism and find it much cleaner and more preferable.
Allowing to mix and choose is its strength over C# or Java (they have generics, but they're quite different, resolved at run-time, and rather limited). The whole idea of "pure OOP" where "everything is an object" is simply incompatible with GP or at best uninteresting; see interview with Stepanov, http://www.stlport.o...tepanovUSA.html

Of course that strength really shows when you mix in modern techniques, like GP and TMP, not meaning that you should stay with imperative programming / procedural programming for everything (with C-style code you'd have to deal with C-style errors).
And I find programs written in early style / "C with Classes" /* http://c2.com/cgi/wi...arlyCeePlusPlus */ to be a problem as well.
// IMVHO, OOP and some of its features are overused to the point of abuse -- I think you should learn templates and get used to static polymorphism/CRTP before you even begin to think about using the "virtual" keyword -- if you want to start with C++ the modern C++ way, learn templates, STL, and Boost first, picking GP and TMP as your main paradigms -- object-orientation second; the imperative & procedural stuff should just come to you in the meantime ;-) In the end: pick and choose what's optimal for your project (now you see why you should be aware of *all* the things to pick and choose from).

See:
http://www2.research...bs_faq.html#oop
http://www2.research...aq.html#generic
http://www2.research...l#multiparadigm
Why C++ isn't just an object-oriented programming language


OK, see, from everything I've read, 99% of people have nothing but bad things to say about templates, and I chose not to use them myself. (Though by doing so it also means I'm not good at them either.)
And I'm not exaggerating when I say 99%. I can't recall one single person, besides you, who has said anything good about templates.
I just made personal choice not to use them, but I admit that I no longer remember straigh off-hand why that is.

And don't get me wrong, I write things procedurally at times aswell. I just don't think it'd be a good thing to teach people to do things the easy way. Maybe I'm at fault, I'm not a licensed teacher. And, perhaps due to my aspergers, I do surely over-engineer things, because I want everything to make sense. And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)

Edited by antiHUMANDesigns, 24 June 2012 - 11:17 AM.


#36 Matt-D   Crossbones+   -  Reputation: 1469

Like
0Likes
Like

Posted 24 June 2012 - 09:29 AM





but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.


A very small wasted effort, in such a case. But if a language is meant for OOP, then I think it should be done that way, just like Java (though I don't like Java). In Java, you don' thave the option to stray outside the OOP path, and I don't think C++ benefits from doing so. If you want to write a small program, you can choose to do it in C, and that's a choice. But you can also chose to do it with "proper" C++, which I feel is by going OOP like it was intended.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I disagree. As said above, C++ is a multi-paradigm programming language.
I actually mostly use GP (Generic Programming) with TMP (template metaprogramming) over OOP for code reuse and (static) polymorphism and find it much cleaner and more preferable.
Allowing to mix and choose is its strength over C# or Java (they have generics, but they're quite different, resolved at run-time, and rather limited). The whole idea of "pure OOP" where "everything is an object" is simply incompatible with GP or at best uninteresting; see interview with Stepanov, http://www.stlport.o...tepanovUSA.html

Of course that strength really shows when you mix in modern techniques, like GP and TMP, not meaning that you should stay with imperative programming / procedural programming for everything (with C-style code you'd have to deal with C-style errors).
And I find programs written in early style / "C with Classes" /* http://c2.com/cgi/wi...arlyCeePlusPlus */ to be a problem as well.
// IMVHO, OOP and some of its features are overused to the point of abuse -- I think you should learn templates and get used to static polymorphism/CRTP before you even begin to think about using the "virtual" keyword -- if you want to start with C++ the modern C++ way, learn templates, STL, and Boost first, picking GP and TMP as your main paradigms -- object-orientation second; the imperative & procedural stuff should just come to you in the meantime ;-) In the end: pick and choose what's optimal for your project (now you see why you should be aware of *all* the things to pick and choose from).

See:
http://www2.research...bs_faq.html#oop
http://www2.research...aq.html#generic
http://www2.research...l#multiparadigm
Why C++ isn't just an object-oriented programming language




but C++ does not run on a virtual machine like Java does.


That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.


A very small wasted effort, in such a case. But if a language is meant for OOP, then I think it should be done that way, just like Java (though I don't like Java). In Java, you don' thave the option to stray outside the OOP path, and I don't think C++ benefits from doing so. If you want to write a small program, you can choose to do it in C, and that's a choice. But you can also chose to do it with "proper" C++, which I feel is by going OOP like it was intended.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I disagree. As said above, C++ is a multi-paradigm programming language.
I actually mostly use GP (Generic Programming) with TMP (template metaprogramming) over OOP for code reuse and (static) polymorphism and find it much cleaner and more preferable.
Allowing to mix and choose is its strength over C# or Java (they have generics, but they're quite different, resolved at run-time, and rather limited). The whole idea of "pure OOP" where "everything is an object" is simply incompatible with GP or at best uninteresting; see interview with Stepanov, http://www.stlport.o...tepanovUSA.html

Of course that strength really shows when you mix in modern techniques, like GP and TMP, not meaning that you should stay with imperative programming / procedural programming for everything (with C-style code you'd have to deal with C-style errors).
And I find programs written in early style / "C with Classes" /* http://c2.com/cgi/wi...arlyCeePlusPlus */ to be a problem as well.
// IMVHO, OOP and some of its features are overused to the point of abuse -- I think you should learn templates and get used to static polymorphism/CRTP before you even begin to think about using the "virtual" keyword -- if you want to start with C++ the modern C++ way, learn templates, STL, and Boost first, picking GP and TMP as your main paradigms -- object-orientation second; the imperative & procedural stuff should just come to you in the meantime ;-) In the end: pick and choose what's optimal for your project (now you see why you should be aware of *all* the things to pick and choose from).

See:
http://www2.research...bs_faq.html#oop
http://www2.research...aq.html#generic
http://www2.research...l#multiparadigm
Why C++ isn't just an object-oriented programming language


OK, see, from everything I've read, 99% of people have nothing but bad things to say about templates, and I chose not to use them myself. (Though by doing so it also means I'm not good at them either.)
And I'm not exaggerating when I say 99%. I can't recall one single person, besides you, who has said anything good about templates.
I just made personal choice not to use them, but I admit that I no longer remember straigh off-hand why that is.

And don't get me wrong, I write things procedurally at times aswell. I just don't think it'd be a good thing to teach people to do things the easy way. Maybe I'm at fault, I'm not a licensed teacher. And, perhaps due to my aspergers, I do surely over-engineer things, because I want everything to make sense. And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)


Well, I prefer to look at quality over quantity. If templates are good for Abrahams, Alexandrescu, Gurtovoy, Meyers, Stepanov, Stroustrup, and Sutter, they're good enough for me :-) // So, now you'll be hopefully able to recall a few more people besides me who said something good about them Posted Image

I would presume that 99% of people you've talked with / read are probably still stuck in the early 1990s "C with Classes" approach and aren't really using C++, since templates are a pretty fundamental feature thereof Posted Image
// Chances are they were using ancient (late 1980s/early 1990s) compilers that didn't support much beyond the pre-standard "iostream.h" and simply couldn't compile template-based code well or at all -- so, no wonder they had bad experience ;] I have to say, it takes some major intellectual laziness though to never try a feature again just because a decade or two decades ago one had a bad experience...

If you want to catch up, I'd recommend:
http://www.moderncpp.../book/main.html
http://www.boostpro.com/mplbook/

If you're already familiar with OOP and design patterns, you can see the first book as trying to achieve the abstraction without the run-time performance overhead penalty -- for instance, what's known as "strategy pattern" in the Design Patterns book (using the OOP) way is really stemming from a common software engineering principle and (re)introduced as "policy based design" (using the GP) in the Alexandrescu's book.

You shouldn't trust other people, you should pick up the book, examine it, and determine the costs/benefits yourself!

That's why this part of your statement worries me: "and I chose not to use them myself. (Though by doing so it also means I'm not good at them either.)" This is exactly the WRONG approach -- you should FIRST become good at a feature in order to be able to assess whether it's good or bad for your project(s) and choose what's right, otherwise you're unable to do so (and no, reading/listening to other people, including me, is not enough -- personal experience is vital!). Only then you're able to pick and choose optimally. Take the "virtual" keyword, for example -- are you sure that when you need polymorphism in your code it *always* has to be dynamic/run-time polymorphism? If not, are you aware that C++ allows you to have static/compile-time polymorphism with absolutely zero run-time costs /* http://en.wikipedia....emplate_pattern */?

Perhaps it will turn out that dynamic polymorphism is exactly what you need. Perhaps not. Similarly, it may turn out that Data-Oriented Design (DOD) will be a better fit than OOP in a particular application -- http://gamesfromwith...oriented-design -- or, in completely another application, the costs/benefits flip around.
That's the beauty of multiparadigm programming -- it allows you to pick *exactly* what you need, when you need it -- no less and no more.
Seriously, I recommend you to pick up GP and TMP as well -- it will make you a better programmer and a better designer.

As for mixing -- again, see the links to Stroustrup's FAQ -- no offense, but I'm inclined to take the word of the C++ creator over you and "99% of people" you've encountered for what's wrong and what's right in C++ :-)

Edited by Matt-D, 24 June 2012 - 09:39 AM.


#37 CaptainMurphy   Members   -  Reputation: 262

Like
0Likes
Like

Posted 24 June 2012 - 09:54 AM

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I'm not sure if you've programmed in c, I've used it a bit for writing libraries, and the main problems I have with it, are things that c++ has introduced shortcuts for, and of course its painfully lacking of the standard template library (So you have to implement your own lists, hashmaps etc). So not defining classes isn't really equivalent to c code.


And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)


I know the feeling, I dislike mixing functional code with imperative code, but I think procedural and oop can fit together fine. I know the feeling of over obsessing with oop from when I first started programming. If you want to see programming from another perspective, to see why oop isn't so important, you should look at a functional language like scheme (racket is a good implementation) or haskell.

Also if you're interested in alternate oop systems, look at clos (common lisp object system), I think it's a vast improvement over the c++/java/c# oop system.

Knowing some of these things, I believe will help you put things in a better perspective.

Edited by andrew111, 24 June 2012 - 10:06 AM.


#38 Cornstalks   Crossbones+   -  Reputation: 6991

Like
2Likes
Like

Posted 24 June 2012 - 10:08 AM

For the love of all things holy, people, please trim the quotes!

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 s/rand(), you're using the s/rand() from C (and not the s/rand() 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.

Edited by Cornstalks, 24 June 2012 - 10:13 AM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#39 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 24 June 2012 - 10:16 AM



{...} (tryign to cut down on the reply history here)


OK, see, from everything I've read, 99% of people have nothing but bad things to say about templates, and I chose not to use them myself. (Though by doing so it also means I'm not good at them either.)
And I'm not exaggerating when I say 99%. I can't recall one single person, besides you, who has said anything good about templates.
I just made personal choice not to use them, but I admit that I no longer remember straigh off-hand why that is.

And don't get me wrong, I write things procedurally at times aswell. I just don't think it'd be a good thing to teach people to do things the easy way. Maybe I'm at fault, I'm not a licensed teacher. And, perhaps due to my aspergers, I do surely over-engineer things, because I want everything to make sense. And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)


Well, I prefer to look at quality over quantity. If templates are good for Abrahams, Alexandrescu, Gurtovoy, Meyers, Stepanov, Stroustrup, and Sutter, they're good enough for me :-) // So, now you'll be hopefully able to recall a few more people besides me who said something good about them Posted Image

I would presume that 99% of people you've talked with / read are probably still stuck in the early 1990s "C with Classes" approach and aren't really using C++, since templates are a pretty fundamental feature thereof Posted Image
// Chances are they were using ancient (late 1980s/early 1990s) compilers that didn't support much beyond the pre-standard "iostream.h" and simply couldn't compile template-based code well or at all -- so, no wonder they had bad experience ;] I have to say, it takes some major intellectual laziness though to never try a feature again just because a decade or two decades ago one had a bad experience...

If you want to catch up, I'd recommend:
http://www.moderncpp.../book/main.html
http://www.boostpro.com/mplbook/

If you're already familiar with OOP and design patterns, you can see the first book as trying to achieve the abstraction without the run-time performance overhead penalty -- for instance, what's known as "strategy pattern" in the Design Patterns book (using the OOP) way is really stemming from a common software engineering principle and (re)introduced as "policy based design" (using the GP) in the Alexandrescu's book.

You shouldn't trust other people, you should pick up the book, examine it, and determine the costs/benefits yourself!

That's why this part of your statement worries me: "and I chose not to use them myself. (Though by doing so it also means I'm not good at them either.)" This is exactly the WRONG approach -- you should FIRST become good at a feature in order to be able to assess whether it's good or bad for your project(s) and choose what's right, otherwise you're unable to do so (and no, reading/listening to other people, including me, is not enough -- personal experience is vital!). Only then you're able to pick and choose optimally. Take the "virtual" keyword, for example -- are you sure that when you need polymorphism in your code it *always* has to be dynamic/run-time polymorphism? If not, are you aware that C++ allows you to have static/compile-time polymorphism with absolutely zero run-time costs /* http://en.wikipedia....emplate_pattern */?

Perhaps it will turn out that dynamic polymorphism is exactly what you need. Perhaps not. Similarly, it may turn out that Data-Oriented Design (DOD) will be a better fit than OOP in a particular application -- http://gamesfromwith...oriented-design -- or, in completely another application, the costs/benefits flip around.
That's the beauty of multiparadigm programming -- it allows you to pick *exactly* what you need, when you need it -- no less and no more.
Seriously, I recommend you to pick up GP and TMP as well -- it will make you a better programmer and a better designer.

As for mixing -- again, see the links to Stroustrup's FAQ -- no offense, but I'm inclined to take the word of the C++ creator over you and "99% of people" you've encountered for what's wrong and what's right in C++ :-)


A very well written reply. +1 (Apart from your last sentence.)

I understand that there are people who like templates, of course, I just haven't heard of any yet. I didn't count Stroustrup, because... well, frankly, he's biased. :D

You misunderstand me, I didn't chose not to use them because of what others have said. They didn't make sense to me.

Aren't they changing/improving templates for C++0x? As I recall, they had a pretty big flaw, which they are [finally] fixing now, so there is/was probably a reason that caused people not to like them, and likely the same reason that caused them to fix/improve it.

I have no formal education in programming, so I lack a lot of the terminology, and maybe I use some of it poorly. I do my best.

I also side with the creator, once I truly understand the intent and value of it. I just don't see it with templates. They're messy, first of all. I don't like using "++" in statements either, so I don't side with the creator there either, I think it's bad practice to use it in any other way that pretty much only "x++;" on it's own. and there are articles explaining why it's a bad idea, because it causes ambiguity in many cases. But C++ allows it, just like it allows many other bad practices (in different people's opinions). I just think templets fall into that category, which inherently means it's an opinion or matter of taste or style. All I'm saying is that I'm not alone in seeing it that way.

And like I've said earlier, I also use C++ procedurally (mostly when testing stuff), but I would never mix 2 styles in one application if I could help it. I actually go to great lengths to avoid doing so, sometimes. Keeping one style consistenly throughout one program is deathly important to me, so that I know where to look and what to expect when I look for things in my code. But if I completely skipped classes in a program, I personally would not consider it proper C++, and I stand by this opinion, for now.

#40 antiHUMANDesigns   Members   -  Reputation: 58

Like
0Likes
Like

Posted 24 June 2012 - 10:22 AM


Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.


I'm not sure if you've programmed in c, I've used it a bit for writing libraries, and the main problems I have with it, are things that c++ has introduced shortcuts for, and of course its painfully lacking of the standard template library (So you have to implement your own lists, hashmaps etc). So not defining classes isn't really equivalent to c code.


And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)


I know the feeling, I dislike mixing functional code with imperative code, but I think procedural and oop can fit together fine. I know the feeling of over obsessing with oop from when I first started programming. If you want to see programming from another perspective, to see why oop isn't so important, you should look at a functional language like scheme (racket is a good implementation) or haskell.

Also if you're interested in alternate oop systems, look at clos (common lisp object system), I think it's a vast improvement over the c++/java/c# oop system.

Knowing some of these things, I believe will help you put things in a better perspective.


No, I agree it's not equivalent to C code just because you don't use classes. But if you do'nt use classes, I don't think it's C++ code either. :P It feels more like some kind of mix...which I don't enjoy.

As for procedural and OOP... you know, the term "procedural" is something I probably end up using widely and wrongly. I lack formal education and I may get the terminology wrong. I've always programmed alone, for about 19 years, so I've never needed to express these things in words, to others. I do my best to express myself, but it obviously comes out wrong at times.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS