Дебильные вопросы в анкетах на позицию

[olis]

Можно узнать с помощью поинтер арифметики, кого пытаеца деструктать деструктор - что-то на стеке или че-то на хипе.
Но так мало кто делает патаму што зависит от процессора, от модели памяти и от осы.

Даже не начинай. Там такой зоопарк с форматом стека при разных вызовах, что черт ногу сломит.

Соглашение о вызовах то как раз стандартное , для X86/X64 по крайней мере. Но его необязательно придерживаться и не все это делают. Но вообще для раскрутки стека используется DWARF информация, для С++ из eh_frame.
Если же нет DWARF и не поддерживается соглашение о вызовах, то раскрутка стека невозможна. Но это не про С++.
У меня был проект где как раз требовалась раскрутка стека, но не было ни того, ни другого.

[Bobeg]

При покидании фрейма вызываюца деструкторы всего того что было аллоцировано в/на том фрейме. Пункт про необязательно мне не ясен.
Они именно что обязательно инвокируются.
Эксепшен их не обходит.

Ну да. Только при возврате из ф-ции деструкторы стековых объектов тоже вызовутся. И как различить эту ситуацию с эксепшеном?

Ты с чем и о чем спориш.
Фукнция при возврате очищает свой фрейм.
При анвайндинге тоже.
При этом вызываются деструкторы.

Как понимать твою фразу:

"На стеке ведь тоже необязательно удаляются во время раскрутки стека."

[Bobeg]

x64 это канешно гуд.
Но надо штоб было портабле на арм.

[Bobeg]

Пооооорт
Портабле на аааарм
(петь на мотив борн ту би элайв)

[olis]

Ну да. Только при возврате из ф-ции деструкторы стековых объектов тоже вызовутся. И как различить эту ситуацию с эксепшеном?

Ты с чем и о чем спориш.
Фукнция при возврате очищает свой фрейм.
При анвайндинге тоже.
При этом вызываются деструкторы.

Как понимать твою фразу:

"На стеке ведь тоже необязательно удаляются во время раскрутки стека."

Ну мы ж вроде обсуждаем - как узнать вызывается деструктор из эксепшн или при удалении объекта из стека. Как различить эти 2 ситуации?

[assassello]

Осталось разобраться чем std::uncaught_exception отличается от std::uncaught_exceptions.
Удачи.

Ты не умничай, а пальцем покажи (с)

А что непонятно? std::uncaught_exception (без s) возвращает bool и совершенно справедливо раскритикована и удалена из c++20.
std::uncaught_exceptions возвращает int и вполне себе используется.

[olis]

x64 это канешно гуд.
Но надо штоб было портабле на арм.

Да они там все DWARF используют. И при вызове ф-ций сохраняют в стеке адрес возврата и предыдущее значение base/frame pointer.

[Bobeg]

Ты с чем и о чем спориш.
Фукнция при возврате очищает свой фрейм.
При анвайндинге тоже.
При этом вызываются деструкторы.

Как понимать твою фразу:

"На стеке ведь тоже необязательно удаляются во время раскрутки стека."

Ну мы ж вроде обсуждаем - как узнать вызывается деструктор из эксепшн или при удалении объекта из стека. Как различить эти 2 ситуации?

Что означает "деструктор вызывается из иксепшен"?

И при ретурне и при иксепшен кидании функция все равно очищает стак фрейм.

Но при анвайндинге рантайм ищет хендлер.
А при ретурне ексекьюшен возвращаеца к точке вызова.

В обеих ситуациях все что было на стеке будет деструкнуто.

[Bobeg]

Ну и узнать есть ли лайв эксепшен можно.
Это используется всякими бустами чтобы
имплементать анвайнд стак трейс.
Правда в рилиз билдах он очень странно работает.
Лол гыгы.

[olis]

Ну мы ж вроде обсуждаем - как узнать вызывается деструктор из эксепшн или при удалении объекта из стека. Как различить эти 2 ситуации?

Что означает "деструктор вызывается из иксепшен"?

И при ретурне и при иксепшен кидании функция все равно очищает стак фрейм.

Но при анвайндинге рантайм ищет хендлер.
А при ретурне ексекьюшен возвращаеца к точке вызова.

В обеих ситуациях все что было на стеке будет деструкнуто.

Эээ...

Напомните, как деструкторе знает, что это unwind, а не принудительное удаление обьекта?

Наверно можьно посмотреть на SP и догадаца.
Но так никто ниделаит.

[Bobeg]

x64 это канешно гуд.
Но надо штоб было портабле на арм.

Да они там все DWARF используют. И при вызове ф-ций сохраняют в стеке адрес возврата и предыдущее значение base/frame pointer.

Ты дебаггер стандарт и коллинг конвеншены памоему немного миксишь.

[Bobeg]

Что означает "деструктор вызывается из иксепшен"?

И при ретурне и при иксепшен кидании функция все равно очищает стак фрейм.

Но при анвайндинге рантайм ищет хендлер.
А при ретурне ексекьюшен возвращаеца к точке вызова.

В обеих ситуациях все что было на стеке будет деструкнуто.

Эээ...

Наверно можьно посмотреть на SP и догадаца.
Но так никто ниделаит.

Што ты разэкался.

[olis]

Да они там все DWARF используют. И при вызове ф-ций сохраняют в стеке адрес возврата и предыдущее значение base/frame pointer.

Ты дебаггер стандарт и коллинг конвеншены памоему немного миксишь.

Нет. Для раскрутки стека и дебаггер, и С++ exception handling используют DWARF data. Из eh_frame. Дебаггер может из debug_frame использовать, если eh_frame нет. Или смотреть что в стеке.
Но exception handling/stack unwinding в С++ это всегда eh_frame. Он просто компилятором генерится для C++.
Есть еще другие программы, кому stack unwinding тоже нужен. Те что занимаются live patching, например.
Есть библиотеки, libunwind например. Но там тоже только эти 2 метода.

[Mad Hatter]

Даже не начинай. Там такой зоопарк с форматом стека при разных вызовах, что черт ногу сломит.

Соглашение о вызовах то как раз стандартное , для X86/X64 по крайней мере. Но его необязательно придерживаться и не все это делают. Но вообще для раскрутки стека используется DWARF информация, для С++ из eh_frame.
Если же нет DWARF и не поддерживается соглашение о вызовах, то раскрутка стека невозможна. Но это не про С++.
У меня был проект где как раз требовалась раскрутка стека, но не было ни того, ни другого.

Ну вот ты сам и сказал, что бывают ситуации когда нет нужного фреймворка. Понято что внутри такого все чётко определено, но я об общей ситуации. Кстати, в модели защиты x86 передача параметров между кольцами защиты при вызове метода из другого кольца определён на уровне железа но это другое.

[Mad Hatter]

Ты не умничай, а пальцем покажи (с)

А что непонятно? std::uncaught_exception (без s) возвращает bool и совершенно справедливо раскритикована и удалена из c++20.
std::uncaught_exceptions возвращает int и вполне себе используется.

И это принципиально меняет ситуацию?

[voyager3]

Запретить эти буржуазные экскпшены, и всё тут!

[assassello]

А что непонятно? std::uncaught_exception (без s) возвращает bool и совершенно справедливо раскритикована и удалена из c++20.
std::uncaught_exceptions возвращает int и вполне себе используется.

И это принципиально меняет ситуацию?

Хм... никак. Потому что и нет никакой "ситуации".
С++ представляет надежное средство, которое (в том числе помогает) кидать эксепшены из деструктора.

Ты о чем вообще?

[assassello]

Запретить эти буржуазные экскпшены, и всё тут!

Можно. Но с какой-то частью Стандартной библиотеки придется проститься, нет?

Честно говоря, сам никогда не пробовал.
Был проект, где жестким условием было "своих исключений не бросаем, чужие - не выпускаем", но давно.

[olis]

Запретить эти буржуазные экскпшены, и всё тут!

На С++, на котором ядро Симбиоз был написан, так и сделали)

[alex_127]

Запретить эти буржуазные экскпшены, и всё тут!

На С++, на котором ядро Симбиоз был написан, так и сделали)

А это что такое?