Boost:: multi_array изменение размера?

Я пытаюсь выяснить, может ли метод boost:: multi_array или метод изменения размера генерировать исключение bad_alloc (или какое-либо другое исключение, указывающее, что сбой распределения или изменения не удалось). Я не могу найти эту информацию в документации.

Разъяснение (добавлено из комментария):

Это научный алгоритм, который может вернуться к менее интенсивному (более медленному) методу памяти, если сбой распределения. В основном есть два динамически распределенных 3-мерных массива для хранения "расстояний" (корреляции) между всеми парами генов в запросе и всех генов в наборе перекрестной проверки для каждого из большого количества наборов данных. Более медленный метод пересчитывает каждое расстояние "на лету" по мере необходимости. Это для С++-версии существующей реализации Java, которая реализовала оба метода и отпала бы от исключения из памяти. Я действительно не ожидаю, что у вас не хватит памяти.

3 ответа

1-й: (отвечая на реальный вопрос): поскольку он использует динамически распределенную память, да, он может бросать std::bad_alloc (я никогда не видел исключений форсированного перевода std::bad_alloc, это было бы сумасшедшим для этого).

2nd: (прокомментируйте ваше разъяснение): вам нужна информация о доступной физической памяти для оптимизации производительности вашего алгоритма во время выполнения. Однако вы не можете полагаться на std::bad_alloc, чтобы определить, сколько памяти у вас доступно, поскольку современные операционные системы используют такую ​​вещь, как overcommit, а это означает: они (почти) никогда не возвращают неудачную попытку размещения, а вместо этого просто дают вам некоторую "память" ", который не сможет появиться, только когда вы попытаетесь получить к нему доступ.

В Java это может работать, поскольку виртуальная машина делает много вещей для вас: она пытается выделить некоторые непрерывные фрагменты памяти и делает это в отношении доступной физической памяти и доступной неиспользуемой физической памяти, чтобы решить, стоит ли ее подчеркивать GC больше или просто выделяет больший барахт. Кроме того, по соображениям производительности вам нужно учитывать, что виртуальная память и физическая память - это совершенно разные понятия.

Если вам необходимо оптимизировать производительность для ваших алгоритмов (что может быть необходимо, в зависимости от вашей области работы), вам нужно проверить свои специфичные для платформы функции, которые могут рассказать вам, как выглядит "реальный мир" как.


Почему бы не проверить его? Легко передать абсурдно высокое значение для генерации исключения.

С другой стороны, что вы планируете делать, если генерируете это исключение? std::bad_alloc - это вид исключения, с которым вы обычно не справляетесь на микроуровне...

Например, на веб-сервере вы обычно выполняете некоторую очистку (откат на транзакции db?) и затем возвращаете пользователю ошибку 500.

Но когда память исчерпана, вы не можете сделать что-то безопасное, так как вам нужно осторожно протестовать, если вы не хотите снова ударять по стене памяти, которая, как вы знаете, близка:)


Отсутствие явной спецификации исключений является преднамеренным. См. этот раздел для объяснения. Кроме того, обратите внимание, что отсутствие явной спецификации означает, что нет ограничений на тип исключения, которое может вызывать функция. Таким образом, как минимум, функция ctor и resize может вызывать исключения в случае исчерпания памяти или если копия объекта-объекта не работает.

Некоторые общие ссылки, которые вдохновили Boost, которые вас могут заинтересовать, следующие:

licensed under cc by-sa 3.0 with attribution.