Will clearing an already empty vector lead to undefined behavior?

What happens if I clear a vector which was already cleared before? I tried it out in Visual Studio and it did not lead to any run-time errors. But I'm hunting for a possible cause to an exception (below) And wanted to know if this could be the reason?

*** glibc detected *** process.out: double free or corruption (out): 0x01a0b588 *** 

Updating code:

bool myclass::Sort(SortType enSortOption)
{

  bool bRet = TRUE;


  m_oVecOfIntsOrig.clear();
  m_oVecOfIntsSorted.clear();

  for(int i = 0;i<m_oList.listsize();i++)
  {
    m_oVecOfIntsOrig.push_back(i);
  }
  m_oVecOfIntsSorted = m_oVecOfIntsOrig; 
  //Just sort the indices     
  switch(enSortOption)
  {
  case Alpha:
    { 
      t_SortStructAlpha sSortAlpha(this);
      sort( m_oVecOfIntsSorted.begin(), m_oVecOfIntsSorted.end(), sSortAlpha );        
    }
    break;
  case Dist:
    {        
      t_SortStructDist sSortDist(this);
      sort( m_oVecOfIntsSorted.begin(), m_oVecOfIntsSorted.end(), sSortDist );
    }
    break;
  case none:  
    {

      //Nothing to do
      return TRUE;
    }
    break;  
  default:
    {
      bRet = FALSE;

    }
    break;
  }

  //Update the list based on sorted index vector
  ListElem oSortedListElements;
  //this clear function simply clears all the 7 constituent vectors. 
  oSortedListElements.vClear();
  if(TRUE == bGetSortedList(oSortedListElements))
  {
    //If successfully copied to temp object, then update member variable
    //m_oList is what I'm intending to display
    m_oList.vClear();
    m_oList = oSortedListElements;
  }
  else
  {
    //copy failed
    bRet = FALSE;

  }
  return bRet;
}


bool myclass::bGetSortedList(ListElem& oSortedListElements)
{

  bool bRet = TRUE;

  //Creating object from beginning, so clear old contents if any
  oSortedListElements.vClear();
  /* Sort done. Now update the list based on new indices*/
  for(int u16Index = 0; u16Index<m_oVecOfIntsSorted.size(); u16Index++)
  {
    if(
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec1.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec2.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec3.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec4.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec5.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec6.size())
      ||
      (m_oVecOfIntsSorted.at(u16Index) >= m_oListConstituents.oVec7.size())
      )
    {
      //out of bounds check
      return FALSE;
    }
    //m_oListConstituents contains overall list
    oSortedListElements.oVec1.push_back(m_oListConstituents.oVec1.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec2.push_back(m_oListConstituents.oVec2.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec3.push_back(m_oListConstituents.oVec3.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec4.push_back(m_oListConstituents.oVec4.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec5.push_back(m_oListConstituents.oVec5.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec6.push_back(m_oListConstituents.oVec6.at(m_oVecOfIntsSorted.at(u16Index)));
    oSortedListElements.oVec7.push_back(m_oListConstituents.oVec7.at(m_oVecOfIntsSorted.at(u16Index)));     

  }

  return bRet;

}
开发者_如何学Python

If what you did amounts to

v.clear();
v.clear();

then no, there's no UB: one of the postconditions of v.clear() is that v.size() == 0, so the second call to clear should be a no-op.

Calling the clear method twice in a row should be fine. Your error looks like you are freeing something which was already freed. This can happen because you called free twice on the same object or possibly put an object in your vector which was then deleted. Calling clear on your vector would then cause that error (this is a problem because clear calls the destructor on any objects contained in the vector).

Edit:

at returns a reference so deleting something set to a value returned from an at might cause problems.