2013-03-27 12 views
0

一些我如何在xcode,C++中創建漏洞列表。 所以在我的iOS項目我已填充自定義對象的列表,如:xcode中的漏洞C++列表

 int i=0; 
     while (rawArr->isObject(i)) { 
      Object::Ptr object = rawArr->getObject(i); 
      SRComplexType* sr = new SRComplexType(object); 
      refs.push_front(*sr); 
      delete sr; 
      i++; 
     } 

這似乎有些漏水這裏雖然我加了一個解構刪除所有對象:

for(std::list<SRComplexType>::iterator list_iter = refs.begin(); 
    list_iter != refs.end(); list_iter++) 
{ 
    list_iter->~SRComplexType(); 
} 

}

SRComplexType包含:

std::string sNo; 
std::string sName; 
std::string sUrl; 
LocationComplexType *sLocation; 

s位置(只包含兩個雙打和一些方法)使用設置:

this->sLocation = new LocationComplexType(locationObject); 

在LocationComplexType雙打使用設置:

double d; 
    const char * str = LatRaw.convert<string>().c_str(); 
    sscanf(str, "%*[^0-9]%lf",&d); 
    free ((void*) str); 
    this->longitude=d; 

文書泄漏報告中說明:

Leaked Object # Address Size Responsible Library Responsible Frame 
Malloc < varying sizes > 17 <multiple> 384 Bytes libstdc++.6.dylib std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) 
Malloc 32 Bytes 17 <multiple> 544 Bytes PocoTest2 std::list<SRComplexType, std::allocator<SRComplexType> >::_M_create_node(SRComplexType const&) 
Malloc 16 Bytes 1 0x72f2140 16 Bytes PocoTest2 -[ViewController viewDidLoad] 
Malloc 3.00 KB 1 0x7c6ca00 3.00 KB libstdc++.6.dylib std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) 
Malloc < varying sizes > 17 <multiple> 560 Bytes libstdc++.6.dylib std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) 
Malloc 32 Bytes 17 <multiple> 544 Bytes libstdc++.6.dylib std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) 
+0

@cli_hlt該對象並不是新鮮的,因此不需要調用delete或析構函數。 – juanchopanza 2013-03-27 09:39:45

回答

3

它看起來像你的列表持有SRComplexType對象,所以這裏不需要動態分配。只需通過SRComplexType

refs.push_front(SRComplexType(object)); 

沒有必要刪除列表中的元素。

如果SRComplexTypeLocationComplexType是動態分配的,你必須確保你跟隨rule of three或使用smart pointerboost::scoped_ptrstd::unique_ptr將是很好的候選人)。

+0

這是正確的,但不能解釋爲什麼上面的代碼泄漏。我會查找'SRComplexType'中的錯誤。 – john 2013-03-27 09:32:37

+0

@john我認爲沒有足夠的信息來知道它爲什麼會泄漏,但應用我建議的修復程序應該可以解決問題,或者至少縮小它的範圍。 – juanchopanza 2013-03-27 09:37:03

+0

謝謝@juanchopanza。現在的泄漏減少到: malloc的32個字節\t \t 544字節\t \t PocoTest2 :: StoreRefComplexType反序列化(波索:: SharedPtr <波索:: JSON ::對象,波索:: ReferenceCounter,波索:: ReleasePolicy >) – 2013-03-27 09:58:47