2 questions

[fmasroor]

2 questions that I have always wondered about:
1. On my compiler, I have to use

#include "stdafx.h"
#include <iostream>
#include <Windows.h>
using namespace std;

and not

#include "stdafx.h"
#include <iostream.h>
#include <Windows.h>

Please explain the difference between these 2. (c++)
2. Why use pointers when the array can be declared as global?

[Narue]

1) <iostream.h> is an old style header that's no longer supported by modern compilers. Your compiler is correct in forcing you to use the standard <iostream> header, which also wraps everything in the std namespace.

2) Your question is nonsensical. Please provide an example of using pointers that's improved with a global array.

[mrnutty]

using namespace std;

your probably confused about what the above does. Look up 'C++ namespace'. In short, it makes public data that is in std namespace in your current scope. So instead of doing std::cout << "hello" you can simply do cout << "hello";. Notice I didn't have to specify the namespace std when using the cout object. Thats because when you write using namespace your basically telling the compiler to find variable in std namespace if not found in current scope. Of course thats a oversimplification.

[thines01]

What type of app are you creating?
There are LOTS of options.

[Schol-R-LEA]

2. Why use pointers when the array can be declared as global?

I assume you're talking about passing arrays to functions, in which case the answer is, because global variables in general are a Bad Thing, or at least enough of a bad thing that you will want to use them sparingly if at all. Now, admittedly, this leaves out a bit of explanation, but the real issues has to do with visibility, namespace pollution, and uncontrolled access of global data. If that doesn't help, I'll try to explain a bit more.

First off, when you make a global variable, you take up a part of the global namespace. In a large program, if you have a lot of globals, sooner or later you (or some other programmer you're working with) are going to lose track of what names have already been used, and get a namespace collision - that is, you'll declare two different variables with the same name, and then wonder why a part of the program that was working fine before suddenly broke. Even if you manage to avoid this, you most likely will end up having to use awkward work-arounds in order to avoid repeating names. It is easier all around to limit as many variables as possible to local scope, which means that if you want to share them with other functions, you need to pass them to those functions as arguments.

The second part of this is related to the first, which is the issue of scope and visibility. As a rule, you want to limit the scope of variables to as narrow a field as possible; this is because the greater the scope, the greater the risk of changing the wrong data structure - either directly or indirectly - by accident.

The third issue, uncontrolled access to the data structures, is a problem partly for the reasons already given but also because you want to be able to tell from the function prototypes alone what data structures a given function effect. Global data structures present a problem for this, because any function out there might change them, and the only by peeking around inside the functions can you be sure whether or not a given function affects it. To put it another way, each global variable adds exponentially to the possible side effects each function may have.

[fmasroor]

I get what you're saying. But, itsn't manipulating them from a seperate function the whole idea of pointers?

[Schol-R-LEA]

While that is one of the uses of pointers, it is not the whole purpose or even the main purpose of them. Still, I'll address the question in two parts.

First, speaking of functions generally, it is better to pass an argument explicitly rather than having access to it implicitly, because it makes it clear what the function is operating on. I've already explained the reasons for this, so I won't go into them again.

More importantly, it separates the function from the data it is manipulating, allowing you to apply it to a different data structure each time it is called. This is important because it allows you to write code in a 'modular' fashion, that is, you can break a program down into separate sections and use different sections of the program repeatedly.

For example, let's take the function strcpy(), the old C-style string copy function. It takes two arguments, one for the destination array and the other for the source array. By using pointers to the arrays, the function can be applied to any two string variables, without knowing ahead of time what arrays they are or even how long they are. If you didn't have this flexibility, you'd need a separate function for copying one array to another for every two pairs of arrays you might want to copy! Whereas with pointers, you can manipulate the arrays without knowing anything but the address where they begin (and where they end, though with C-strings that is implicit in the string itself).