multifile projects; Visual Studio; multiple errors

[dobby156]

I have done a little C++ now (previous java, c#) so far I have just made single file programs (short algo's mainly) and compiled them with G++.

now I am ussing VS (2010B2) and I could do with some help putting classes into header files ect...

am I right in thinking that the header file contains all the defining infomation about a class (and it methods)

Here is what I **think** I should be doing. I know this example doesn't even require the use of header but it will grow.

ok:

Rectangle.h

#include <iostream>
using namespace std;

class rec
{
private:
	int a, b;
public:
	rec(int, int);
};

Rectangle.cpp

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

rec::rec(int x, int y)
{
	a = x;
	b = y;

	cout << "constructed" << endl;
}

Program.cpp

#include <iostream>
#include <string>
#include "Rectangle.h"

using namespace std;

int main(int argc, char *argv[])
{
	rec *k = new rec(2, 3);
	cout << "Output" << endl;
	string input = "";
	cin >> input;
	return 0;
}

Output

constructed
Output

The code clearly compiles and provides the expected results. So I must be doing something right. yet intelisense is pretty much dead and I get the following errors.

Rectangle.cpp

1 IntelliSense: name followed by '::' must be a class or namespace name
2 IntelliSense: identifier "a" is undefined
3 IntelliSense: identifier "b" is undefined

Program.cpp

1 IntelliSense: identifier "rec" is undefined
2 IntelliSense: identifier "k" is undefined
3 IntelliSense: expected a type specifier
4 IntelliSense: expected a ')'

If anyone could help me, I would love to know whether I am doing this correctly, why I am getting all these errors, why there are red lines under anything I use from another file.

Thank You.

[Disch]

Everything is right with your code except for one thing:

You're not deleting your 'k' object. C++ doesn't have garbage collection like Java, so every time you use new, you must have a coresponding delete:

int main(int argc, char *argv[])
{
	rec *k = new rec(2, 3);  // allocated with new...
	cout << "Output" << endl;
	string input = "";
	cin >> input;
	delete k;  // ... so you must delete it when you're done
	return 0;
}

Alternatively, you can put your object on the stack so you don't need new/delete:

int main(int argc, char *argv[])
{
	rec k(2,3);  // made without new...
	cout << "Output" << endl;
	string input = "";
	cin >> input;
	// ... so you don't delete it
	return 0;
}

This is not recommended for objects which are very large, though. There's pros and cons to using the stack vs. the heap. But that's another topic.


As for your intellisense problem, my guess is that it's not finding your header for whatever reason. I don't have a clue why, though. Only thing I can think of is to make sure Rectangle.h is part of your project.

[dobby156]

sorry my bad, I know it should deleted, bad habits.

if I could just open this can of worms; I know the difference between a object and pointer, but I really don't get when I should use one rather than the other.

OK the intellisense has just fixed itself, maybe this VS2010Beta2 is still a little rough.

thanks for your help

[Disch]

Variables declared in functions (without 'new') are put on the stack.
Variables dynamically allocated are put on the heap.

Aside from the not-having-to-delete thing.... without getting too much into it, here's a very simplistic tradeoff:

- There is more heap space, but it's generally slower to access
- There is less stack space, but it's generally faster to access

There are other weird things to know too, though. strings and vectors, for example. The classes themselves are very small, and internally they put their buffer on the heap. So even if you have a vector on the stack, the actual array data will be on the heap... so it's typically better to put vectors and strings on the stack.

Where it gets hairy is when you have a structure/class that has very large members:

struct Foo
{
  int huge[100000];
};

int main()
{
  Foo ouch[100];  // 100000 * 100 * sizeof(int) bytes on the stack!
   // ouch!!

  return 0;
}

For something like that, because 'Foo' is so large, you're generally better off putting it on the heap.

[helios]

There is more heap space, but it's generally slower to access

...What?
Memory is memory. It's true that allocating heap space is more expensive, but that nothing to do with actually using the memory.

[Disch]

Er

It made sense in my head when I said it, but I can't find the logic behind it now.

Then again it was 7 AM when I made that post.

nevermind. XD