повреждение функции vector.resize памяти, когда размер является слишком большим

Я НАСТОЯТЕЛЬНО предлагаю вам проверять свои данные на наличие повреждений ПЕРЕД вызовом библиотечных функций с, возможно, неправильными аргументами!

Используйте какой-то хэш-код или алгоритм проверки суммы для ваших пакетов. Вы не можете рассчитывать на то, что библиотека вам поможет, поскольку она не может: Возможно, вы дадите ему поврежденный, но все еще действующий (с точки зрения библиотеки) размер, который действительно велик, поэтому он выделяет, например, 768 МБ ОЗУ. Это может сработать, если в системе достаточно свободной памяти, но может выйти из строя, если на вашем компьютере размером 1024 МБ работают другие программы, которые потребляют слишком много памяти.

Итак, как сказано выше: Сначала проверьте!

Я понятия не имею, что вы имеете в виду, когда говорите «изменение размера повредило память». Как вы это определяете?

FWIW, я не согласен с ответом Майкла . Если std :: vector <> :: resize () вызывает расширение вектора, я вижу две возможности:

1. Либо один из конструкторов, используемых для заполнения нового пространства (или копирования элементов), либо
2. распределитель, используемый для увеличения вектора, сделал
3. или вектор, который заранее определил, что запрошенный размер слишком велик, и выбрасывает.

С помощью std :: vector мы можем безопасно отклонить №1, так что остается №2. Если вы не t использовать какой-либо специальный распределитель, тогда следует использовать std :: allocator и, AFAIK, который вызовет new для выделения памяти. И новый выбросит std :: bad_alloc . Однако вы говорите, что не можете этого поймать, поэтому я не знаю, что происходит.

Что бы это ни было, оно должно быть производным от std :: exception , чтобы вы могли сделать это, чтобы узнать:

try {
  my_vec.resize( static_cast<std::size_t>(-1) );
} catch(const std::exception& x) {
  std::cerr << typeid(x).name() << '\n';
}

Что это в результате?

В любом случае, что бы это ни было, Я почти уверен, что это не должно испортить память. Либо это ошибка в вашей реализации std lib (маловероятно, если вы спросите меня, если вы не используете очень старую версию), либо вы сделали что-то не так в другом месте.

Отредактируйте теперь, когда вы сказали, что используете VS6 ...

Вы должны были сказать это раньше. VC6 был выпущен более десяти лет назад, после того, как М.С. проиграли свой голос в комитете std, потому что они слишком долго не появлялись на собраниях. Реализация std lib, которую они отправили, была от Dinkumware (хорошая), но из-за юридических проблем она была для VC5 (очень плохо), в которой было много мелких и крупных ошибок и даже не было поддержки шаблонов участников, хотя компилятор VC6 поддержал это. Честно говоря, чего вы ждете от такого старого продукта?

Если вы не можете переключиться на достойную версию VC (я бы порекомендовал хотя бы VC7.1, также известный как VS.NET 2003, поскольку именно эта версия сделала большой скачок в сторону соответствия стандарту), по крайней мере, посмотрите, Dinkumware до сих пор продают VC6t-версию своей превосходной библиотеки. (На самом деле, я был бы удивлен, но раньше они были, и мало ли ...)

Что касается исключений: В более ранней версии VC (это включает VC6 и не включает VC8 aka VS.NET 2005, хотя я не уверен насчет VC7.1) по умолчанию нарушения доступа могли быть пойманы с помощью catch (...) . Так что, если такой блок catch что-то поймает, вы не узнаете, было ли это исключением C ++. Я бы посоветовал использовать catch (...) только вместе с throw; , чтобы исключение прошло. Если вы это сделаете, вы получите настоящий сбой в AV и сможете отслеживать их в отладчике. Если вы этого не сделаете, антивирус будет проглочен, и тогда вы застрянете с приложением, которое пришло в ярость, даже если вы не знали. Но делать что-либо, кроме прерывания работы с AV-приложением, не имеет смысла. AV является одним из результатов неопределенного поведения , и после этого все ставки отменяются.