PDA

View Full Version : basic inherited or vector problem?



mickey
13th February 2007, 02:27
class Network {
private:
Layer lay;
.....................
};

void Network::_create() {
lay._ne->resize(10);
}
//lay.h
#include "ne.h"
#include <vector>
class Network;
class Lay {
protected:
std::vector <Ne>* _ne;
friend Network;
public:
Lay();
~Lay();
};

Hi, I dont want use inherit for this program for my reasons.
Problems:
1. when resize is called program crash; I guess it happen because I'm working with vector of pointers...maybe they should be set to NULL (?). But how can I do this? Before resizing vector size is 0.....
2. when net.create() is executed; then why do I have to use 'class network, friend network'? (otherwise I can't access to member protected _ne). Wich is the reason? If I done a class as member I guess that I can do everything with that oblect.....
Are you understand?
Are there any other implementation of this ? (without inherit please)
thanks

mickey
13th February 2007, 14:33
I solved so:


Lay::Lay {
_ne = new std::vector<Ne>;
}

so memery is initialized and I can resize _ne everywhere. Is it correct? But maybe wasn't it better declare in lay.h std::vector <Ne> _ne; and not std::vector <Ne>* _ne; Any suggets?
I'm hoping for the 2nd question.....

Methedrine
13th February 2007, 14:43
It is dangerous to use a pointer to a vector because when the vector is resized it is very likely that it will change it's location inside memory and thus invalidate your pointer. So std::vector<Ne> _ne; is what you're looking for.
You have to declare Network as a friend because class A cannot access private or protected members of other classes (unless A is declared as a friend of the other classes). So what you are doing in your source-code is forward-declaring class Network and then telling your class Lay that Network is a friend and as such is allowed to access Lay's private/protected members.

jacek
13th February 2007, 19:16
when the vector is resized it is very likely that it will change it's location inside memory and thus invalidate your pointer.
Not quite, only the location of internal buffer will change. The object itself will remain where it was.

wysota
13th February 2007, 20:17
The problem here was that the poster was declaring a pointer to the object, but no object was created, therefore he was accessing random values in memory which didn't form a std::vector object which led to a crash. One has to differenciate between a pointer to an object and address of an object. Their values have the same type (object*) but creating a pointer doesn't create an object. I can have several pointers pointing to the same object (and that's the whole point of using pointers).


int var;
int *ptr1 = &var;
int *ptr2 = &var;
int *ptr3 = ptr2;
Now if I modify var ( var = 7; ) all pointers will still point to the same object, so dereferrencing them will still give me "7". Moreover if I now do:

int var2 = 5;
ptr2 = &var2;
ptr2 will point to var2, but ptr3 will still point to var. The bottom line is that pointers are not tied to any objects, they just point to a place in memory, regardless of its contents.

mickey
13th February 2007, 22:21
class Network {
private:
Layer lay;
.....................
};

void Network::_create() {
lay._ne->resize(10);
}
//lay.h
#include "ne.h"
#include <vector>
class Network;
class Lay {
protected:
std::vector <Ne>* _ne;
friend Network;
public:
Lay();
~Lay();
};
Lay::Lay {
_ne = new std::vector<Ne>;
}



Sorry, I'm a bit confused;
this above seems work. Is it dangerous or not?
I could create _ne as no pointer: std::vector <Ne> _ne; but Isn't better declare "pointer to" in the class (.h) and then do "new" in their constructors? (in terms of performance...)

jacek
13th February 2007, 22:43
Is it dangerous or not?
No, it's not, but don't forget to implement operator= and copy constructor.


but Isn't better declare "pointer to" in the class (.h) and then do "new" in their constructors? (in terms of performance...)
Why should it increase the performance? It might affect the compilation speed, because you can use forward declarations instead of #includes.

mickey
14th February 2007, 20:08
No, it's not, but don't forget to implement operator= and copy constructor.
sorry, but why copy constructor and = operator?? (I gues for lay class but why and = operator ???). Is there here a particularry purpouse?

jacek
14th February 2007, 21:29
Is there here a particularry purpouse?
Yes, it's because Lay::_ne is a pointer. The default copy contructor and operator= implementations will make a copy of that pointer, not the object it points to. In result Lay's destructor might delete that object more than once.

If you don't need operator= and copy constructor, you should just in case declare them as private (you can leave them unimplemented) or derive your class from boost::noncopyable.