Пробуйте/Ловите отказ сегментации на Linux

Я бы предложил вам не указывать на подсказку. ORACLE знает лучше, используя оптимизатор на основе затрат. Более того, по мере роста данных текущая подсказка индекса может быть устаревшей. Я чувствую, что у вас уже есть достаточные показатели. Просто попробуйте ниже и посмотрите, работает ли ваш запрос лучше.

SELECT * 
  FROM TB_020 AS E
INNER JOIN (SELECT 
              CID, 
              MAX(GATH_DTM) GATH_DTM 
         FROM TB_020 
        WHERE DATA_STAT_CODE=28001 
    GROUP BY CID 
       ) AS J 
 ON E.GATH_DTM=J.GATH_DTM 
   AND E.CID =J.CID 
10
задан jackhab 5 February 2009 в 09:27
поделиться

9 ответов

Если у Вас есть сценарий, где много указателей через Ваше приложение ссылаются на те же ограничено-пожизненные объекты, популярное решение состоит в том, чтобы использовать интеллектуальные указатели повышения.Править: в C++ 11, оба из этих типов доступны в стандартной библиотеке

Вы хотели бы использовать shared_ptr для указателя (указателей), которые ответственны в течение времени жизни Вашего объекта и weak_ptr для других указателей, которые могут стать недопустимыми. Вы будете видеть это weak_ptr имеет проверку достоверности, которую Вы просите встроенный.

8
ответ дан 3 December 2019 в 15:53
поделиться

Отказом сегментации не является Исключение (как NullPointerException Java); это - сигнал, отправленный от ОС до процесса. Взгляните на страницу справочника для sigaction для указателей о том, как установить обработчик для отказа сегментации (SIGSEGV).

8
ответ дан 3 December 2019 в 15:53
поделиться

Инициализируйте свой указатель на ПУСТОЙ УКАЗАТЕЛЬ. Если после некоторой обработки это является все еще ПУСТЫМ, это недопустимо, иначе это допустимо.

4
ответ дан 3 December 2019 в 15:53
поделиться

Вы могли включить обработчик сигналов для SIGSEGV для этого возникновения. См., что страница справочника "сигнализирует" для деталей. Другая альтернатива должна использовать ссылки, которые, как гарантируют, будут допустимы. Это зависит от Вашего приложения, конечно.

4
ответ дан 3 December 2019 в 15:53
поделиться

Нет никакого естественного, универсального пути с необработанными указателями C++. C++ предполагает отслеживание той информации.

В большинстве ситуаций можно обработать это, не забыв устанавливать указатели в NULL, когда они недопустимы. Новые указатели, которые первоначально не указывают, должны быть установлены в NULL, и недавно удаленным объектам нужно установить их указатели в NULL.

2
ответ дан 3 December 2019 в 15:53
поделиться

Как Вы тестируете указатель на законность? Выдержать сравнение с ПУСТЫМ УКАЗАТЕЛЕМ?

Лучшая вещь, которую Вы делаете, состоит в том, чтобы запустить Вашу программу под Valgrind. Ошибка могла бы быть в очень отличающемся месте.

Обновление: На платформе Win32 существует что-то как __ попытка __, кроме которого позволяет ловить некоторые исключения. Поскольку далеко я знаю, что нет никакого Linux, эквивалентного для той функции Win32.

1
ответ дан 3 December 2019 в 15:53
поделиться

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

Вне проверки ПУСТОЙ УКАЗАТЕЛЬ я не полагаю, что существует способ проверить, 'допустим' ли указатель в смысле, Вы описываете. Во время ошибок нормального функционирования как это не должен происходить, поскольку они представляют ошибку, таким образом, необходимо хотеть, чтобы программа перестала работать, хотя корректно.

0
ответ дан 3 December 2019 в 15:53
поделиться

Указатели хранятся в объектах. Они инициализируются в конструкторе, потенциально к 0 (ПУСТОЙ УКАЗАТЕЛЬ). Они удалены в деструкторе, возможно в присвоении и редко в других функциях. При удалении в участниках кроме деструктора им сразу присваивают новое значение или 0.

0
ответ дан 3 December 2019 в 15:53
поделиться

Обычно относительно довольно странной идеи "проверки ненулевого указателя для законности", взглянули на эту статью: http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx ("IsBadXxxPtr должен действительно быть назван CrashProgramRandomly"),

0
ответ дан 3 December 2019 в 15:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: