Re: [VS2008 SP1][std::vector] _CRT_DEBUGGER_HOOK crash in Release mode only -- [SOLVED by work-around]
Tobias Alte wrote:
BOOL CReportData::GetSubItem(INT iSubItem, [...])
{
INT iText;
if ((size_t)iSubItem >= dataItems.size() || dataItems.empty())
return FALSE;
std::list<REPORT_DATA_ITEM>::const_iterator iter;
int i = 0;
for(iter = dataItems.begin();
iter != dataItems.end(), i < iSubItem;
iter++, i++);
REPORT_DATA_ITEM data = *iter;
There are several things to note here:
1. I would use size_t instead of INT in the interface already. One important
point is that you do an explicit (C-style *spit*) cast once to check if the
index is correct but not while iterating over the sequence.
2. The check for empty() is redundant and I would at least use brackets
there to make evaluation order clear.
3. There is a function std::advance which does exactly what you do in the
for-loop. ;)
4. In the condition ("y" in "for(x;y;z)"), you evaluate the iterator against
end() and then discard the result by using the comma operator.
In the original version, you first checked the index and then use
vector::at() to retrieve the element. This is redundant, since at() signal
out-of-range indices using an exception. Two ways:
// I
try {
... = at(index);
return TRUE;
} catch(std::exception const& e)
TRACE(_T("GetSubItem(%i): %hs\n"), index, e.what());
return FALSE;
}
// II
if(index >= size())
return false;
... = operator[](index);
Note that you can explicitly invoke [] by its name, too.
Which solves the issue. What I am still somewhat curious about is the
"Why?" obviously. Even if I use the same iterator code for the vector
instead of the std::vector::at(...) the problem persists.
Your original code had an index that was out of range, hence at() threw an
exception which your program was not prepared to handle.
Is it possible that the std::vector implementation has some problems
with the structure it is supposed to store? Maybe something the
std::list container handles better?
You can create types that can't correctly be handled by std containers, but
the problem applies to all of them. In particular when the type is copyable
and assignable, i.e. is a real value type and not a (polymorphic)
entity/object, chances are good that it is handled correctly.
BTW: as an alternative to aggregation or public inheritance, there is also
private inheritance (read "is implemented in terms of"). You can afterwards
make those parts public that you want public with using directives:
class wrapper: vector<int> {
typedef vector<int> container;
public:
using container::iterator;
using container::const_iterator;
using container::begin;
using container::end;
};
Same interface, using aggregation:
class wrapper {
typedef vector<int> container;
container m_content;
public:
typedef container::iterator iterator;
container::const_iterator const_iterator;
iterator begin() { return m_content.begin(); }
iterator end() { return m_content.end(); }
const_iterator begin() const { return m_content.begin(); }
const_iterator end() const { return m_content.end(); }
};
Note that to the outside, those really provide the same interface, allowing
you to change some code behind the scenes. This won't fix your immediate
problem though. ;)
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932