_HAS_ITERATOR_D EBUGGING and std::vector

[ngaloppo]

Hi,

I sometimes convert std::vector::it erators to pointers by the (afaik)
legal construct &v[0], e.g. in the construct below. In debug build, the
program terminates, because of what seems to be part of the new checked
iterators in VC8. OTOH, I thought that the code is perfectly legal. Is
it safe to temporarily disable _HAS_ITERATOR_D EBUGGING here? I feel
bad about just shutting up the compiler.

Thanks!

bool QuadsFileIO::Re ad(const std::string& fn, std::vector<flo at>&
verts, std::vector<flo at>& texcoords) {
ifstream ifile(fn.c_str( ), ios::binary | ios::in);
if (!ifile.is_open ())
{
std::cout << "Warning: Couldn't open file for reading " << fn <<
std::endl;
return false;
}

typedef std::vector<flo at>::size_type size_type;
size_type size;
ifile.read((cha r*)&size, sizeof(size_typ e));

verts.resize(si ze);
texcoords.resiz e(size);

ifile.read((cha r*)&verts[0], sizeof(float) * size);
ifile.read((cha r*)&texcoords[0], sizeof(float) * size);

ifile.close();

return true;
}

[Holger Grund]

> I sometimes convert std::vector::it erators to pointers by the (afaik)

legal construct &v[0], e.g. in the construct below. In debug build, the
program terminates, because of what seems to be part of the new checked
iterators in VC8. OTOH, I thought that the code is perfectly legal. Is
it safe to temporarily disable _HAS_ITERATOR_D EBUGGING here? I feel
bad about just shutting up the compiler.

&v[0] is perfectly valid so long as v has at least one element.
You should check that size != 0.

Otherwise, I fail to see why iterator debugging would cause
problems here. Can you get us the exact diagnostic and the call
stack?

-hg