Developing.ru

Можно ли здесь: запретить исключение?
А здесь: ?

Можно узнать зачем...? Как по-мне, ожидать, что они будут "дружить" как минимум, достаточно недальновидно, а если сказать прямо, то глупо.

И так ответ. По умолчанию "не дружит". Точнее, если выражаться общепринятой терминологией, компилятор по умолчанию не генерирует в классе operator new с соответствующей сигнатурой. Причина очень проста. Дело в том, что placement new (в отличие от обычного new) не выделяет память, а значит он и так не может бросить std::bad_alloc. Нам просто нечего запрещать, понимаешь?

Однако, при желании, пользователь может определить такой оператор, если он, например, хочет вложить в оператор с такой сигнатурой какой-то свой тайный смысл.

Подробнее об операторах new, как всегда, можно узнать, поискав в гугле. Первая же статья ведёт на известный С++ ресурс cppreference.

То есть второй фрагмент уже не умеет бросать исключения. Эйси. А первый? Он то память выделяет.

В заголовке был вопрос о placement new. Я на него и дал ответ.

В первом фрагменте да, можно. Это ведь не placement new. Будет выглядеть так: И если бы ты открыл приведённую ссылочку из гугла, то, увидев на первой же странице сигнатуры операторов присваивания, сразу же понял, как поправить вызов Гугл - это вещь!

Ваще то открыл. Но:
1. Понял не сразу. Пришлось тестовое приложение писать.
2. Сомнения остались.

Насколько я понимаю, std::bad_alloc не выбрасывается вообще никогда, так как память на современных операционных системах выделяется ленивым (Lazy) образом после первого обращения по адресу и недостаток оной может проявиться только уже во время работы конструктора объекта. При этом о недостатке памяти твоя программа вообще не узнает, так как ее тихо убьет ядро. В линуксе когда ядро видит что и ОЗУ и своп в общем-то исчерпаны, оно берет все процессы и начисляет им штрафные баллы. Чемпион убивается. Предпочтение отдается жадным пользовательским процессам. Скорее всего это будет какой-нибудь perl запущенный от юзера который из-за кривого регекспа запнулся на кривой строке и ушел перебирать O(N!) комбинаций мемоизируя промежуточные результаты в куче. А вот Оракел с многогигабайтым кешем скорее всего будет амнистирован, так как это серверный процесс. В Windows скорее всего тоже реализована подобная логика, так как других разумных решений подобной проблемы скорее всего не существует.

Вообще то бросается. Обращения к памяти ни как на это не влияют, даже бросает исключение, но ни один конструктор или деструктор здесь не вызывается в принципе и фактическое обращение к выделенной памяти не происходит.

Скорее всего имеет место исчерпание адресного пространства. Переходите на x86_64.

1. Если в x86_64 исчерпывается адресное пространство, то надо переходить с него опять на x86_64? Сам то понял, что сказал?
2. Жалкий триллион интов 16 эксибайт исчерпать не может даже с учётом любых дыр.

На win64 верхний предел динамической памяти выделяемой для процесса это 8TB, а не 16 экзабайт. Почему затык на 3TB - вопрос конечно интересный, но не настолько чтобы лезть в msvcrt прямо вот сейчас.

Ну Ок, уговорил, разрешаю тебе ловить std::bad_alloc. Но вот такой вопрос: к примеру, ты компилируешь огромный исходник на С++ с кучей темплейтов и пр. Когда попытался аллокировать память для того чтобы раскрыть какой-то шаблон с новыми параметрами получил внезапно std::bad_alloc. Вопрос: как продолжать дальше работать.