Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Кстати вот вопрос такой, в случае SEH исключений в С++, допустим в каком то классе, как быть? На сколько я помню(возможно ошибаюсь) деструкторы не вызываются в таких случаях, и попадаем мы в глобальную переопределенную функцию обработчик, что напрочь портит стэк. Есть ли какие нибудь ср-ва(кроме мозгомаразма, типа писать стек фрейм в файл под студию или еще под какой нибудь gcc) для обнаружения ошибки в С++ ? Всякие опции компиля, тоже отпадают. Просто я иногда встречаюсь с такого рода траблами, и это выливается в полный геморой трейсов и дампов... Может есть средство от этого? В делфи, на сколько я понял, это средство встроенное

Сообщение отредактировано: Qraizer - 05.01.12, 19:29

D_KEY, что, если деструктор не вызовется? Мало ли, кто-то не захотел воспользоваться умными указателями, а по-старинке new/delete? Только не нужно отвечать, мол, ССЗБ =)

Цитата korvin @ 05.01.12, 17:58

D_KEY, что, если деструктор не вызовется? Мало ли, кто-то не захотел воспользоваться умными указателями, а по-старинке new/delete? Только не нужно отвечать, мол, ССЗБ =)

ССЗБ

Цитата KILLER @ 05.01.12, 18:02

ССЗБ

Ну я так не играю =)

Я вот не уверен, но при SEH вызывается деструктор класса? На сколько я помню, нет... Т.е. при том же делении на 0, на каких то компиляторах(если я еще помню хорошо) деструктор и так не вызовется...

Добавлено 05.01.12, 18:06

Цитата korvin @ 05.01.12, 18:03

Ну я так не играю =)

korvin, у него там умный shared_ptr, если программер незнает что это, и пишет чота свое, то он сам за это свое типа и отвечает... На крайний случай есть документация, ее следует обязательно читать перед использованием...

Цитата KILLER @ 05.01.12, 17:47

Кстати вот вопрос такой, в случае SEH исключений в С++, допустим в каком то классе, как быть? На сколько я помню(возможно ошибаюсь) деструкторы не вызываются в таких случаях, и попадаем мы в глобальную переопределенную функцию обработчик, что напрочь портит стэк. Есть ли какие нибудь ср-ва(кроме мозгоебства, типа писать стек фрейм в файл под студию или еще под какой нибудь gcc) для обнаружения ошибки в С++ ? Всякие опции компиля, тоже отпадают. Просто я иногда встречаюсь с такого рода траблами, и это выливается в полный геморой трейсов и дампов... Может есть средство от этого? В делфи, на сколько я понял, это средство встроенное

Ты про обработку системных исключений в MSVC? Это их интимные трудности, что у них не вызываются деструкторы при этом.
А если ты про исключение в деструкторах, то их быть не должно. По многим причинам.

Цитата D_KEY @ 05.01.12, 18:26

Ты про обработку системных исключений в MSVC? Это их интимные трудности, что у них не вызываются деструкторы при этом.

Да, я про SEH, и эта интимность меня будоражит... Я знаю что это платформозависимо, но все же... В *nix'ах тоже есть нечто подобное. Просто интересно, м.б. кто то с таким сталкивался, и другими путями обходил?
Да и вообще как быть с апаратными исключениями, на разных платформах ?

Цитата korvin @ 05.01.12, 17:58

D_KEY, что, если деструктор не вызовется?

Это как?

Цитата

Мало ли, кто-то не захотел воспользоваться умными указателями, а по-старинке new/delete?

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

Скрытый текст

Цитата D_KEY @ 05.01.12, 18:34

Во-первых, при delete деструктор вызывается. И это его основная функция, особенно если мы в проекте используем GC.

Особено если два раза

Сообщение отредактировано: KILLER - 05.01.12, 18:37

Цитата KILLER @ 05.01.12, 18:29

Цитата D_KEY @ 05.01.12, 18:26

Ты про обработку системных исключений в MSVC? Это их интимные трудности, что у них не вызываются деструкторы при этом.

Да, я про SEH, и эта интимность меня будоражит...

Видимо, нужно руками вызывать в __finally(а вообще лучше Qraizer'а спросить, он хорошо эти вопросы знает, я подзабыл уже). Ну или выбрать другой компилятор. К языку это отношения не имеет.

Цитата

В *nix'ах тоже есть нечто подобное.

Тут сигналы, так что таких проблем нет - их обработка отделена от основного кода.

Цитата

Да и вообще как быть с апаратными исключениями, на разных платформах ?

На разных? По разному, как же еще.

Добавлено 05.01.12, 18:46

Цитата KILLER @ 05.01.12, 18:36

Скрытый текст

Цитата D_KEY @ 05.01.12, 18:34

Во-первых, при delete деструктор вызывается. И это его основная функция, особенно если мы в проекте используем GC.

Особено если два раза

Скрытый текст

Это уже бага-бага

Цитата D_KEY @ 05.01.12, 18:43

Видимо, нужно руками вызывать в __finally(а вообще лучше Qraizer'а спросить, он хорошо эти вопросы знает, я подзабыл уже). Ну или выбрать другой компилятор. К языку это отношения не имеет.

Видимо да, но это с включеной обработкой..., а код не должен быть платформозависим... __finally - фича MSVC

Цитата D_KEY @ 05.01.12, 18:43

На разных? По разному, как же ещ

И это печалит...

Цитата KILLER @ 05.01.12, 18:05

korvin, у него там умный shared_ptr, если программер незнает что это, и пишет чота свое, то он сам за это свое типа и отвечает...

Connection'у это не поможет...

Цитата korvin @ 05.01.12, 19:08

Connection'у это не поможет...

Почему? В деструкторе Connection'а - он его закроет, а вызовеца деструктор, либо когда на него не будут ссылаца, либло при исключении...

Цитата D_KEY @ 05.01.12, 18:34

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

Во-первых, delete можно и забыть вызвать, не учесть какой-нибудь случай.
Во-вторых, само собой, но ведь он не всегда нужен.
Затем, что он не эффективен.
Да-да, тулзы-тулзы... Ни шагу на C++ не ступить без тулзов =)

Добавлено 05.01.12, 19:16

Цитата KILLER @ 05.01.12, 19:10

Почему? В деструкторе Connection'а - он его закроет, а вызовеца деструктор, либо когда на него не будут ссылаца, либло при исключении...

Как он узнает, что на него не ссылаются, если ссылка не умная?

Цитата KILLER @ 05.01.12, 17:47

Кстати вот вопрос такой, в случае SEH исключений в С++, допустим в каком то классе, как быть? На сколько я помню(возможно ошибаюсь) деструкторы не вызываются в таких случаях, и попадаем мы в глобальную переопределенную функцию обработчик, что напрочь портит стэк.

Деструкторы не вызываются потому, что оно имплементэйнш-дефинед. Стандарт не определяет, как аппаратные сбои должны быть представлены в C++EH, системные исключения слишком уж некроссплатформенны. Но оно настраивается. В MSVC это ключик -EHa (Exception Handling asyncronuous). По дефолту использовать нет смысла, т.к. у SEH и C++EH различное назначение, и они очень редко пересекаются в приложениях на одном и том же уровне абстракции представления предметной области. Просто оно нехило увеличивает оверхед на размер типостатической информации, генерируемой компилятором для SEH-кадров. Обычно восстребовано только на этапе отладки или в техподдержке. По дефолту используют -EHs (Exception Handling syncronuous), что означает, что системные исключения никогда не затрагивают стековые кадры, содержащие объекты с нетривиальными деструкторами.

#include <iostream>
#include <windows.h>
 
struct aClass
{
  ~aClass() { std::cout << "I'm destructor" << std::endl; }
};
 
void g();
 
void f()
{
  try
  {
   aClass a;
   g();
  }
  catch(...)
  {
   std::clog << "An exception has been catched" << std::endl;
   throw;
  }
}
 
int main()
{
  __try
  {
   f();
  }
  __except(std::clog << (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
                                     "Access violation has been happened" : "An unexpected exception has been happened") << std::endl,
           EXCEPTION_EXECUTE_HANDLER)
  {
  }
}
 
void g()
{
  *reinterpret_cast<int*>(NULL) = 0;
}

-EHs

D:\WORK\DelMe>1.exe
Access violation has been happened

-EHa

D:\WORK\DelMe>1.exe
I'm destructor
An exception has been catched
Access violation has been happened

Цитата KILLER @ 05.01.12, 17:47

Есть ли какие нибудь ср-ва ... для обнаружения ошибки в С++ ? Всякие опции компиля, тоже отпадают.

Нормальный компилятор, нормально портированный под платформу, должен обеспечивать полноценную её поддержку, не находишь? Без опциёв - используй трансляцию SEH в C++EH, WinAPI и это позволяет.

Цитата D_KEY @ 05.01.12, 18:43

Тут сигналы, так что таких проблем нет - их обработка отделена от основного кода.

У сигналов есть агромадное ИМХО неудобство перед SEH - невозможность пользоваться ими структрурно, то бишь скобочками {} или чем-то подобным. Не, можно накидать RAII-классец, не спорю, но под ОСью с поддержкой структурного EH это костыль.

Добавлено 05.01.12, 19:28

Цитата KILLER @ 05.01.12, 19:01

код не должен быть платформозависим

Это непобедимо, KILLER. В POSIX нет SEH. Прадва, в WinAPI есть немножко сигналов...