Quote:Original post by Kenoli Am I doing this right? http://cma.zdnet.com/book/c++/index.htm
I started on this a long time ago. I got up to about day 6 and stopped for some unknown reason. Maybe I'll try again. :o
I'm not sure what your question is. If you're asking whether that's the right book, then the answer is no. From what I've read of it, second edition seems to use pre-standard C++ (#include <iostream.h>).
I've been using Open Watcom 1.5, if I'm behind I'm sorry took me a little while to figure it out but http://gravesworld.org/c++1.html :) havn't figured out how to debug :( tho I'll figured it out.
As to this: #include <iostream> int main() { int x = 5; int y = 7; std::cout << std::endl; std::cout << x + y << " " << x * y; std::cout << std::endl; return 0; }
Hmm.. my guess is that random numbers?
heya
this is the line that gave me a clue on what that example gave
std::cout << x + y << " " << x * y;
then look at the begining of the code and see what x & y are should be pretty clear
IDEs So, most of you taking the workshop have hopefully by now gotten setup with an IDE, and have your first programs compiling and running successfuly. The textbook tells you that IDE stands for Integrated Developement Environment but doesn't really tell you what your IDE does for you or how it goes about doing it. Just like having a firm grasp of the language is nessecary to be able to use the language effectively, knowing what your IDE does and how it does it is important to know when you have to use it. It is also important to know why we use them at all.
Not all IDEs are created equal and some are more fully featured than others, but all the ones likely to be used with this course (The various flavours of Visual C++, Dev-C++, Code::Blocks) as well as others share a lot of key features.
Building When you tell your IDE to Build, (Compile in some IDEs), your first program, you see the text change in the output window at the bottom of your IDE and hopefully at the end you see "0 Errors, 0 Warnings". The text book tells you that this means that it is taking your source file, compiling it into object files, and then linking them into an executable. But how is it doing all this. (Page 15 summarizes this process of compiling and linking)
Your IDE doesn't actually do the compiling and linking itself. The programs responsible for these are independant command line programs. In the case of Visual C++ the compiler is cl.exe and the linker is link.exe, for Dev-C++ and Code::Blocks the compiler is g++.exe and ar.exe is the linker.
The IDE passes each .cpp file to the compiler program, which generates the .o object files. You'll notice in most of the sample apps we #include <iostream>. Page 21 of the text tells us that this is a command to the preprocessor to find the file named iostream and place its contents right here, before compilation starts. But where is this file, iostream? It's not in the same folder as your .cpp so where does the compiler know where to find it? This is one of the jobs your IDE takes care for you. As well as passing the name of the .cpp file to be compiled it also tells the compiler where it can find all these standard include files. There are also many other "flags" which can be passed to the compiler telling it how to compile the .cpp file. So the IDE passes each source file to the compiler, along with the list of include directories and flags, and results in the .cpp file being turned into a .o file. What about compile time errors? The output of the compiler is caught be the IDE and printed into the output window towards the bottom of most IDEs. So if you were to run the compiler from the command line manually, you would see much the same information you see in your IDE.
So now your .cpp files have been turned into .o files. Its time to combine them together into a single executable. This is where the linker comes into play. Unlike the compiler, which is called once for every source file, the linker is only called once and the IDE passes it the names of all the .o files created by the compiler. Just like each .o file contains data from your code that will be combined together to create you .exe, sometimes extra external files are linked to project. These are often .lib or .a files. You needn't worry about these at all yet, but take it on faith for now that your IDE helps sort out which ones get combined with your project.
Now it should be clear that the IDE automates a lot of the build process. You give it your .cpp files and for our simple apps it'll make sure that the compiler and linker get all the info they need automatically. All these settings that are sent to the compiler and linker can be edited in the IDE, and allow you to add or remove things when nessecary for your project, but again, there is no need to worry about doing that for a good while.
Projects Most IDEs use the concept of a "project" to help manage your code. So far you have only ever been working with a single .cpp file at a time, so managing them isn't an issue. But in the future as your projects get larger you will have many many files, possibly split into several directories. And you might have large numbers of specific paramaters to pass to the the compiler and linker. This is where the concept of a project is handy. It contains references to all the source files in the project and contains the information about how the project should be built.
You will notice that in most of the instructions for creating your first "hello world" program, you were asked to select win32 console program or some synonomous option. This means that the project is created with all the settings required to build a standard win32 console program. If you had selected a "win32 dll" or equivilent your project would have been created with different settings. Right now you don't need to know anything about these project settings, except that picking the appropriete type at creation time is vitally important.
Debugging Another of the most important features in an IDE is its debugging facilities. Debugging is the term used for tracking down and fixing bugs in your programs. The compiler will tell you the errors in your code, but sometimes your code doesn't work the way you expect it to and you have to find out how. I won't describe the methods of debugging here, that deserves a lot more space than I can afford it at the moment. The debugger allows us to pause the program at almost any given point and examine the state of variables. The IDE makes this process very simple with facilities like easily placing breakpoints and windows which display the values of local variables. This is extremely useful for tracking down bugs and it becomes increasingly more useful as the project gets bigger and solving a problem using other means gets increasingly more difficult.
These are only some of the more common features in IDEs, there are many more. But it should be obvious now why they are used, and hopefully the build process is a bit clearer.
Quote:Original post by jflanglois: To jwalsh: I suggest you change the instructions for a new project to use "Win32 Console Application" instead. [edit] And select "Empty Project" in "Application Settings" in the dialog box that pops up.
Indeed. My instructions for creating an empty project are the bare minimum for creating a working application. Unfortunately, using an empty project as I described doesn’t provide enough settings for the IDE to make debugging possible without further modification to the project properties. I'll update my posts to reflect an alternate setup.
Is there an advantage to using the method in the code below...
#include<iostream>int main(){ int x = 5; int y = 7;std::cout<< std::endl;std::cout<< x + y << " " << x * y;std::cout<< std::endl; system("PAUSE"); return 0;}
Versus, let's say, this code?
#include<iostream>int main();using namespace std;{ int x = 5; int y = 7;cout<<"\n";cout<< x + y << " " << x * y;cout<<"\n"; system("PAUSE"); return 0;}
They both give the same result, but the top one seems like it would be easier to manage on bigger projects. Or are there situations where that is not true? Sorry for the noobish question......but then again.....I am a noob.
Quote:Original post by Joelvtx Is there an advantage to using the method in the code below... ... They both give the same result, but the top one seems like it would be easier to manage on bigger projects. Or are there situations where that is not true? Sorry for the noobish question......but then again.....I am a noob.
The former method involves less namespace pollution, for example if you wanted to use the name 'cin' or 'endl' for an object in your program, you'll be assured as to which one you're getting if you don't just wholesale include a namespace.
An optional way to get the best of both worlds is...
using std::cout;using std::endl;...cout << blah << endl;
That way you know which items have been included from the std namespace and won't get namespace conflicts, but also don't have to type the fully qualified names of the things you'll be using.
Quote:Original post by Joelvtx Is there an advantage to using the method in the code below...
*snip*
They both give the same result, but the top one seems like it would be easier to manage on bigger projects. Or are there situations where that is not true? Sorry for the noobish question......but then again.....I am a noob.
A few notes:
-I would avoid "using" directives. They can cause problems if you have another class with the same name. It also generally helps make your code much clearer.
-Use "std::endl" instead of "\n". std::endl does more than kick to the next line; It flushes the buffer to the screen. This isn't so important with console output, but makes a difference for file output. Also, I believe some operating systems may require more than just an endline (such as a carriage return), so it's best to keep your code platform independent.
-Do not use System("PAUSE") ever. It is non-standard and probably platform dependent. Also, when running a console app from the console, it is going to be redundant and annoying if your program pauses at the end. If you want the window to stay up, either run it from the console, or "start without debugging".
Sean Henley [C++ Tutor]Rensselaer Polytechnic Institute
@jflanglois Hmm.. what compiler should I use tho I have Dev C++ but it's pak installer doesn't work, other wize it run fine :), btw what's a STL implementation?
