C / C++ / MFC

14-Aug-05 18:46

I had a question about the two programming + I am some what new to the subject so bear with me... I have read multiple tutorials on programming in C++ and in Python, but I was always notice that something is different...

My first question is for Python... Whenever I look at different tutorials I notice this:
#! /usr/local/bin/python or this #! /usr/bin/python before your program starts... I was wondering though why some tutorials do not incorperate that in their tutorial/programs... I was actually wondering why you would, because I can run things just fine without putting that before my code in Python. I don't get any errors also. Is that only if you are running a linux system and you have to do that?

My second question is about C++... I have also noticed that in different tutorials they show all types of different ways to start out their programs. For example one way is
-----------------------------------------------------------------------------------------

#include<br />
<br />
int main ()<br />
//(main program goes here)<br />
<br />
<br />
or<br />
<br />
#include<br />
#include<br />
int main(int nNumberofArgs, char* pszArgs[])<br />
{

----------------------------------------------------------------------------------------
The list goes on and on... I am just so confused. Is there a right way to right a C++ program? Are they all right ways? What does it all mean?

Thanks for any help,
Raistlin

code-frog14-Aug-05 19:00

14-Aug-05 19:00

You are definitely new to the language. As such I'm sure this is not your only set of questions and as you've said the list goes on. This is a really good book to get started:http://www.amazon.com/exec/obidos/tg/detail/-/0201485184/002-4765200-8896040?v=glance[^]

It gives a very compact overview of C++ and it does so in a pretty short text. It might work for you and maybe not.

As far as your questions go:

Google for overloading functions in C++ and the other is just the path in a *nix (Linux/Unix/Etc) environment to where python is installed. In most cases it will be in either /usr/local/bin/python or /usr/bin/python you can also set your system path to contain the absolute path to it as well. In windows it's working because you most likely have the path in your environment variables and the python installer probably did this for you.

What environment are you coding in?

At this point are you just trying to learn the language or is there a problem you are trying to solve using C++?

Do you have other programming experience that members here can use to explain things to as a comparison? If you've worked in Java or VB 6 then some things can be explained like, "In VB you did this to ..." and "In C++ you can do the same thing by ..."

- Rex

My name is Maximus Decimus Meridius, commander of the Armies of the North, General of the Felix Legions, loyal servant to the true emperor, Marcus Aurelius. Father to a murdered son, husband to a murdered wife. And I will finish this project, in this life or the next. Slightly modified " from Gladiator.

Code-frog System Architects, Inc.

Raistlfiren14-Aug-05 19:16

14-Aug-05 19:16

That is the bad thing, because I am not really new to all of this. I have two or three books on C++ and 1 book on java. I have also looked at numerous tutorials on the internet. I have spent many of hours looking at this monitor and at tutorials. Things just are not clicking, so to speak...

Those were some of the two things that baffled me the most though. I know that #include <iostream.h> or #include<stdio.h> are calling to different libraries, but if their different libraries why would you call them down... I am thinking now that there is a way to view these libraries or not? The first two parts just are not clicking as in the #include part and int main() or the other one. I mean I have wrote programs in C++ like just aa simple one for a card name called "Clabber" that adds up all of your non trumps cards and a few other things...

For Python I am pretty much starting, so right now Im in the process of learning it. I thought buying a book and trying to learn JAVA would be the answer to figuring out C++, but it really hasn't. Now as I look at Python it lookd rather easy to do. I am not too familiar with Visual Basic 6, because I haven't messed with it much... Other than that though, that is where I am at to programming. I know some of the basics I think...
Raistlin

code-frog14-Aug-05 19:35

14-Aug-05 19:35

If you are using Visual C++ go to C:\Program Files\Microsoft Visual Studio\ and somewhere in there is C++ directory and in there is an includes directory that has bajillions of include files. Don't mess with them at all but you can at least see them.

#include in the most simple form is just a way of telling the compiler that "IN ADDITION" to the code in these project files you are going to need to include these other files to run correctly. The includes themselves give you access to functions that are contained in the included libraries.

It sounds to me like you are in the *very* early stages of learning to cut code and I think taking on C++ is the BEST way to go. The confusion you describe is very common and happened to all of us at one point in time or another. Just remind yourself that they do call it Computer Science, it *is* an engineering discipline and many people go to school for 4+ years to learn it. You are taking it on all by yourself and it's going to be tough at first to figure out.

I won't bother you with the details but main() can be overloaded what this means is that one function name can have many arguments and the arguments determine which function gets called not the name itself. This is so far over your head right now though (and that's perfectly okay) that I wouldn't try to understand it. It's part of 3 main ideas though called Object Oriented. Those 3 ideas are Polymorphism, Inheritance and Encapsulation.

Let me see if someone here has written a decent article that can unwrap this nastiness for you. Gimme a few minutes and I'll see what I can find.

I cannot say this enough though. What you are feeling is totally normal for a lot of people. BEWILDERMENT is okay. Just don't give up. It might take several months but *SUDDENLY* you will get it and I'm not kidding. It will just flip one day in your head and you'll think SWEET!!! I finally get it. It takes time and it this is normal.

- Rex

Raistlfiren14-Aug-05 19:55

14-Aug-05 19:55

Aww man thanks. I didn't even know that area was there! Now, is there a way to understand any of this code in this stdio.h or istream.h? This looks like there is quiet a bit to all of this. Thanks for informaing me of that directory, that explains quiete a bit like where all those #include files are at!

Isn't Object oriented stuff also is JAVA. It has three levels below it like what you said. One code that pretty much defines the class of the object. Another one to test the object and the last one defines the objects variables and methods... For example this diagram:

SHAPES
l l l
SQUARE CIRCLE TRIANGLES
()rotate "" ""
()playsound "" ""

One main class that defines all classes in your project. Three subclass so to speak and your tests or what they are going to do...Is this what your talking about?

Raistlin

code-frog14-Aug-05 21:26

14-Aug-05 21:26

You are kind of talking about several things. You don't by chance have a book by Herbert Schildt called The C/C++ Complete Reference do you? http://www.amazon.com/exec/obidos/tg/detail/-/0072226803/002-4765200-8896040?v=glance[^]

This book gives perhaps the most comprehensive view of the C/C++ language I've ever come across. It's a big read but if you go all the way through it you will get good foundations in C and C++ and he covers Inheritance, Polymorphism and Encapsulation really well. He also takes you through good examples of each. The book is in it's 4th edition and is one of the most recognized books on C++ out there. It's a great book especially for beginners. I highly recommend it.

What you have described above is not quite correct. The programming model you describe Define, Test, Method doesn't exist. It sounds kind of scary. Every object you code will do what you describe above except for testing that's your job.

Read this for a basic idea of how squares, triangles and circles would relate to shapes http://cplus.about.com/od/beginnerctutorial/l/aa120502a.htm[^]

Think of it more like:

A werewolf "is a" wolf, a wolf "is a" canine a canine "mammal" a mammal "is a" animal an animal "is a" kingdom.

So a werewolf can do everything that a wolf does but a bit more. A wolf does everything a canine does but it does not beg like a dog nor does it kill Londoners like a werewolf. A canine is a mammal in that it breathes air, gives birth to live young, so does a wolf, so does a werewolf. A mammal does not live in water. An animal eats, sleeps, multiplies and is part of a kingdom an animal only eats, sleeps and multiplies. It does not give birth to live young because not all animals do.

As you move up the chain of inheritance from Kingdom to Werewolf each subsequent "is a" gets everything from it's base and can add to it. So werewolf gets everything that a wolf gets from canine and canine gets from mammal etc... You can implement kill() in canine because canine's kill to eat, so do wolfs and so do werewolfs. You cannot implement mutate() in canine because only werewolves mutate. Does this make sense?

Objects should be well defined objects that inherit base functionallity from other objects. Car would inherit everything in vehicle. Car.Drive() Car.Stop() Car.Go() if F1RaceCar inherits car it automatically can .Drive, .Stop and .Go without writing a line of code. F1RaceCar gets all that from Car. However F1RaceCar can add F1.Sponsor() F1.PitStop F1.PitCrewMember() but car does not need these thing and neither does vehicle.

You compose base functionallity and extend that functionallity using well define objects that build logically on top of their base. So what you get is.

#include canine

class werewolf()

You don't need to include "mammal" or "animal" because canine gives all of those to werewolf by design.

This is about as far as I'm willing to go in this because guys like Schildt do a better job. Get the book and read it 1 page at a time. Trust me, you really need to. Either that or get the book that Christian recommended. Just pick one. Go all the way through it several times. Don't jump from one book to the next. Pick one and stick it out. You'll be glad you did.

Raistlfiren15-Aug-05 10:46

15-Aug-05 10:46

Hehehe thanks for your information and time. I really do appreciate it.
Raistlin

code-frog14-Aug-05 19:52

14-Aug-05 19:52

I didn't see anything in the tutorials that was a good fit. Christian is an MVP for Microsoft C++ and that means he's been helping people for a long time. He might have some good advice at this point because what I'm about to tell you taps out mine. Learning this stuff is a bit like learning to ride a bike. You have to ride a lot and crash a lot before you internalize what it takes to ride a bike and then you'll never forget it.

My advice at this point. Go back to the books you have bought on C++ and go over them. Write all the examples and step through the programs. Read, re-read then read again the descriptions of the concepts involved. Relevant words to your questions right now are:

Inheritance - overloading

Things I think you should really focus on learning are the basics.

1. First learn and memorize (go over it until you can vomit it) the basic data types like int and char.
2. Then learn looping. for, while, do, etc...
3. Then learn how classes are written. This will cover function overloading, constructors, destructors and other key ideas.

If you get this far you are a long ways toward being really good. But to get this far you have lots of hours of struggling ahead of you.

Christian, do you have other ideas or suggestions? I only jumped in here because I ran this guy out of the lounge. You->MVP me C++ developer but not a teacher. I'll defer to your experience at this point.

- Rex

S. Senthil Kumar14-Aug-05 19:12

S. Senthil Kumar

14-Aug-05 19:12

Raistlfiren wrote:
Whenever I look at different tutorials I notice this:
#! /usr/local/bin/python
That's just to indicate to the shell as to where the python interpreter is present. I guess it's in your PATH environment variable, so you don't need that line of code.
Raistlfiren wrote:
Is there a right way to right a C++ program?
There are only two ways main can be written and you've listed both of them. The first one is used when you don't bother about command line arguments, the second one when you have to use them.

What other way did you find?

Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro

Raistlfiren14-Aug-05 19:24

14-Aug-05 19:24

Well, the other way was this :

#include <iostream><br />
<br />
using namespace std;<br />
<br />
int main()<br />
{<br />
  cout<<"HEY, you, I'm alive! Oh, and Hello World!\n";<br />
  cin.get();<br />
}

Yes it is the same way , but it has the "using namespace std;"... What does that represent? The other way doesn't have it... Just a little bit confused as you can see...
Raistlin

Christian Graus14-Aug-05 19:35

Christian Graus

14-Aug-05 19:35

All that stuff you're worried about are used when needed. Don't worry about them until you need them. using namespace:std will not change anything unless you're using someting in std. Don't worry about it until you know what that means.

Christian Graus - Microsoft MVP - C++

Christian Graus14-Aug-05 19:43

Christian Graus

14-Aug-05 19:43

Raistlfiren wrote:
Is there a right way to right a C++ program?

So long as main returns int and either takes these arguments, or takes none, it's right.

Raistlfiren wrote:
Are they all right ways?

Yes.

Raistlfiren wrote:
What does it all mean?

#include means to include an external file, and #include < > means to include a library file, not one in your project. For example, iostream is the streaming classes, string is the string classes. Note these files do not have .h after then, iostream.h is wrong.

The arguments in the second case are the number of arguments and the arguments passed on the command line, like when you type myProgram.exe /?, /? is the one argument, which is passed in.

namespaces are used to hide parts of the program from each other, namespace std is where the standard library sits. using namespace std makes all those things globally visible, otherwise you'd need to put using std::string, etc, for each class in std you want to use, or use std::string where-ever you used it in code.

I suggest you buy a book called 'Teach yourself C++ in 24 hours', I found that book very good when I was at your level of understanding. And obviously, keep asking those questions when you get stuck.

Why Python ?

Christian Graus - Microsoft MVP - C++

Raistlfiren14-Aug-05 20:28

14-Aug-05 20:28

So wait wouldn't this be right though: #include <iostream.h>? Sorry, for the wait, but I am trying to comprehend the second sentence :
Christian Graus wrote:
For example, iostream is the streaming classes, string is the string classes.
I don't quiet understand this right here... So are string classes the same as this : big = dog... String classes define words, like x = 8. So string classes are all of the classes that define words like if I were to say "cout << big" it would then say dog in the displayed text? Those are string classes?

Then, the file you type in command prompt is what the arguements define?

So where is this standard library at that defines namespace std? Then use std::string to define a library that is in the namespace library?

Christian Graus wrote:
Why Python ? I am kind of just trying out a whole bunch of programming languages, I currently have stuff on my computer for Perl, Python, C++, JAVA, visual basic, and dos batch files. A lot of those programs are ran by command prompt so they don't cost anything... I was looking at python though because it is multi platformed and is rather easy. Plus I was getting so annoyed at JAVA and C++, because I wasn't understanding it, that I was fed up with it. I was also loosing interest fast, so Python and perl kept me going for a little bit. Looking up good resources is rather hard sometimes...
Raistlin