   [Solved] Strange Constructor Problem (C++ / Xcode)
  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 classHere 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 PictureI'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]
  Are you sure you haven't redefined m_manager somewhere in your RenderBlockSystem class?   ;Quote:Original post by Sc4FreakAre 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.;Quote:Original post by RiraitoNo 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;;Quote:Original post by swiftcoderTry casting it to void * before printingNo 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?   ;  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?)   ;  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.   ;  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!   ;Quote:Original post by RiraitoActually 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.   ;  I've had this problem before as well. Misuse of #pragma pack can very easily cause ODR violations - which are really nasty to debug.   