Skip to main content
gamedev.net
🔒 Locked

[Solved] Strange Constructor Problem (C++ / Xcode)

Started by Riraito May 28, 2009 at 10:03 PM 9 replies 3.3k views
Original Post
Riraito
Riraito
I'm having a strange error in one of my constructors, a value set in the constructer of the base class (System) seems to have changed by the time it gets to the constructor of the derived class Here is the relevant code (unedited, except for where the '...' appears):


class System {
protected:
	
	EntityManager* m_manager;

	...
};

System::System(EntityManager* manager) {
	this->m_manager = manager;
	std::cout << "SystemCons: this = " << this << std::endl;
	std::cout << "SystemCons: manager = " << manager << ", m_manager = " <<	this->m_manager << std::endl;
}

class RenderBlockSystem : public System {
public:
	RenderBlockSystem(EntityManager* manager) : System(manager) {
		std::cout << "RenderBlockSystemCons: this = " << this << std::endl;
		std::cout << "RenderBlockSystemCons: manager = " << manager << std::endl;
		std::cout << "RenderBlockSystemCons: m_manager = " << this->m_manager << std::endl;
	}

	...
};

int main(int argc, char *argv[]) {
	EntityManager* m_manager = new EntityManager;
	std::cout << "EntityManager = " << m_manager << std::endl;
	
	RenderBlockSystem* m_renderSys = new RenderBlockSystem(m_manager);
	
	return 0;
}




I was beggining to suspect the IDE, so I stepped through it to check the values, the weirdest part was that it didn't show the values begin wrong at all... Debugger Picture I've tried cleaning the build, deleting the build folders manually, restarting xcode. I don't know what else to do, is there something wrong in the code? Any help would be greatly appreciated. Edit: the bitshift operator for std::cout is displaying strangely here, not quite sure how to fix that... [Edited by - Riraito on May 30, 2009 12:49:57 AM]
Sc4Freak
Sc4Freak
Are you sure you haven't redefined m_manager somewhere in your RenderBlockSystem class?
Riraito
Riraito
Quote:
Original post by Sc4Freak
Are you sure you haven't redefined m_manager somewhere in your RenderBlockSystem class?


unfortunately I'm quite positive :(, only a few other function declarations in there. No other globals either, although that shouldn't matter with the this-> in there.

swiftcoder
swiftcoder
Quote:
Original post by Riraito
No other globals either, although that shouldn't matter with the this-> in there.
Try casting it to void * before printing:

std::cout << (void*)this->m_manager << std::endl;

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]
Riraito
Riraito
Quote:
Original post by swiftcoder
Try casting it to void * before printing


No change. Upon a little more digging, it seems that internally the variable is stored correctly but whenever I pass it to a function (std::cout << m_manager) or call a function on it (m_manager->foo()) it uses the wrong value, usually '0xa0000000'. What could be causing this?
Riraito
Riraito
Alright well it looks like I fixed it for now, I changed:

class System {protected:	std::set<EntityHandle> m_entities;	EntityManager* m_manager; 	...};to:class System {protected:	EntityManager* m_manager;	std::set<EntityHandle> m_entities; 	...};


However I don't like this solution at all... Perhaps someone could enlighten me on why this worked, and how I could avoid it altogether (ordering of member variables really shouldn't matter should it?)
Blobberson
Blobberson
You're overriding the memory somewhere, you did NOT fix the problem, you only hid it. It will come back again later and be even harder to find if you don't fix it now.
Riraito
Riraito
Actually I think I figured it out now, the problem had to do with my memory allignment, I had previously done #pragma pack(0) which ended up putting m_manager on an odd byte, which I guess is why it sort-of half worked. Now that that's fixed it's all working well, thanks everyone!
swiftcoder
swiftcoder
Quote:
Original post by Riraito
Actually I think I figured it out now, the problem had to do with my memory allignment, I had previously done #pragma pack(0) which ended up putting m_manager on an odd byte, which I guess is why it sort-of half worked. Now that that's fixed it's all working well, thanks everyone!
Be very careful with the packing alignments: only pack POD structs, and make sure to pop the pack state immediately after. In general, packed structs should only be used for reading and writing legacy binary file formats.
Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]
Riraito
Riraito
Quote:
Original post by swiftcoder
Be very careful with the packing alignments: only pack POD structs, and make sure to pop the pack state immediately after. In general, packed structs should only be used for reading and writing legacy binary file formats.


Thanks for the tip, I have definitely learned my lesson this time :D

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.