tags:

views:

209

answers:

4

My class has this member.

  std::vector<AvaWrapper> m_controls;

In my constructor I call

  m_controls.clear()

Then I call a member function that does m_controls.clear() again but it blows up with an assert. The debugger shows that m_controls has a half million or more entries though none of them are valid cause the debugger shows "Error: expression cannot be evaluated" when I expand the tree. So, my intuition is that the class is not created correctly cause this code did work but I later derived a class from this class and I call new() to create the parent. In it's new role as a base class it's blowing up. The this pointer however shows all the other member variables have valid data so my hunch is wrong. The constructor is getting called too. Any ideas? Thanks.

UPDATE2:

Train::Train() : SpriteWindowFrame(200)
{
  s_mutexProtectingTheGlobalData = new wxMutex();
  m_window_rect = NULL;
  m_thread = NULL;
  m_ok = false;
  m_accumulate_timer = new wxTimer();
  m_accumulate_timer->SetOwner(this, ACCUMULATE_TIMER_ID);

  m_autohide_timer = new wxTimer();
  m_autohide_timer->SetOwner(this, AUTOHIDE_TIMER_ID);

  m_autohide = false;
  m_autohide_period = 5000;
  m_controls.clear();
}

UPDATE:

//This version works.
SpaceInit::SpaceInit()
{
  //Use INI config store. If you need something else, just
  //create the appropriate object.
  m_config_store = new IniConfigStore();

  //Start up config. 
  Init(); 

  m_t = new Trains();
  return;
}

SpaceInit::~SpaceInit()
{
  wxDELETE(m_config_store);
  return;
}

I can do this: m_t->SomeMemberFunctionThatManipulatesVector()

and it works.

This one does not

SpaceInit::SpaceInit():Trains()
{
  //Use INI config store. If you need something else, just
  //create the appropriate object.
  m_config_store = new IniConfigStore();

  //Start up config. 
  Init(); 
  return;
}

I can't do: SomeMemberFunctionThatManipulatesVector()

blows up on vector.

I've just noticed that the this pointer really is messed up inside the Train() default consturctor. I thought it wasn't but it is. The Trains constructor runs but everything is trashed.

My Trains constructor code is run of the mill. Just initialize things, new a couple things, etc. The SpaceInit is created with SpaceInit* t = new SpaceInit(); Train is a derived class so maybe that has something to do with it?

+7  A: 

There's a problem with this statement:

I later derived a class from this class and I call new() to create the parent.

When you derive from a class, you do not call new() to create a parent. The parent constructor is already called before the first line of the child constructor is run.

I suspect that your problem might be around this area. Perhaps you could show us the code where this is happening.

Andrew Shepherd
+1 for me for giving a first diagnosis without yelling 'GIEV CODE!'. In particular, the 'give me all relevant code' comment to the question is useless since the creator of the question probably does not know what's relevant, and what's not.
Frerich Raabe
+1  A: 

Since you seem to have RAW pointers (hard to tell as we don't have the definition of SpaceInit). Have you defined the copy constructor and assignment operator. If not you could potentially be accessing destroyed objects which would lead to undefined behavior included overwriting other members.

Martin York
No. I don't have much experience overloading these operators. Why would this be required? I'm not cloning or copying the objects.
max
There are a lot of opeations that cause objects to be copied that are not obvious. If you are sure they are not being copied the define the copy/assignment operators as private and see if the code still compiles. If it does you are safe otherwise you have a problem.
Martin York
+1  A: 

I'm with @andrew-shepherd. Since you got different results when you changed initialization order of the class Trains, I strongly recommend you check all the base and derived classes about the "initialization list."

If you were not allowed to show the specific code snippet, please at least ensure all data member of each class were on the initialization list, not in the ctor.

Mike Jiang
oh, they are in the constructor. Would moving them to the initialization list make a difference?
max
In C++ it's always a better idea to use initialization list, a part of reason has been given by @dominolog. Since you got difference behavior on different new() orders of derived class, especially around IniConfigStore and Init(), which we don't know what it did here, it's worth to check all the initialization progress. Using the initialization list is one of the easiest way to keep them safe.
Mike Jiang
A: 

Hello

I'm just geuessing that the Init method is virtual. The rule no. 1 is you shall not call virtual methods from ctor because object may not be initialized properly.

Regards

dominolog