C++ Help

[hickman]

Okay here is my question i can do very little programming. I can semi write a program in C++ that inputs 3 test scores and then prints teh avgerage of the two highests scores. But what i can't do is Input 3 values and output one of the following three messaes that best describes the three Values 1. THREE VALUES EQUAL 2. TWO VALUES EQUAL 3. NO VALUES EQUAL. so if someone could kinda of explain how to go about writting the code for a program like this please get back to me

[avdven]

#include <iostream>
using namespace std;

int main()
{
int x, y, z;

cout << "Input 3 numbers: ";
cin >> x >> y >> z;

if ((x == y) && (y == z))
cout << "Three values equal\n";
else if ((x == y) || (x == z) || (y == z))
cout << "Two values equal\n";
else
cout << "No values equal\n";

return 0;
}



(haven't actually compiled it, but it should work...

The basic logic follows:

- Start by (obviously) declaring three variables (in this case, I used integers)
- Then read in all three integers one by one.
- Next, you need to compare the variables to see how many of them are equal
-> By using nested if-else statements, you can reduce the amount of statement redundancy
-> First - check to see if all the variables are equal
-> Then check to see (since they're not all equal), if two of them are equal
-> Finally, since none are equal, you're done

AJ

[pwaring]

Okay, three points need to be made here:

1. Don't post the same question twice - it's confusing (I'd already answered this question in another thread for hickman, and then I came across this one)
2. The tutorials forum is, suprisingly enough, for TUTORIALS. Questions should go in the newbie help forum, programming security or whatever
3. Is it really too much effort to write std::cout instead of cout? Almost all the code and books I have seen on C++ either have the 'using namespace std' statement or just don't bother (meaning in the latter case that it's not standard C++, although you might get away with it if you use <iostream.h> instead of <iostream>.

[PM8228]

At least he wont be able to C/P the code and make it work. He'll have to figure some syntax stuff out. Also, do lots of people use the || and &&, I always use 'and' and 'or'.

[White_Eskimo]

Also, do lots of people use the || and &&, I always use 'and' and 'or'.

err yeah well they are standard operators that pretty much do the same thing in all language. I always use them and i high descourage you from using the "and" or "or" keywords in their place because you might start to get confused with you are using the bitwise operators ('|' or '&'). Also avdven, instead of putting \n (new line escape character for those who dont know...) at the end of your cout statements, you should just and your lines with endl; or because you dont want to piss off pwarning std::endl; :) Anyways, follow pwarning's instructions, read the tutorials and dont post the same thing twice :)

[pwaring]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by PM8228
At least he wont be able to C/P the code and make it work. He'll have to figure some syntax stuff out. Also, do lots of people use the || and &amp;&amp;, I always use 'and' and 'or'.

I always use && and ||, and I've yet to come across any publicly-released code that uses 'and' or 'or' (in fact, to be honest I've never seen them mentioned in any of my resources/books, and I wasn't even sure if they'd work as a result). It's recommended to use the 'shorthand' operators, simply because everyone else does and it's a convention that's widely adopted. I know that the precedence for the longhand operators is lower than the shorthands (not that you should rely on the order of precedence to make your programs work) - which means you can write things like:

$i = mysql_connect($host, $username, $password) or die("Couldn't connect");

in PHP and Perl (okay, Perl version would be different, but you get the idea). I think you could use || instead of or and it would still work though - but I know that I've seen somewhere that if you use or it definitely works because it's lower in the precedence table.

(I think I digressed a bit there, best get back on topic!)

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by White_Eskimo


err yeah well they are standard operators that pretty much do the same thing in all language. I always use them and i high descourage you from using the &quot;and&quot; or &quot;or&quot; keywords in their place because you might start to get confused with you are using the bitwise operators ('|' or '&amp;'). Also avdven, instead of putting \n (new line escape character for those who dont know...) at the end of your cout statements, you should just and your lines with endl; or because you dont want to piss off pwarning std::endl; :) Anyways, follow pwarning's instructions, read the tutorials and dont post the same thing twice :)

If I recall correctly, std::endl is better than \n because it flushes the output buffer and I think std::cout is buffered by default. So I think (but I'm not sure) that if you created a program with three lines of output using \n, they would all be flushed at the end of the program, whereas using std::endl would mean each one was output at a time. I'm not 100% sure on this, but I remember reading somewhere that std::endl was something to do with buffering and std::cout.

Oh, and my pedanticness when it comes to std::cout instead of using namespace std and cout, is because it sort of defies the whole point of namespaces being available and implemented if you're just going to override them without a good reason.

[Lansing_Banda]

So pwarning, if you don't use namespace std, then what do you do, define everything before your programs?

[EaseZE]

using std::cout;
using std::cin;
using std::endl;

and so on

[White_Eskimo]

So pwarning, if you don't use namespace std, then what do you do, define everything before your programs?

I bet he does what any half-smart programmer would do which is put all of the using std directives into a header file and then before he writes his programs, he just types in #include "directives.h" and viola he has everything he wanted (if you read my tutorial about the preprocessor you would know how to do this :))

I'm not 100% sure on this, but I remember reading somewhere that std::endl was something to do with buffering and std::cout.
Yup pwarning you are right there...also you could do something by calling the flush() function in the iostream library that will flush the buffer for you...an example of this in code would look something like this:

#include <iostream>
using std::cout;
using std::cin;

int main (void)
{
char decision;

cout << "Is White_Eskimo a hardcode C++ H4xwh0r3? (y/n)";
cout.flush();
cin >> decision;
if (decision == 'y')
cout << "Damn right he is!";
else
cout << "WRONG...Deleting your C drive...";
}


Anyways, the only problem about using the flush() function that is built in to your iostream library is that it doesnt skip a line like endl does :)

[PM8228]

White your a guru :) From now on I'll code respectably && use ||. ;)

-Life is like a box of chocolates, sweet-

[pwaring]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by Lansing_Banda
So pwarning, if you don't use namespace std, then what do you do, define everything before your programs?

Instead of writing:

using namespace std

cout << "Like this\n";


I use:

std::cout << "Like this instead" << std::endl;


In other words, every time I use cout, I write it in full including the namespace - i.e. std::cout. Same for std::endl, std::cin etc.

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by White_Eskimo


I bet he does what any half-smart programmer would do which is put all of the using std directives into a header file and then before he writes his programs, he just types in #include "directives.h" and viola he has everything he wanted (if you read my tutorial about the preprocessor you would know how to do this :))

Nope, never used that - although it would be the most sensible way to go about it if I was going to skip the namespaces. The thing is, I'm not anti-using namespace because it requires extra lines etc., but because it defies the whole point of having namespaces in the first place. I use std::cout all the time and it always compiles and works as I expect.

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by White_Eskimo

Yup pwarning you are right there...also you could do something by calling the flush() function in the iostream library that will flush the buffer for you...an example of this in code would look something like this:

Anyways, the only problem about using the flush() function that is built in to your iostream library is that it doesnt skip a line like endl does :)

Of course, there's nothing stopping you from flushing the output explicitly using the flush() function - if that's all you want to do. However, if you're going to add a newline anyway, you might as well use std::endl. It's a matter of using the best tool for the job at hand.

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by White_Eskimo

I bet he does what any half-smart programmer would do which is put all of the using std directives into a header file and then before he writes his programs, he just types in #include "directives.h" and viola he has everything he wanted (if you read my tutorial about the preprocessor you would know how to do this :))


Half-smart programmer should be the defining quote because a smart programmer would not put all their std dependencies in an include file. The compile time of the project will increase significiantly because header files such as set, iostream, map and string are extremly huge. The compiler will need to read and parse each file each time it is included and determine if it is needed or not. Additionaly if your program is including the iostream header when the program does not make use of it the size and intialization time of the program will also increase because the cout, cin, and cerr objects need to be constructed. Furthermore, if you have a list of 'using std::' and have a particulary large project you may end up making use of quite a few parts of the stl. This will make you're include file resolve many of the names of the standard namespace and will have the averse effect of 'using namespace std' which even yourself advocate against.

[White_Eskimo]

smart programmer would not put all their std dependencies in an include file. The compile time of the project will increase significiantly because header files such as set, iostream, map and string are extremly huge.

?? iostream.h is a file that is on your computer and if you have ever gone into it or done anything with it you would notice that it is about 15000 lines of code so it is pretty big. If i were to create a file called directives.h and i was to add all of the std namespace's directives in it, i would have about 10 lines of code in the file directives.h. So you tell me...will an extra 10 lines of code really slow down your compile time? SURE!! by 10 miliseconds max...plus any half-smart programmer would know that compile time doesnt matter at all. it is how fast the program will run...not how fast it will compile on your computer. once you distribute your .exe your clients wont have to compile anything in C++ because it is already in computer language.

Additionaly if your program is including the iostream header when the program does not make use of it the size and intialization time of the program will also increase because the cout, cin, and cerr objects need to be constructed
you better hope that you are using the iostream header file in your code or there is no point in using any std namespace's directives...

Furthermore, if you have a list of 'using std::' and have a particulary large project you may end up making use of quite a few parts of the stl
Agreed. But hardcore C++ programmers who put their class declarations into a header file run into the same problem right?

This will make you're include file resolve many of the names of the standard namespace and will have the averse effect of 'using namespace std' which even yourself advocate against
well if you have seen any of my code, i use the using namespace std declaration because i dont give a shit about compile time...it is run time that matters...i kinda see the stand you are taking but my directives.h file is a lot shorter than my iostream header file so therefore it isnt quiet the same thing but i do believe that my compile time will probably be increased by a couple of miliseconds...but then who cares? unless you work in a open source enviroment, people wont take your code and try to compile it. they will just get your executable and run that.

Anyways, why do i use the using namespace std; declaration and not all of the namespace directives? because it is a lot safer form of programming. instead of the using std directives the declarations has everything in it and therefore i can never leave something out. Anyways...hope this post made some sense :)

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by White_Eskimo
plus any half-smart programmer would know that compile time doesnt matter at all. it is how fast the program will run...not how fast it will compile on your computer. once you distribute your .exe your clients wont have to compile anything in C++ because it is already in computer language.


It is obvious that you havn't worked on any real projects before because you would understand that compiling can take over a day to complete. The company I work at has strick standards on what can be included and resolve in a .cpp file and a .h file. On another note, run-time speed doesn't dictate how you should be programming either. Unless the constraints of the program specifically state that it must run with a certain time-effeciency then there is no need to be worrying about petty details like speed. If it runs fast enough that the user can not notice it is fast enough.


Anyways, why do i use the using namespace std; declaration and not all of the namespace directives? because it is a lot safer form of programming. instead of the using std directives the declarations has everything in it and therefore i can never leave something out. Anyways...hope this post made some sense :)

No it is not safer because you run into the name clashing problem that was so prominent in C and was gratefully fixed. I've noticed a few other posters mention quite a few times about what can happen via using namespace std. So I'm not sure if I should make the effort on beating a dead horse with its own leg but it seems that I will have to because you are set in your ways. The standard template library is quite enormous and was designed by a programmer Alex Stepanov who was years a head of his time in program design. He understood that classes should only be used when the problem calls for a behavior or a state. He also knew that he should not be gobbing together all the functions, classes, and variables into one gigantic class std because C++ was so nice to give us the namespace it lacked from before. The std namespace keeps all the functions, classes, and variables inside it's own namespace and prevents them from polluting the global namespace. When you use 'using namespace std' it resolves all of the functions variables, and objects into the global namespace. The consuequences of name clashing will pop-up in any medium to large scale project. Where you import a library(or even use your own) that has a common function, class or variable that is also included in the stl and the choice to use which becomes ambiguous. This can lead to hard to track run-time errors of certain functions behaving differently then expected and was a major leading reason that namespaces were introduced to the language.

[White_Eskimo]

It is obvious that you havn't worked on any real projects before because you would understand that compiling can take over a day to complete.

You are right...i am just a 15 year old kid :) Anyways wow i didnt know that computers take that long to compile stuff...wow learn something everyday at AO :)

If it runs fast enough that the user can not notice it is fast enough.

I was thought that no program ever runs fast enough...and even if all of my programs ran a million times faster, that still wouldnt be good enough for me.

[avdven]

Just my two cents on the whole std debate. While I agree it's better programming practice to use std::cout and such, I also know it's a hassle for many beginning programmers to have to worry about it. I teach some introduction to computer science courses at my campus and we just started using the "using" statement last semester because the CS department felt that they should move towards the new standard all at once. In doing so, I was given the choice on how I wanted to teach the material. I decided to stick with "using namespace std" because, that way, the students don't need to know exactly which directives are stored in the std library. It's much like, at least for the first course, I tell them to just get in the habit of always putting #include<iostream> so it gets them in the habit of using the include statement. Not until the second semester do we go into details on what is included in each of the header files and which they need to include for what purposes. That's the reason I teach them to simply us "using namespace std" as well. It gets them in the habit of having the using statement at the top of their programs. Some of you may disagree with this method of teaching, but, given many of the students I've had in the class, it's amazing that some of them even get their programs to compile, let alone execute successfully.

AJ

[Lansing_Banda]

That's a fine way of teaching it, and that is what I still use. I still don't understand the reason why you wouldn't use namespace std? I would love to know in depth your reasoning behind this (It's good programming practice isn't what I'm looking for).

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by avdven
That's the reason I teach them to simply us &quot;using namespace std&quot; as well. It gets them in the habit of having the using statement at the top of their programs. Some of you may disagree with this method of teaching, but, given many of the students I've had in the class, it's amazing that some of them even get their programs to compile, let alone execute successfully.

AJ

IMO the first thing you should be teaching your students is the rules of scope and namespaces can fall quite easily into one of these lectures. Honestly you can tell me students wont understand it but it's hogwash. Check out Koeing & Moo both are excellent C++ teachers and authors of the now infamous accelerated C++ book. They both advocate learning how to properly resolve identifiers into scope from the beggining. Though this is just an opinion - teach your class the way you want but it seems to me that Koeing & Moo have a pretty succesful carear.


Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by Lansing_Banda
That's a fine way of teaching it, and that is what I still use. I still don't understand the reason why you wouldn't use namespace std? I would love to know in depth your reasoning behind this (It's good programming practice isn't what I'm looking for).

Many posters have already mentioned the pitfalls in fact I mentioned it myself in my last post.

[pwaring]

It is obvious that you havn't worked on any real projects before because you would understand that compiling can take over a day to complete.

Not all "real" projects take days to compile.

The company I work at has strick standards on what can be included and resolve in a .cpp file and a .h file.

Not everyone at AO works for the same company as you though, so we're not bound by their standards.

On another note, run-time speed doesn't dictate how you should be programming either.

I think you'll find that run-time speed does dictate how you should be programming. Remember Quake? Some of the most frequently-called routines in that program had to be written in assembly to make it run at an acceptable speed, even though the rest of the game was written in C. So run-time speed not only dictates how you should program, but what language you should use to do so.

Unless the constraints of the program specifically state that it must run with a certain time-effeciency

Since a lot of programs run in real-time (i.e. they have to respond to an event within a given time, whether that be 1 millisecond or three hours), the constraints of most programs will specify that they must run with a certain time-efficiency.

there is no need to be worrying about petty details like speed

Since when has speed ever been a petty detail in computing? If speed was so insignificant, why on earth would Intel and AMD be spending millions of pounds creating faster and faster processors (especially the new 64 bit range)? They'd only sell these products if consumers (particularly businesses and research institutes) wanted their programs to run faster. Admittedly, processor speed isn't the only factor in speed of execution, but it sure as hell makes a difference.

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by pwaring

Not all real projects take days to compile.


No not all but if you go and work at any software house that produces software of any reasonable size it will. I can't think of one project that I've worked on in the last four years that wasn't compiled overnight. This is just my experience though working on industry strength software.


Not everyone at AO works for the same company as you though, so we're not bound by their standards.

Did I say you were to be bound by my company standards? The only reason I mentioned my companies standards is to give a real life example on why you shouldn't be using unused dependencies.


I think you'll find that run-time speed does dictate how you should be programming. Remember Quake? Some of the most frequently-called routines in that program had to be written in assembly to make it run at an acceptable speed, even though the rest of the game was written in C. So run-time speed not only dictates how you should program, but what language you should use to do so.


Sure I remember quake, I also remember the days when there wasn't parallel processing and all graphics rendering was done in software on the CPU. Though today it is different with CPU speeds reaching 4 ghz and programmable processors on the video card's, games are reaching lighting speeds. Do you know that most games spend 90% of their time in the graphics card? That leaves the rest of the time for physics and AI, which in the past has also had to share its time with graphics rendering. Because of this games like the bandicoot series have come out that are programmed in an even higher-level language LISP. LISP allowed the programmers to write code much faster and prototype new ideas that allowed the game to get out on budget and in time. This is a feet that most games written in C++ cannot compete with. A majority of games today that are shipped use a pre-written graphics library, physics and AI library. Their concerns are not with speed anymore and they are more worried about game design, game play and meeting deadlines.

Of course there are exceptions to this, some programs are written to be as fast as possible such as the implementers of the graphics, physics, AI library, embedded devices that are triggers for events. But these projects are more rare then they are common the typical project makes use of 3rd party libraries that were written once and are already as fast as they need it to be. It is very typical for new programmers to worry about the execution speed of a program before it is written. This should be left to the profiler to decide what needs to be executed quicker and most of the time it can be solved by implementing a more efficient algorithm and not by inlining assembly.

In this era of computing, programmers time and program stability has become more of a priority in a majority of applications even in games then speed has been.

[pwaring]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by progme


No not all but if you go and work at any software house that produces software of any reasonable size it will. I can't think of one project that I've worked on in the last four years that wasn't compiled overnight. This is just my experience though working on industry strength software.

Define "reasonable size". A program doesn't have to require overnight compilation to be considered industrial strength software.

Sure I remember quake, I also remember the days when there wasn't parallel processing and all graphics rendering was done in software on the CPU.

Most PCs today only have one CPU, so parallel processing still isn't an option for the fast majority of people.

And I wasn't saying that speed is the most important factor in programming any more, but it is certainly not a petty one as you stated it to be.

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by pwaring

Define &quot;reasonable size&quot;. A program doesn't have to require overnight compilation to be considered industrial strength software.


I suppose not and this is also my personal experience working at software houses. I certainly don't constitute for all software development houses but I can speak for the ones I have worked at. If you would like to offer counter-evidance to support your argument rather then no it doesn't please post them now.


Most PCs today only have one CPU, so parallel processing still isn't an option for the fast majority of people.


PC's definatly have more then one CPU, the sound card will have a CPU your graphics card will have a CPU and if it's a modern graphics card it will have a programmable CPU. When I was refering to paralllel processing I meant that as the game was handling it's logic/physics the graphics card was rendering to the screen. The way games today work is this:

1) Handle input
2) Handle Logic
3) Handle Physics
4) Batch all responce sounds and send the to the sound card to be processed( 3d sounds, dongle effects..)
5) Batch all 3d data together and send to the graphic card to be rendered
6) LOOP

Step 4/5 use to be a much longer process because games didn't have any CPU's that could handle 3d Sounds and graphics. Thankfully all of the rendering is done on the GPU(graphics card processor unit) and this leaves the programmer to only worry about step 2 and 3.

[pwaring]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by progme


I suppose not and this is also my personal experience working at software houses. I certainly don't constitute for all software development houses but I can speak for the ones I have worked at. If you would like to offer counter-evidance to support your argument rather then no it doesn't please post them now.

I've worked on projects where the software has compiled in a matter of minutes (sometimes even less) - and sometimes that code was written in Visual Basic. Now, you might not consider it "industrial strength" software, but the fact that it was an important part of a £250 million project and was taken to various countries (including the Middle East and the USA) to be demonstrated shows that to someone it was "industrial strength" software.


PC's definatly have more then one CPU

I was referring to the actual CPU that most people would be thinking off - i.e. the Intel/AMD processor that sits on your motherboard with a fan on and works at anything from 66MHz to upwards of 4Ghz (based on the manufacturer's specs of course).


the sound card will have a CPU your graphics card will have a CPU and if it's a modern graphics card it will have a programmable CPU.

When I was refering to paralllel processing I meant that as the game was handling it's logic/physics the graphics card was rendering to the screen. The way games today work is this:

1) Handle input
2) Handle Logic
3) Handle Physics
4) Batch all responce sounds and send the to the sound card to be processed( 3d sounds, dongle effects..)
5) Batch all 3d data together and send to the graphic card to be rendered
6) LOOP

Step 4/5 use to be a much longer process because games didn't have any CPU's that could handle 3d Sounds and graphics. Thankfully all of the rendering is done on the GPU(graphics card processor unit) and this leaves the programmer to only worry about step 2 and 3.

What, so the programmer doesn't have to worry about handling input now either? Programmers have to be aware (although not necessarily involved in, if using an external graphics library) of ALL the steps you mention, even if they don't have to write the code for it. Furthermore, programmers definitely have to worry about input - even in the most simplest of programs user input is one of the things that can cause major problems if not handled correctly. Again, you could use a library to validate the input, but still the programmer will have to worry about it.

[hickman]

Thanks everyone for the responses. They helped a lot and i will try not to post them in two different forums. Thanks again HICKMAN

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by pwaring

What, so the programmer doesn't have to worry about handling input now either?


It's not that they don't have to worry about input but it is generally as hard as writing the initializing code for starting up a window, it is trivial. Also handling input takes no real time considerations because you are just polling the hardware every iteration.


Programmers have to be aware (although not necessarily involved in, if using an external graphics library) of ALL the steps you mention, even if they don't have to write the code for it. Furthermore, programmers definitely have to worry about input - even in the most simplest of programs user input is one of the things that can cause major problems if not handled correctly. Again, you could use a library to validate the input, but still the programmer will have to worry about it.

Let's not vear off the topic we were originally discussing. We were talking about speed considerations and how you even believed you had to choose a low language project for real-time applications. I never would disagree with you on how programmers need to have a sense for how all their external dependencies should work. Knowing basic theory on graphics rendering is essential even if you're making use of a third party library but worrying about optimizations, custimizations and inlining assembly is nothing programmers should be worrying about. A game company can make a game now a days in a high level language like ruby, python, or LISP by using 3rd party libraries. Speed isn't as important as it use to be.

[pwaring]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by progme


It's not that they don't have to worry about input but it is generally as hard as writing the initializing code for starting up a window, it is trivial. Also handling input takes no real time considerations because you are just polling the hardware every iteration.

I wouldn't say that handling and validating user input was "trivial" - think of the number of problems that have been caused over the years by users either accidentally or purposely entering invalid data. Sure, the basic functions of handling input may be trivial, but to make sure that you cover all (or at least the majority of) the possible inputs that might cause unwanted effects requires a lot of thought. In fact, last time I worked on a project, about 20% of the code was used purely to collect and validate user input.

Let's not vear off the topic we were originally discussing. We were talking about speed considerations and how you even believed you had to choose a low language project for real-time applications.

I never said that you had to choose a low level language for real-time applications - what I mentioned was that speed is essential in real-time applications (although the program doesn't have to be fast, it does have to respond in a certain time) and sometimes that used to mean using assembly. Nowadays you can probably get by using a slightly higher level language such as C - perhaps even write everything in an interpreted language if it doesn't require extremely fast response times (based in milliseconds rather than seconds say). Speed (or perhaps more correctly response time - although that is obviously linked to speed) has always been an important factor for programmers, and will continue to be so. Perhaps if you're writing a simple education program it might not be top of the priority list, but it's still a consideration.

I never would disagree with you on how programmers need to have a sense for how all their external dependencies should work. Knowing basic theory on graphics rendering is essential even if you're making use of a third party library but worrying about optimizations, custimizations and inlining assembly is nothing programmers should be worrying about. A game company can make a game now a days in a high level language like ruby, python, or LISP by using 3rd party libraries. Speed isn't as important as it use to be.

I agree, speed isn't as important as it used to be - but only to a point. It's still an important consideration for tasks which need to be performed faster and faster (e.g. any task involving large amounts of statistical analysis/number crunching). Sure, you might not have to worry about inlining assembly anymore (unless you are interacting with hardware on a low-level, or require the fastest response times possible - e.g. in a program dealing with hospitals, emergency services etc.).

In theory you could use ruby or python to write a game, but I doubt that the major software houses will step to that level yet because the games probably wouldn't run fast enough. Sure, python (and other interpreted languages) are great for scripting, but I expect the core code (some of which the programmers will still have to write, even if they are using external libraries) will be written in C/C++ or a similar middle-level language for some time yet.

[progme]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=#post) by pwaring

I wouldn't say that handling and validating user input was "trivial" - think of the number of problems that have been caused over the years by users either accidentally or purposely entering invalid data. Sure, the basic functions of handling input may be trivial, but to make sure that you cover all (or at least the majority of) the possible inputs that might cause unwanted effects requires a lot of thought. In fact, last time I worked on a project, about 20% of the code was used purely to collect and validate user input.


If you would stay in context to my post then you would know that I'm refering to Input in the game cycle. I only brought up inputing to show that it was a detail in the game cycle but not an important detail. Writing how input is handled in a game is trivial, it requires polling every iteration of the game sequence of the hardware and updates the states of every key position. Based on the key positions events happen.


In theory you could use ruby or python to write a game, but I doubt that the major software houses will step to that level yet because the games probably wouldn't run fast enough. Sure, python (and other interpreted languages) are great for scripting, but I expect the core code (some of which the programmers will still have to write, even if they are using external libraries) will be written in C/C++ or a similar middle-level language for some time yet. [/B]

www.gamasutra.com

That is the definitive source for game development. Particulary if you check out he articles on the Crash Bandicoot series you will notice that the 'core' of the game was written in LISP. Those games were fully 3d and I didn't notice anything slow about them. While C++ is still a major development language in the game industry, due to managers making development decisions, many game companies are shifting away from developing the game from ground up. Many games are written in a scripting language and use Unreal's or Quake's engine.

You can argue with me all day that there will be always a need for assembly and low level C optimizations. I've worked on plenty of projects which made strict requirements on the space and time. Though White_Eskimo made it clear that he was more worried about speed on such a trivial issue. I see it happen all the time even at work when iterns are optimizing they are looking at little tricks such as ++i instead of i++ when they should be looking at the tripple nested for loop they had implemented. Another observation I've made is that on most programming forums, when people ask advice on what language they should learn they usually base there decision on speed. Most of these programmers arn't writing time critical applications they are writing programs that help them out or maybe they are writing games. So they choose to learn C/C++ and it takes them months to get beyond the basics of C++ where if they choose a language like Python they could of have multiple fully developed programs out in weeks.

[Death_Knight]

btw, can someone explain the usage of "using namespace std;" and #pragma once. i'm new to c++ :confused:

[White_Eskimo]

oh no not again....i am going to write a tutorial about it damn it the question has been asked at least 100 times...sorry to be a little rude, but it gets annoying when you re type the same stuff over and over again. plus if you actually read all the posts in this thread i think you should get a general idea maybe i havent read them all so i dont quite know but thats what progme and pwarning were originally argueing about...or at least i think it was :)

[pwaring]

You can argue with me all day that there will be always a need for assembly and low level C optimizations.

You are not listening to what I have said - I never stated that there will *always* be a need for assembly or low level C optimisations (in fact I've managed to avoid assembly and "low level" C in all the commercial programs I have written), I merely used them as an example to support the point that speed still is an important issue when considering the design of any program, not just games.

I've worked on plenty of projects which made strict requirements on the space and time.

So have I, but that doesn't necessarily mean I had to use interpreted languages such as Ruby, Python or LISP.

Though White_Eskimo made it clear that he was more worried about speed on such a trivial issue. I see it happen all the time even at work when iterns are optimizing they are looking at little tricks such as ++i instead of i++ when they should be looking at the tripple nested for loop they had implemented.

i++ is just a throwback to when it did actually make a difference to write i++ instead of i = i + 1, because it told the compiler to use the increment instruction rather than the add instruction, which if I recall correctly did make a speed difference. Nowadays the compiler will probably interpret both statements as the same thing and optimise it for you.


Another observation I've made is that on most programming forums, when people ask advice on what language they should learn they usually base there decision on speed. Most of these programmers arn't writing time critical applications they are writing programs that help them out or maybe they are writing games. So they choose to learn C/C++ and it takes them months to get beyond the basics of C++ where if they choose a language like Python they could of have multiple fully developed programs out in weeks.

Obviously speed is not going to be a critical issue when you start programming, especially since a lot of newbies will spend so much time thinking about what they are doing that they won't notice if their program runs 10% slower in Python than its equivalent in C++. It's probably better to learn an interpreted language first, although some people (including myself) do find it more useful to be thrown in "at the deep end" so to speak.

[White_Eskimo]

Though White_Eskimo made it clear that he was more worried about speed on such a trivial issue.

listen i am just some 15 year old kid who writes lame programs that do lame stuff and all that matters to me while programming is style and efficiency...thats all that i care about. However, if you were to write some huge program, i think that it is important that the program not only gets the job done, but gets it done quickly and efficiently (sp?). Anyways, if you write programs that run really slowly or games that take forever to run, i believe that none of your users are going to be happy and no one is going to want to use your product.

You can argue with me all day that there will be always a need for assembly and low level C optimizations.
Amen. the only programming language i kinda know is C++ and it is pretty low leveled. low level programming languages run a lot faster and are great for writing operating systems or programs that are low leveled such as databases.