необходимо разобраться с обработкой системных исключений , (что писать сюда: catch (...))? компилятор g++

Друзья! Есть рекурсивная функция, которая переполняет стек. Вот хочу чтобы об этом как-нибудь сигнализировалось, пишу обработку исключений и в catch (...) пишу ХОТЬ ЧТО-НИБУДЬ ЛИШЬ БЫ СКОМПИЛИЛОСЬ

Так, писать вроде как надо тип исключения. А какой у исключений тип? А чёрт его знает. Порылся по гуглу, у Джефри РИхтра всё очень-очень интересно. Вот, допустим отрывок его кода: (правда, там он использует компилятор msvs и соответственно конструкццию __try __except, но не суть)

__except(GetExceptionCode() == EXCEPTION_INT_DIVIDE_BY_ZERO

Что в левой части? Смотрим в msdn
The return value identifies the type of exception

ага, а в правой? лезем в winbase.h

#define STATUS_INTEGER_DIVIDE_BY_ZERO 0xC0000094
#define EXCEPTION_INT_DIVIDE_BY_ZERO    STATUS_INTEGER_DIVIDE_BY_ZERO

неплохо, да? Идентификатор типа приравнивается к конкретному значению 0xC0000094!
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Так чё писать-то в catch (...)? Я пробовал тупо
cath (EXCEPTION_ACCESS_VIOLATION) (переполнен стек)- так компилятор говорит, что нужен тип... Какой тип?
Пробовал cath (GetExceptionCode())- то же самое:
expected type-specifier before 'GetExceptionCode'
...Опять же, макрос GetExceptionCode(). Роюсь в инклудах и вижу в:

#define RpcExceptionCode() GetExceptionCode()

На этом всё определение GetExceptionCode() заканчивается. И в msdn ничего о нём нет. Ни самомго макроса, ни файла, где бы он был определён.
Ну и хорош пока на этом.

В общем, ребята помогите разобраться в данном вопросе! Компилятор g++

#include <windows.h>
#include <stdio.h>
using namespace std;
 
 
void k () {
 printf ("hello, word!\n");
 k();
}
 
 
int main () {
 
 try {
  k();
 }
 catch (EXCEPTION_ACCESS_VIOLATION) {
// catch  (GetExceptionCode()== EXCEPTION_ACCESS_VIOLATION) {
 }
 
 return 0;
}

спасибо, кто откликнется

Сообщение отредактировано: повстанец - 26.11.11, 06:56

Для MSVC так:

LONG My_ExceptFilter(DWORD except_code,PEXCEPTION_POINTERS except_info)
{
  if (except_code==EXCEPTION_STACK_OVERFLOW)
  {
    //some code
    
  }
   //return EXCEPTION_CONTINUE_SEARCH; //система дальше будет искать обработчик исключения
   //ИЛИ
   //return EXCEPTION_CONTINUE_EXECUTION //продолжает выполнение программы с точки где возникло исключение
   //ИЛИ
   //return EXCEPTION_EXECUTE_HANDLER;  //мы обрабатываем, дальше поиск обработчика не пойдет, после возврата из функции выполнится блок __except
 
    
}
//...............................................................................................................
__try
 {
   //КОД где предполагается возникновение исключения
 }
 __except(My_ExceptFilter(GetExceptionCode(),GetExceptionInformation()))
 {
 
 }

Только при переполнении стека уже ничего не получится сделать. Всё кирдык, только закрыть всё, запомнить что нужно и завершать поток. Ну если только сами данные в стеке важны, а если не важны то можно указатель стека вновь на начало поставить.

Сообщение отредактировано: neokoder - 26.11.11, 15:27

При всё уважении не рассматривал ваш вариант. У меня g++, другие инструменты работают на нём нормально так что хотелось всё же обсуждать возможности компилятора g++, кстати в сети примеры подобные вашему есть, а для g++ я не нашёл.

В g++ есть SEH-обработка? Если нет, то SetUnhandledExceptionFilter и код, приведенный выше

Я ж только-только начал заниматься исключениями... Откуда же мне знать, есть оно там или нет? И сключения ВООБЩЕ- поддерживаются. В частности SEH... Походил-походил по гуглу, нарыл, что:
"Блоки SEH оформляются с помощью операторов __try, __finally, __except"

Но такой синтаксис поддерживается компилятором MSVS! А g++ не поддерживется. Вывод: в g++ SEH нет.
А потом я так понял, что при удачном вызове SetUnhandledExceptionFilter управление передаётся обработчику сообщений который действует в зависимости от... От чего? От типа исключения? И опять- как определять этот тип?
Но как бы то ни было, вот код с использованием SetUnhandledExceptionFilter, что-то он не работает

#include <windows.h>
#include <iostream>
#include <stdio.h>
 
 
LONG WINAPI UEF(_EXCEPTION_POINTERS *ExceptionInfo)
{
  printf ("пишу тут вдруг адрес, который ниже, невалидный \n");
  getchar ();
  return EXCEPTION_EXECUTE_HANDLER;
}
 
int main()
{
  SetConsoleCP (1251);
  SetConsoleOutputCP (1251);
 
 
  SetUnhandledExceptionFilter (UEF);
  throw std::exception();
  getchar ();
  return 0;
}

Сообщение отредактировано: повстанец - 26.11.11, 14:17

LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
{
  if (except_info->ExceptionRecord->ExceptionCode==EXCEPTION_STACK_OVERFLOW)
  {
    //some code
 
  }
  
   //return EXCEPTION_CONTINUE_EXECUTION
   //ИЛИ
   //return EXCEPTION_EXECUTE_HANDLER;
}
//....................................................
SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);

Добавлено 26.11.11, 14:31
Ещё такой вопрос, а что вас заставляет использовать именно g++, а не MSVC?

Сообщение отредактировано: neokoder - 26.11.11, 14:32

neokoder, зачем давать неопробированные варианты? Запустите ваш код и увидите что он неработает. Вот он:

#include <windows.h>
#include <iostream>
#include <stdio.h>
 
 
 
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)      {
 if (except_info->ExceptionRecord->ExceptionCode==EXCEPTION_STACK_OVERFLOW)
  {
    //some code
  
  }
  else {
    printf ("ÿ õî÷ó âèäåòü ýòó íàäïèñü, íî ÿ å¸ íå âèæó\n");
    getchar ();
  }
  return EXCEPTION_CONTINUE_EXECUTION;
}
      //....................................................
 
 
int main(){
  SetConsoleCP (1251);
  SetConsoleOutputCP (1251);
 
 
  //SetUnhandledExceptionFilter (UEF);
  SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
  throw std::exception();
  getchar ();
  return 0;
}

компилятор- инструмент всего лишь если надо будет я перейду на MSVS, но я должен убедиться, что создатели g++ (или сторонних ибилиотек для g++) не предусмотрели обработку исключений. А не так, что ах не получилось быстренько меняем компилятор. Тем более, что у g++ есть и другие плюсы (нормальная работа с библиотеками OpenGL и pthread, тьфу-ьтьфу-тьфу).

Сообщение отредактировано: повстанец - 26.11.11, 14:41

Цитата повстанец @ 26.11.11, 14:39

Запустите ваш код и увидите что он неработает. Вот он:

А как он "не работает"? В чем это проявляется?

Если тыкать мышью, то окно появляется и тут же исчезает, а если в консоли запускать, то появляется:

terminate called after throwing an instance of 'std::exception'
  what():  std::exception
 
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

А нужной мне строки "я хочу видеть эту надпись, но я её не вижу\n" как не было, так и нет

Цитата повстанец @ 26.11.11, 15:09

А нужной мне строки "я хочу видеть эту надпись, но я её не вижу\n" как не было, так и нет

Чтобы видеть надпись попробуй так:

LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)      {
 if (except_info->ExceptionRecord->ExceptionCode==EXCEPTION_STACK_OVERFLOW)
  {
    //some code
 
  }
  else {
    printf ("Another exception catched.\n");
 
  }
  return EXCEPTION_EXECUTE_HANDLER;
}

Я в комментарии дал немного неверную информацию тебе вначале. Если использовать EXCEPTION_CONTINUE_EXECUTION, то он возвращается в ту же точку где произошло исключение. Поэтому у тебя циклились исключения.

Сообщение отредактировано: neokoder - 26.11.11, 16:28

Может быть они и циклились, но надпись-то должна была выводиться?
ТО есть если "

Цитата

EXCEPTION_CONTINUE_EXECUTION, то он возвращается в ту же точку где произошло исключение.

", то должно было быть так:
генерация исключения- надпись
генерация исключения- надпись
генерация исключения- надпись
генерация исключения- надпись
генерация исключения- надпись
И так далее.

Я тебе больше скажу- ты опять не тестишь свой код. При

return EXCEPTION_EXECUTE_HANDLER;

Всё то же самое. Мелькание чёрного окна и диагностическая надпись из поста номер 9

Сообщение отредактировано: повстанец - 26.11.11, 15:49

Цитата повстанец @ 26.11.11, 15:48

Я тебе больше скажу- ты опять не тестишь свой код.

Правильно, его тестить должен ты, поскольку у меня нет G++;


В MSVC всё будет работать. Я думал может и в твоём компиляторе по аналогии заработает.

Ну если нет надписи с EXCEPTION_EXECUTE_HANDLER, значит в G++ не работает такая обработка исключений. Попробуй в debug-режиме вообще попадает он в этот обработчик или нет, или добавь строчку printf ("In TopLevelUnhandledExceptionFilter.\n"); в начало фильтра.

Конструкцию try/catch(...) пробовал? И опции компилятора, связанные с исключениями проверь, чтобы SEH-исключения также ловились.

И ещё, а почему бы не задать свой вопрос разработчикам компилятора или здесь к примеру?
Там по ходу не только у тебя такая проблема и здесь такая же.

Сообщение отредактировано: neokoder - 26.11.11, 16:06

Так-то кто хочет тот и тестит, у на демократия. Но какое доверие будет к твоим кодам?
try/catch(...) я пробовал, о чём написал в первом собщении.
В общем, спасибо за беспокойство, не смею больше тратить твоё время. Вопрос открыт.

Цитата повстанец @ 26.11.11, 16:04

Так-то кто хочет тот и тестит, у на демократия. Но какое доверие будет к твоим кодам?
В общем, спасибо за беспокойство, не смею больше тратить твоё время. Вопрос открыт.

Тебе ещё раз говорю, что в MSVC всё будет работать без проблем, не раз я этот код писал, поэтому и уверен. Т.е. эта не проблема WinAPI, а проблема твоего компилятора. Так что не в той теме ты вопрос задаешь вообще.

Добавлено 26.11.11, 16:13

Цитата повстанец @ 26.11.11, 16:04

try/catch(...) я пробовал, о чём написал в первом собщении.

Кстати именно такой конструкции у тебя не было в коде:

try
{
}
catch(...)
{
}

Проверь!

Добавлено 26.11.11, 16:22
Ещё до кучи, проверьте включена ли у вас опция "-fhandle-exceptions" при компиляции. По умолчанию она вроде бы отключена.

Сообщение отредактировано: neokoder - 26.11.11, 16:25

Я сразу сказал, что дело в компиляторе, гы. Ну то есть дело в том, что он не генерит нужный мне код с предложенным синтаксисом. Когдаааа я ещё сказал. Так зачем же предлагать коды, которые не опробированы на нём? Здесь- не здесь это второй вопрос, я не знаю где.

Вот отрывок из кода из первого сообщения, я проверил

try {
  k();
 }
 catch (EXCEPTION_ACCESS_VIOLATION) {
// catch  (GetExceptionCode()== EXCEPTION_ACCESS_VIOLATION) {
 }

Не беспокойся, в общем, больше. До свидания. Желаю счастья.

Цитата повстанец @ 26.11.11, 16:26

Не беспокойся, в общем, больше. До свидания. Желаю счастья.

Ну раз так, то счастливо. На фига тогда вопрос задаешь если не хочешь слышать ответы? Cтранно!

Добавлено 26.11.11, 16:31

Цитата повстанец @ 26.11.11, 16:26

Вот отрывок из кода из первого сообщения, я проверил

Ну и где здесь catch(...)???

в g++ таких опций нет, есть - fexceptions, она включена по умолчанию

Добавлено 26.11.11, 16:55
Просто ты не можешь мне помочь. Ты пытался, но больше не можешь.
А чё, троеточие нужно было ставить?
Ну короче, с троеточием тоже не работает. Но даже если бы и работало, как мне исключения-то различать меж собой? Никак.

повстанец, SEH - это часть интерфейса WinAPI, предоставляемый ОС. Для эффективного его использования C и C++ компиляторы MS поддерживают расширение синтаксиса в лице __try/__except/__finally/__leave. Для других языков или других компиляторов эффективное использование SEH становится проблемой других языков или компиляторов. Компиляторы Intel C++ и Borland имеют таковую. Почему её не имеет порт gcc/g++ под Win, хороший вопрос их авторам.
Для пользователей языков или компиляторов, не имеющих эффективной поддержки SEH, WinAPI предоставляет иные средства, например в лице SetUnhandledExceptionFilter(). Попробуй такой пример:

#include <windows.h>
#include <stdio.h>
 
void k ()
{
  printf ("hello, word!\n");
  k();
}
 
 
LONG WINAPI TopLevelUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* except_info)
{
  throw except_info;
}
 
int main ()
{
 SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
 
 try
 {
  k();
 }
 catch (PEXCEPTION_POINTERS except_info)
 {
  if (except_info->ExceptionRecord->ExceptionCode == EXCEPTION_STACK_OVERFLOW)
   printf ("Stack overflow exception\n");
  else printf ("Unexpected exception!\n");
 }
 
 return 0;
}

Добавлено 26.11.11, 18:14
Вообще, Стандарт не обязывает отображать на механизм try/catch исключения, не имеющие своим источником throw. Просто потому, что любые такие исключительные ситуации не могут быть стандартизированы, ибо они платформозависимы.

Цитата Qraizer @ 26.11.11, 18:09

повстанец, SEH - это часть интерфейса WinAPI, предоставляемый ОС.

Так он даже не SEH поймать не может:

throw std::exception();

Это вроде как С++ исключение.

Не, бесполезно. Я на разрабочиков g++ не в обиде- в конце концов мне компилятор беслатно достался. Но я думаю рано отчаиваться тем более, что в хидерах g++ определены виды системных исключений (для чего-то ведь это сделано!). Мне кажется, я мог бы глубже вникнуть в эту проблему, если бы получил ответы на такие глупые вопросы, до которых недавно додумался:

catch (сюда пишется [I]тип аргумент[/I] или сам [I]тип[/I]?)

Это из учебника

Ну так будем последовательны. Какой тип имеют системные исключения?
Всё же просто, вот они так определены:

#define STATUS_ACCESS_VIOLATION 0xC0000005
#define EXCEPTION_ACCESS_VIOLATION  STATUS_ACCESS_VIOLATION

Ну так и надо тип узнать... Но как?
Если я буду знать имя типа, всё вперёд, может у меня из-за несоответствия типу не срабатывает блок catch!

надо будет спросить у niXman, который mingw толкает, есть там поддержка исключений или нет...

Не поддерживает GCC SEH-исключения пока. А EXCEPTION_STACK_OVERFLOW - это как раз SEH.

Цитата

Structured Exception Handling (SEH)

Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). A great overview of this mechanism can be found here.

Unfortunately, GCC does not support SEH yet. Casper Hornstrup had created an initial implementation, but it was never merged into mainline GCC. Some people have expressed concerns over a Borland patent on SEH, but Borland seems to dismiss these concerns as balderdash.

На хрена я мучился? Надо было тебе, повстанец, доки внимательно изучить сначала. А насчет С++ исключений, вот такой код их ловит:

  try
  {
  throw std::exception();
  }
 catch(std::exception &except)
 {
    printf("We catched std::exception with message: %s\n",except.what());
 }
 catch(...)
 {
     printf("We catched unknown exception.\n");
 }

Компилить так:

g++-4 -fexceptions main.cpp -o main.exe

Добавлено 26.11.11, 19:32
Но если очень уж надо ловить SEH, можешь поробоватьт поставить LibSEH. Описание и примеры кода здесь.

Спасибо не надо, лучше в следующий раз внимательнее доки читай и пользуйся поиском понастойчивее.

Сообщение отредактировано: neokoder - 26.11.11, 19:32

Надо было не мучаться, а читать тему. Об этом меня уже спрашивали, я честно ответил:

Я ж только-только начал заниматься исключениями... Откуда же мне знать, есть оно там или нет?

И ещё: ну, допустим, не поддерживаются SEH исключения, а зачем же они тогда в хидерах определены?

Далее, там говорится о gcc, а у меня g++
Я понимаю, что они где-то даже похожи, но у меня по g++ процесс gcc даже не повляется, а появляется процесс cc1plus

Короче, спрошу-ка я у niXmanа, он точно знает. А пока вопрос открыт:
исключениями КАКОГО ТИПА являются системные исключения?

...Про библиотеку ой как рано делать выводы, я чера такого монстра скачал-скачал
http://code.google.com/p/exceptions4c/

Это тоже библиотека исключений
А чё толку-то? Пришлось удалять. Может, конечно, руки кривые, только если другие билиотеки работают, так они и работают (графика и потоки я имею ввиду). Уж я всяко изгалялся, а всё равно линкёр ошибку выдавал и всё, что он не находит функций, я уж и библиотеки вручную подключал- бесполезно. Короче, удалил. Завтра буду мучаться.

Сообщение отредактировано: повстанец - 26.11.11, 19:43

GCC это - GNU Compiler Collection.
GCC - также это изначально С-компилятор.
G++ - это GNU C++, компилятор для языка С++. Это часть этой коллекции.
Проще говоря если нет для GCC, значит нет и для G++.

Что у тебя стоит Cygwin или Mingw?

У меня ничё, у меня просто сборка. Я качнул сперва пустую Dev-C++, а потом начал её оснащать пакетами по отдельности
binutils, gcc-core и ещё несколько пакетов. Старался брать поновее. Короче, как получилось так и получилось.

Цитата повстанец @ 26.11.11, 19:35

исключениями КАКОГО ТИПА являются системные исключения?

повстанец, SEH и C++ exception handling - это разные механизмы. Даже в MSных компиляторах, чтобы их можно было использовать сообща, требуется ключик компилятору, и даже в этом случае SEH не может использоваться в той же функуции, где уже присутствует try/catch и наоборот, а также в функции, которая содержит автоматические объекты с нетривиальными деструкторами.
Твой вопрос лишён смысла. Почитай про SEH в MSDN, в частности про RaiseException(), WinAPIшный аналог throw. Ты можешь функцией-фильтром транслировать SEH в некий класс (читай тип) и ловить его. Примерно как в коде выше. Для этого сначала требуется разобраться с исключениями в g++. Не исключено, что по дефолту они просто выключены, поэтому ты не смог поймать даже банальный Стандартный std::exception Стандартным же catch. Вообще, странно, у меня они работали "из коробки", безо всяких ключиков.

Цитата Qraizer @ 26.11.11, 21:08

Вообще, странно, у меня они работали "из коробки", безо всяких ключиков.

Вот и у меня тоже С++ исключения ловятся нормально при компиляции с GCC из Cygwin(поставил последнюю версию). Вообще DEV-C++ последняя версия обычно идёт в комплекте с MinGW(в котором есть уже GCC), но старым, и он как написал всё вручную ставил может из-за этого какие-то глюки.

В общем итог такой: микрософтовский SEH в GСС не реализован в принципе, значит ловить по-нормальному EXCEPTION_STACK_OVERFLOW не получится, а те либы одну из которых я порекомендовал скорее всего банальные костыли и поэтому работать будут через раз, и в частности libSEH даже не раскручивает стек после исключения. Поэтому, если у автора возникла изначально задача проследить за переполнением стека, то я бы ему рекомендовал сделать самому стек в динамической памяти, который будет полностью под его контролем, обработку переполнения и расширение можно будет делать легко и просто. Как считаешь, Qraizer? Думаю это лучший выход из ситуации, чем возиться со сторонними либами-костылями .

Сообщение отредактировано: neokoder - 27.11.11, 04:48

Начиная с какой версии есть обработка системных исключений?

Эта тема была разделена из темы "Сборки MinGW(GCC-win32) от niXman"

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Сообщение отредактировано: повстанец - 27.11.11, 14:29

Нету в GCC поддержки SEH на уровне компилятора.

http://gcc.gnu.org/wiki/WindowsGCCImprovements

Цитата

Windows uses its own exception handling mechanism known as Structured Exception Handling (SEH). A great overview of this mechanism can be found here.
Unfortunately, GCC does not support SEH yet. Casper Hornstrup had created an initial implementation, but it was never merged into mainline GCC.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата повстанец @ 27.11.11, 14:28

обработка системных исключений

это еще что такое? оО

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата niXman @ 27.11.11, 15:56

это еще что такое? оО

что-то типа такого:

__try
{
    *((int *)0) = 0;
}
__catch
{
    std::cout << "segment fault" << std::endl;
}

только я не понимаю зачем это нужно.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Сообщение отредактировано: DEADHUNT - 27.11.11, 16:13

Цитата DEADHUNT @ 27.11.11, 16:12

что-то типа такого

ясно.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата niXman @ 27.11.11, 15:56

Цитата повстанец @ 27.11.11, 14:28

обработка системных исключений

это еще что такое? оО

смешно... Это когда исключения генерируются системой. Например, при переполнении стека.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата повстанец @ 27.11.11, 16:36

Это когда исключения генерируются системой. Например, при переполнении стека.

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

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

гы... а в компиляторе от мелкомягких есть... И вообще, я так понимаю mingw это сборка для винды, так что вот!

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Сообщение отредактировано: повстанец - 27.11.11, 17:38

Цитата DEADHUNT @ 27.11.11, 16:12

только я не понимаю зачем это нужно.

Для СОМ, к примеру. Из-за того, что одна прога запихнула невалидный адрес, сервер (а за ним и все остальные клиенты) упасть не должен.

Добавлено 27.11.11, 17:13

Цитата niXman @ 27.11.11, 16:46

это какая-то поделка, по всей видимости. в стандарте ничего про это нет.

В стандарте много чего нет. Например там нет ни одного способа связывания с системным API.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Если мы говорим о том, что является частью API ОС и что тем не менее Стандарт любезно оставил на усмотрение реализаций, в данном случае это связь системых исключений с C++ Exception Handling, то уповать на Стандартную неопределённость поведения значит заметать мусор под ковёр. Системные исключения в WinAPI присутствуют в виде технологии SEH, и она играет важнейшую роль для 24/7 приложений.

Цитата DEADHUNT @ 27.11.11, 16:44

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

Нормально написанная программа в таком случае не должна использовать никаких библиотек. Даже статических. О динамических, COM- ActiveX- итп-компонентах, и даже просто о плагинной архитектуре можно просто забыть. Да, в таких случаях SEH не нужна, ибо мы сами пишем весь код своего приложения, и вполне способны отвечать за его качество. Но всё равно остаётся процесс разработки и отладки.
niXman, вопрос, как я понимаю, пока не заключается в поддержке SEH, пока вопрос выглядит как "при каких условиях g++ может не поддерживать C++ Exception Handling", ибо транслировать SEH в C++EH можно тем же WinAPI, коль уж портированный под WinAPI компилятор не поддерживает расширения синтаксиса, рекомендованные MS для своих ОСей уже без малого 20 лет.

Это сообщение было перенесено сюда или объединено из темы "GCC-win32 and SEH"

Цитата Повстанець @ 27.11.11, 17:12

Для СОМ, к примеру. Из-за того, что одна прога запихнула невалидный адрес, сервер (а за ним и все остальные клиенты) упасть не должен.

это стандартная ситуация. но я совершенно не понимаю для чего тут SEH...

if ( ptr_type ptr = server->get_iface(...) ) {
   work with ptr if it`s valid
} else {
   throw exception_type(...);
}

Невалидные указатели не обязательно null_ptr. (int*)0x12345678 тоже с большой долей вероятности будет невалидным и вызывать EXCEPTION_ACCCESS_VIOLATION при разыменовании.
За действия не нашего кода мы не можем отвечать, но мы можем защититься от них, поймав фаулт, возникший в плагине, и вырубив такой плагин к чертям, к примеру. SEH для этого - стандартная и очень удобная практика для WinAPI.

Цитата Qraizer @ 28.11.11, 09:06

(int*)0x12345678

ну так это означает что баг в том коде который вернул такой указатель. к чему лечить последствия?
не могу представить здравый код, который возвращал бы случайные указатели. ( (int*)random() )

Сообщение отредактировано: niXman - 28.11.11, 09:31

Здравый и не будет. Только откуда знать, что он здравый, если он не наш? Даже если его автор - Компания с Большим Именем.

Цитата niXman @ 28.11.11, 09:30

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

Т.е. ты предлагаешь, к примеру, такую ситуацию: в Photoshop закосячил какой-то плагин, вернул не валидный адрес или ещё что, и Photoshop вместо того, чтобы поймать исключение и написать пользователю что плагин глючный, просто тупо упадёт не сохранив работу пользователя.
Что-то мне кажется пользователей такой расклад не порадует.
Ты не можешь отвечать за код, который написан не тобой, и должна быть возможность оградиться от последствий исполнения такого кода.
Собственно это реализуется с помощью WinAPI даже без поддержки SEH на уровне компилятора, так что...

Qraizer, если ты перенесёшь тему в холивар, где же я буду сообщать о том, как я предлагаю работать с исключениями? А я предлагаю.
Вот я провёл тут небольшое исследование. Помнишь, ты попрошал у niXmanа, почему не работает код отсюда (сообщение номер 7)?


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

Но тут почитав кое-что, поспрошав людей, я понял, что она должна внести ещё и изменения в связный список элементов типа EXCEPTION_REGISTRATION_RECORD! А она этого не делает! То есть я вот тут выложил программу, кому интересно запустите, компилятор g++ должен быть. Хе, адрес обработчика после УДАЧНОЙ отработки SetUnhandledExceptionFilter НЕ ИЗМЕНЯЕТСЯ.

Первый раз вижу API-функцию, так половинчато работающую. Предварительный вывод: компилятор g++ в этой части вообще не причём. Имеется задокументированная функция, которая должна установить новый обработчик исключений, которая его якобы устанавливает, но не устанавливает. Это у меня вопрос к майкрософту возник, почему так.
Щас я пытаться буду написать свою реализацию SetUnhandledExceptionFilter

#include <windows.h>
#include <iostream>
#include <stdio.h>
#include <excpt.h>
  
      
      
                                   //+
                                   //+
                                   //+
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS x)      {
 //Это функция-обработчик исключений, которая никогда не вызывается
 printf ("hello, word!\n");
 getchar ();
 return 0;
}
            //....................................................
                                   //+
                                   //+
                                   //+
      
int main(){
 
 SetConsoleCP (1251);
 SetConsoleOutputCP (1251);
 
 
 PNT_TIB pTIB;
 PEXCEPTION_HANDLER handler_;
 
 printf ("новая функция-обработчик находится по адресу: %x\n"\
         ,(unsigned int)TopLevelUnhandledExceptionFilter);
 
 
                                 //++
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 pTIB= (PNT_TIB)NtCurrentTeb();
// //NtCurrentTeb() недокументированная функция,
//суть ассемблерная вставка где-то
 
 //А это сразу указатель найдём на функцию-обрабочик исключения
 handler_= ((PEXCEPTION_REGISTRATION_RECORD)pTIB->ExceptionList)->handler;
 
 
 printf ("\nДо вызова SetUnhandledExceptionFilter:\n");
 printf ("TEB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("TIB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("Стандартная Функция-обработчик исклюючения находится по адресу== %x\n", (unsigned int)handler_);
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                                 //++
 
 
//устанавливаем обработчик исключения
printf ("\nSetUnhandledExceptionFilter вернула %x\n\n",\
         (unsigned int)SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter));;
 
 
                                 //++
//повторяем процедуру нахождения адреса обраблотчика
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 pTIB= (PNT_TIB)NtCurrentTeb();
 handler_= ((PEXCEPTION_REGISTRATION_RECORD)pTIB->ExceptionList)->handler;
 printf ("После вызова SetUnhandledExceptionFilter:\n");
 printf ("TEB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("TIB текущего потока== %x\n", (unsigned int)pTIB);
 printf ("Новая Функция-обработчик исклюючения находится по адресу== %x\n", (unsigned int)handler_);
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                                 //++
 getchar ();
 return 0;
}

Сообщение отредактировано: повстанец - 02.12.11, 14:26

Цитата повстанец @ 02.12.11, 21:07

Не ловит, доказательства в моём посту номер 153

Я не знаю что ты там понаписал, у меня ловит:

#include<stdio.h>
#include<windows.h>
 
int *pointer=0;
 
LONG WINAPI myUnhandledExceptionFilter(struct _EXCEPTION_POINTERS *ExceptionInfo)
{
    printf("Exception %08X at %08X\n",
            ExceptionInfo->ExceptionRecord->ExceptionCode,
            ExceptionInfo->ExceptionRecord->ExceptionAddress );
    return EXCEPTION_EXECUTE_HANDLER;
}
 
int main(void)
{
    SetUnhandledExceptionFilter(myUnhandledExceptionFilter);
    printf("Generating Exception...\n");
    *pointer=123;
    printf("Done!\n");
    return 0;
}

>test.exe
Generating Exception...
Exception C0000005 at 0040104F

Добавлено 02.12.11, 21:54

Цитата niXman @ 02.12.11, 20:00

собственно, ЯП выполняемые на ВМ обязаны работать быстрее компилируемых, ибо эвристический анализ.

А как насчёт того, что код VM потом всё равно переводится JIT компилятором в нативный для исполнения? А на это время надо.

Цитата повстанец @ 02.12.11, 14:24

Qraizer, если ты перенесёшь тему в холивар, где же я буду сообщать о том, как я предлагаю работать с исключениями?

Это разговор даже не для С++ Общих. Тут прямая дорога обратно в Системное и WinAPI.

Добавлено 02.12.11, 22:22

!

Дух Повстанца, создание клонов запрещено Правилами. Незачем было доводить ситуацию до критической. Если твой клон стремится во флейм и тут не будет появляться, я не против. Банить или не банить, пусть решают тамошние модеры. Но тут уровень вверх твой.

Сообщение отредактировано: Qraizer - 02.12.11, 22:22

Цитата cppasm @ 02.12.11, 21:50

Я не знаю что ты там понаписал, у меня ловит:

У тебя не ловит

      #include<stdio.h>
      #include<windows.h>
      #include<iostream>
      
      int *pointer=0;
      
      LONG WINAPI myUnhandledExceptionFilter(struct _EXCEPTION_POINTERS *ExceptionInfo)
      {
          printf("Exception %X at %X\n",
                  (unsigned int)ExceptionInfo->ExceptionRecord->ExceptionCode,
                  (unsigned int)ExceptionInfo->ExceptionRecord->ExceptionAddress );
          return EXCEPTION_EXECUTE_HANDLER;
      }
      
      int main(void)
      {
          SetUnhandledExceptionFilter(myUnhandledExceptionFilter);
          printf("Generating Exception...\n");
          throw std::exception();
          printf("Done!\n");
          return 0;
      }

Generating Exception...
terminate called after throwing an instance of 'std::exception'
  what():  std::exception
 
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

компиляторр g++, windows xp

Цитата повстанец @ 02.12.11, 22:50

throw std::exception();

? Ты путаешь обработку исключений С++ и SEH.

Нет, я их разделяю.
Я знаю, что в конечном итоге, как любая из высокоуровневых функций сводится к вызову API-функции, так любое из исклбючений сводится к генерации одного из 22-х исключений (столько у меня в windows.h)

...Итак, обработчик, установлен, по генерации какого бы то ни было исключения, срабатывает первый обработчик в цепочке исключений. Далее всё зависит от реализации обработчика, но как мы видим он должен обработать любое исключение.

Тут ведь как, вот код:

        throw std::exception();
        getchar ();

либо срабатывает обработчик, либо следующая за throw std::exception(); инструкция. Третьего не дано. Ты ведь знаешь, в ассемблерном коде всё последовательно идут инструкция за инструкцией и относительно любой из инструкций можно утвержать:

1)она либо генерит системное исключение
2)либо нет.

Третьего не дано. И если не генерит, значит продолжает программу в неаварийном режиме. А теперь: ни одна из ассемлерных инструкций не вызвала системного исключения. Значит что? Или существуют какие-то икс-системные исключения (но всё же именно системные), коль скоро мы говорим об инструкциях ассемблера, для которых существует свой тайный обработчик, скрытый от всех глаз?

Если я не прав, хотелось бы конкретики, а не общих слов, типа ты не прав потому, что ты не прав. Я и сам вижу, что сообщения не перехватываются.

Сообщения были разделены в тему "SEH и <signal.h> как технология"

Сообщение отредактировано: повстанец - 02.12.11, 23:40

Короче, дела обстоят так. Последним СУЩЕСТВЕННЫМ вопросом в этой теме было обсуждение неработоспособности установщика обработчика системных исключений и самого обработчика соответственно при такой генерации исключений:

throw std::exception();

Я исследовал, что происходит при генерации этого исключения и почему не срабатывает встроенный обработчик.
Так вот, исключение КАК ТАКОВОЕ не генерится. То есть абсолютно.

Прооисходит обыкновенный вывод на печать программой половины диагностического сообщения, потов вызов функции abort(), которая печатает вторую половину сообщения (об этом можно прочеть в MSND)

Мне могут возразить: а не обстоят ли дела так, что: системное исключение всё же ГЕНЕРИТСЯ-> управление передаётся на цепочку SEH-обработчиков-> один из которых начинает выводить надписи, а потом вызывает abort()?

Нет, дела так не обстоят. Попробуем, это доказать, Предположим, код

throw std::exception();

генирит системное исключение. Что тогда? А тогда:
Windows решает, хочет ли он послать это исключение обработчику исключений программы. Если это так, и если программа отлаживается, Windows уведомит отладчик о возникновении исключения, приостанавливая программу и посылая EXCEPTION_DEBUG_EVENT (значение 1h) отладчику (это первое предупреждение);

Нам остаётся только запустить прогу с этим исключением и посмотреть, чем дело кончится- прога просто завершится по abort(), а если бы сгенерилось системное исключение, то она на соответствующей инструкции ассемблера споткнулась.

Сообщение отредактировано: повстанец - 03.12.11, 08:56

повстанец, я одного все никак понять не могу: что, система бажит? или поведение каких-то вендовых функций не соответствует описанию?

niXman, пока я не узнаю, как из моего последнего поста родились твои вопросы, я воздержусь от ответов. А то мало ли что тебе в голову придёт спросить...

Сообщение отредактировано: повстанец - 03.12.11, 09:19

Цитата niXman @ 03.12.11, 09:02

я одного все никак понять не могу: что, система бажит? или поведение каких-то вендовых функций не соответствует описанию?

Бажит повстанец, потому что не читает ни MSDN, ни то, что ему пишут (тему правда уже почикали).
UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.
Это было написано предыдущим постом, перед тем как я код запостил.

Вот код, который ловит и исключения языка.
Хотя это не гарантируется и зависит от реализации исключений компилятором вообще-то.

#define _WIN32_WINNT 0x0500
 
#include<stdio.h>
#include<windows.h>
 
LONG CALLBACK myVectoredHandler(EXCEPTION_POINTERS *ExceptionInfo)
{
    printf("Exception %08X at %08X\n",
            ExceptionInfo->ExceptionRecord->ExceptionCode,
            ExceptionInfo->ExceptionRecord->ExceptionAddress );
    return EXCEPTION_CONTINUE_SEARCH;
}
 
int main(void)
{
    void *handler=AddVectoredExceptionHandler(1, myVectoredHandler);
    if(!handler)
    {
        printf("Can not register Vectored Exception Handler!\n");
        return -1;
    }
    printf("Generating Exception...\n");
    throw 0;
    printf("Done!\n");
    RemoveVectoredExceptionHandler(handler);
    return 0;
}

Цитата cppasm @ 03.12.11, 11:17

Бажит повстанец

ну было у меня такое подозрение, но подумал что возможно я ошибаюсь..а нет

Цитата cppasm @ 03.12.11, 11:17

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.
Это было написано предыдущим постом, перед тем как я код запостил.

Я считал, что всякое исключение языка С++ в конечном счёте генерит системное исключение. Ты вот знал, что это не так, а я нет. И веришь, нет, это надо было сказать дословно, ибо из утверждения, что

"SetUnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения."
я не делаю вывод, что исключение языка С++ не генерит системных исключений. Я этого просто не понимаю.

Но здесь мне пришло время делать самому. И я сам всё понял и подробно всё описал в посту номер 50. Заметь, я не клянчил ни у тебя ни у кого бы то ни было чего-нибудь. Я сам разобрался.

Вот этот ключевой вопрос:
"SetUnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения." до меня дошёл через руки. Я больше никого ни о чём не спрашивал. Чё тебе надо? Да, ты программист лучше чем я. Доволен? И больше не беспокойся никогда, лучше я с дураком потеряю, чем с тобой найду.

повстанец, злой ты.

niXman, ты давай по существу говори из чего такие вопросы возникли:
"что, система бажит? или поведение каких-то вендовых функций не соответствует описанию?", как ты воздух сотрясать умеешь, я уже увидел.

Я допёр, наконец, кажись.
gcc использует собственный механизм C++EH. Весь его движок реализован посредством RTL. Что является грубой ошибкой на платформе WinAPI, ибо ни ОС ничего не знает о проходящих C++-исключениях и тем самым не сможет по дороге вызывать __finally, даже если ты, повстанец, и реализуешь их аналоги своими силами, ни программа ничего не знает о возникающих системых исключениях и тем самым не сможет по дороге вызывать деструкторы объектов. Та же проблема будет у gcc и под OS/2, стопудово.
Все компиляторы, поддерживающие SEH, реализуют C++EH через некий специальный ExceptionCode системного исключения. Из предыдущих постов видно, что он равен 0xE06D7363, что, впрочем, недомунтировано. throw реализуется через RaiseException(), где параметрами идёт typeid() от типа исключения и его значение (или ссылка), catch реализуется через __except() с выражением, фильтрующим пришедший тип исключения по RTTI, размотка стека выполняется ОСью через RtlUnwind() и аналогичные, деструкторы размещаются в блоках __finally. Примерно так, очень упрощённо, конечно.
повстанец, забудь о gcc под Win. По крайней мере про эту свою сборку.

Добавлено 03.12.11, 12:13
cppasm, UnhandledExceptionFilter() должен ловить все не перехваченные исключения. Это видно по прежним постам.

Цитата Qraizer @ 03.12.11, 12:12

забудь о gcc под Win

Звучит как приговор. Ты уж извини, я не понял ничё. RTL там, всё такое... Но щас у меня очень даже неплохо сигнализироуется о переполнениии стека.

Приговор, приговор. Если обе технологии не дружат друг с другом, значит ты будешь отгребать попеременно от обоих.

Qraizer, покажи код который как-то ни так работает на мингве, и "так" на "правильном" компиляторе. чтоб было о чем с девелоперами общаться.

Qraizer, а давай по простому? Смотри, реализация C++ исключений В g++ компиляторе, как я понял суть те же самые условные-безусловные переходы, только в другой форме. Так, а теперь, если вдруг возникают системны исключения (В ЛЮБОМ МЕСТЕ ПРОГРАММЫ), они обрабатываются осью самым простым и безхитростным способом- включается отладчик ну или программа просто заканчивается. Тут я не вижу никакого пересечения интересов- просто осью смотрится регистр fs, ищется и берётся первый элемент связном списке (случай, когда меняем связный список пока не рассматриваем), а в этом элементе адрес функции X, которая и вызывает отладчик или что там по сценарию.

Наконец, добавляем сюда SetUnhandledExceptionFilter и смотрим, какое зло она может нам привнести. Ну какое... Опять же при возникновении C++ исключений, её действие пройдёт незамеченным. Если возникнет системное исключение (В ЛЮБОМ МЕСТЕ), то опять же, ось смотрит в регистр fs, находит там адрес первого и единственного элемента в связном списке, и через него адрес знакомой уже нам вызываемой функции X. Вызывается эта функция и из неё недр каким-то хитрым способом вызывается обработчик исключений, который мы установили.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Можно в это всё благолепие внести ещё создание цепочки SEH-обработчиков, но пока обойдёмся, с ними я не разобрался ещё.

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

Сообщение отредактировано: повстанец - 03.12.11, 13:16

Цитата cppasm @ 03.12.11, 11:17

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.

Он ловит ВСЕ исключения и SEH и C++.

Добавлено 03.12.11, 13:25

Цитата niXman @ 03.12.11, 12:56

Qraizer, покажи код который как-то ни так работает на мингве, и "так" на "правильном" компиляторе. чтоб было о чем с девелоперами общаться.

Пожалуйста тебе:

#include <windows.h>
#include <stdio.h>
#include <tchar.h>
#include <conio.h>
 
int z,p=1,d=0;
 
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
{
  printf ("Поймали исключение. Код 0x%X.\n",except_info->ExceptionRecord->ExceptionCode);
  return EXCEPTION_EXECUTE_HANDLER;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
  
  SetConsoleCP (1251);
  SetConsoleOutputCP (1251);
 
  SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
  
  //SEH, деление на ноль
  z=p/d;
 
  //сюда можно будет попасть только с использованием __except
  printf("Нажмите любую клавишу...\n");
  _getch();
  return 0;
}

niXman, ты думаешь по твоим просьбам разработчики GCC вот так вот разбегутся и сразу прям реализуют поддержку SEH на Windows?
GCC изначально разрабатывался для Unix-Linux, MSVC естественно для Windows родной. Поэтому есть золотое правило: в Unix-Linux используй GCC, в Windows использую MSVC. И не будет никаких заморочек!

Сообщение отредактировано: neokoder - 03.12.11, 13:31

Цитата neokoder @ 03.12.11, 13:20

ты думаешь по твоим просьбам разработчики GCC вот так вот разбегутся и сразу прям реализуют поддержку SEH на Windows?

нет. цель не в этом. просто я полагал, что в этом примере нет SEH...

Добавлено 03.12.11, 13:33
при том, вот что выводит твой пример:

Цитата

C:\test>except
In TopLevelUnhandledExceptionFilter.
Catched exception with code 0xC0000094.

покажи что он должен выводить.

Добавлено 03.12.11, 13:34
т.е. проблема в том, что не выводит это?: printf("Нажмите любую клавишу...\n");

Сообщение отредактировано: niXman - 03.12.11, 13:34

Цитата neokoder @ 03.12.11, 13:20

Цитата cppasm @ 03.12.11, 11:17

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.

Он ловит ВСЕ исключения и SEH и C++.

Тебе самому не надоело одно по одному гонять? В сообщении номер 5 я тебе сказал и показал, как именно она не ловит C++ исключения. Потом мы выяснили, что она ловит C++ исключения если исползуется MSVS, вот твоё сообщение номер 12:

Цитата

В MSVS всё будет работать. Я думал может и в твоём компиляторе по аналогии заработает.

И щас ты снова безапелляционно, без всяких оговорок на компилятор заявляешь, что заявляешь. Не стыдно? Неплохое начало холивара.

Сообщение отредактировано: повстанец - 03.12.11, 13:39

Цитата niXman @ 03.12.11, 13:31

при том, вот что выводит твой пример:

Естественно в MSVC он это и должен выводить.

Речь идёт о GCC. GCC(Cygwin) у меня выводит следующее:

      0 [main] seh 4292 exception::handle: Exception: STATUS_INTEGER_DIVIDE_BY_Z
ERO
   2167 [main] seh 4292 open_stackdumpfile: Dumping stack trace to seh.exe.stack
dump

Цитата niXman @ 03.12.11, 13:31

т.е. проблема в том, что не выводит это?: printf("Нажмите любую клавишу...\n");

Он и не должен выводить. Посмотри я подправил код. Будет выводить только при использовании __try, __except, а ТоpUnhandledExceptionFilter это последний код который выполнит программа если он возвращает EXCEPTION_EXECUTE_HANDLER. Так что все правильно.

Слуiай, а ты не в MinGW компилил пример? Может это только у Cygwin нет поддержки работоспособной SetUnhandledExceptionFilter?

Сообщение отредактировано: neokoder - 03.12.11, 13:49

Цитата neokoder @ 03.12.11, 13:47

Естественно в MSVC он это и должен выводить.

ок

Цитата neokoder @ 03.12.11, 13:47

Речь идёт о GCC.

я в курсе

Цитата neokoder @ 03.12.11, 13:47

у меня выводит следующее:

я хз чем ты тестишь. но самое интересное в том, что приведенный вывод я получил использовав свои сборки MinGW. никакого MSVC.

посему, еще раз повторяю: покажи код который как-то ни так работает на мингве, и "так" на "правильном" компиляторе.
спасибо.

Добавлено 03.12.11, 13:52
и да, сейчас я установлю экспресс студию, что умельцы мне моцг не парили. а то прям чудеса какие-то творятся...

Сообщение отредактировано: niXman - 03.12.11, 13:52

повстанец, не поднимай пыть, ладно? Я говорил о том что в MSVC UnhandledExceptionFilter ловит ВСЕ исключения и SEH и C++. А то что там всякие неполноценные реализации GCC для Windows не работают как надо это меня мало интересует. Эт ты фанат , вместо того чтобы просто воспользоваться MSVC ты занимаешь садомазохизмом!

только что еще и доку по SetUnhandledExceptionFilter() прочел. код собранный MinGW`ом работает как и должен.

Цитата niXman @ 03.12.11, 13:50

но самое интересное в том, что приведенный вывод я получил использовав свои сборки MinGW.

Ну вот значит это косяки Cygwin. Значит будем считать, что SetUnhandledExceptionFilter отлично пашет в MinGW.

А что насчёт __try __except поддерживается этот синтаксис в MinGW? И скажи какой версией GCC компилишь? И MinGW какая версия? Сейчас поставлю, посмотрю сам ради интереса.

Добавлено 03.12.11, 13:59
niXman, в общем такой код скомпилится в MinGW?

#include <windows.h>
#include <stdio.h>
 
 
 
int z,p=1,d=0;
 
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
{
  printf ("Поймали исключение. Код 0x%X.\n",except_info->ExceptionRecord->ExceptionCode);
  return EXCEPTION_EXECUTE_HANDLER;
  
}
  
 
int main()
{
  
  SetConsoleCP (1251);
  SetConsoleOutputCP (1251);
 
 
  SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
 
  __try
  {
     //SEH, деление на ноль
     z=p/d;
    
     //исключение bad:alloc (С++ исключение)
     //__int64 *pI = new __int64[0xFFFFFFF];
 
  }
  __except(EXCEPTION_EXECUTE_HANDLER)
  {
     printf("Попали в __except\n");
  }
 
  
  printf("Программа завершила свою работу. Нажмите любую клавишу...\n");
  getchar();
  return 0;
}

Сообщение отредактировано: neokoder - 03.12.11, 14:07

Цитата neokoder @ 03.12.11, 13:53

повстанец, не поднимай пыть, ладно? Я говорил о том что в MSVC UnhandledExceptionFilter ловит ВСЕ исключения и SEH и C++.

Лгун. Я один тут не вижу слова MSVC?

Цитата

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.

Цитата

Он ловит ВСЕ исключения и SEH и C++.

сообщение номер 64

Сообщение отредактировано: повстанец - 03.12.11, 14:06

Цитата neokoder @ 03.12.11, 13:55

Ну вот значит это косяки Cygwin.

ну дык! сижвин и не должен это обрабатывать! он же эмулятор!

Цитата neokoder @ 03.12.11, 13:55

А что насчёт __try __except поддерживается этот синтаксис в MinGW?

микрософткомпилятор славится своим не соответствием стандарту. ты что считаешь, что его несоответствия должны перенести в стандарт?
ни один компилятор в здравом уме не станет реализовывать __try __except. засмеют же.

Цитата neokoder @ 03.12.11, 13:55

И скажи какой версией GCC компилишь? И MinGW какая версия?

у меня в пописи. 4.6.1/4.6.2/4.7.0

Цитата повстанец @ 03.12.11, 14:04

Я один тут не вижу слова MSVC?

Специально для тебя:

Цитата cppasm @ 03.12.11, 11:17

UnhandledExceptionFilter НЕ ЛОВИТ ИСКЛЮЧЕНИЯ ЯЗЫКА, она ловит только системные исключения.

Он ловит ВСЕ исключения и SEH и C++ в MSVC.

И ещё вот это также специально для тебя :

Цитата cppasm @ 03.12.11, 11:17

Бажит повстанец, потому что не читает ни MSDN, ни то, что ему пишут (тему правда уже почикали).

neokoder, всегда так делай

код скомпиленный в msvc2010-express работает так же. значит вопрос закрыт.

Цитата niXman @ 03.12.11, 14:09

микрософткомпилятор славится своим не соответствием стандарту. ты что считаешь, что его несоответствия должны перенести в стандарт?
ни один компилятор в здравом уме не станет реализовывать __try __except. засмеют же.

Ну хорошо, давай в стандартном варианте. Вот такой код будет работать правильно в MinGW:

#include <windows.h>
#include <stdio.h>
 
 
 
int z,p=1,d=0;
 
LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
{
  printf ("Поймали исключение. Код 0x%X.\n",except_info->ExceptionRecord->ExceptionCode);
  return EXCEPTION_EXECUTE_HANDLER;
  
}
  
 
int main()
{
  
  SetConsoleCP (1251);
  SetConsoleOutputCP (1251);
 
 
  SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
 
  try
  {
     //SEH, деление на ноль
     z=p/d;
  }
  catch(...)
  {
     printf("Попали в catch\n");
  }
 
  
  //исключение bad:alloc (С++ исключение)
    //__int64 *pI = new __int64[0xFFFFFFF];
 
  printf("Программа завершила свою работу. Нажмите любую клавишу...\n");
  getchar();
  return 0;
}

В MSVC получаем(компилируя c /EHa):

Попали в catch
Программа завершила свою работу. Нажмите любую клавишу...

Добавлено 03.12.11, 14:24

Цитата niXman @ 03.12.11, 14:20

код скомпиленный в msvc2010-express работает так же. значит вопрос закрыт.

Ёпти, ты думаешь я не проверяю что ли прежде чем выкладывать код? Если я даю код значит я его проверил в MSVC. Так что не зачем тебе было проверять в MSVC++.
Ты лучше последний примерчик скомпиляй плиз в своём MinGW. Какой будет результат? А то я тут пока скачаю, пока поставлю...

Сообщение отредактировано: neokoder - 03.12.11, 14:25

Цитата neokoder @ 03.12.11, 14:21

давай в стандартном варианте

ты походу троллишь, да? какой же это стандартный вариант?
стандартным, будет выбросить throw из try{} блока.

выводит это:

Цитата

C:\test>cl except.cpp
Microsoft ® 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright © Microsoft Corporation. All rights reserved.

except.cpp
except.cpp(26) : warning C4530: C++ exception handler used, but unwind semantics
are not enabled. Specify /EHsc
Microsoft ® Incremental Linker Version 10.00.30319.01
Copyright © Microsoft Corporation. All rights reserved.

/out:except.exe
except.obj

C:\test>except
Попали в __except
Программа завершила свою работу. Нажмите любую клавишу...


C:\test>g++ except.cpp -oexcept

C:\test>except
Поймали исключение. Код 0xC0000094.

C:\test>

Добавлено 03.12.11, 14:35
neokoder, еще, способы убедить всех в том что микрософт-специфик расширения являются стандартом, будут?

E:\vso_moio\Программирование_на_C++\Новая папка (5)>cmd
Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.
 
E:\vso_moio\Программирование_на_C++\Новая папка (5)>ra_6.exe
Поймали исключение. Код C0000094
 
E:\vso_moio\Программирование_на_C++\Новая папка (5)>

g++

Сообщение отредактировано: повстанец - 03.12.11, 14:36

Цитата повстанец @ 03.12.11, 14:36

g++

покажи вывод "g++ -v"

Цитата niXman @ 03.12.11, 14:26

C:\test>g++ except.cpp -oexcept

C:\test>except
Поймали исключение. Код 0xC0000094.

Ну вот судя по всему с G++ у тебя сработал TopLevelUnhandledExceptionFilter, а не catch, как должно быть. Что и требовалось доказать!

niXman, я поставил себе mingw32-gcc-4.6.2-release-c,c++,objc,objc++,fortran-sjlj.7z по ссылке у тебя в подписи. Может че другое надо было ставить? В общем запускаю g++ seh.cpp -oexcept. Если из другой директории, он пишет "Отказано в доступе", если из bin'а он пишет: "g++: error: CreateProcess: No such file or directory". Что это за фигня и как её побороть?

Сообщение отредактировано: neokoder - 03.12.11, 14:41

Цитата neokoder @ 03.12.11, 14:39

Что это за фигня и как её побороть?

это микрософт-специфик проблема. пиши в микрософт.

Цитата niXman @ 03.12.11, 14:40

это микрософт-специфик проблема. пиши в микрософт.

Ты прикалываешься, да?

Цитата neokoder @ 03.12.11, 14:42

Ты прикалываешься, да?

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

E:\vso_moio\Программирование_на_C++\Новая папка (5)>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=e:/dev-cpp_nomingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0_20100311/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --ena
ble-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 20100311 (experimental) (GCC)

neokoder, у тебя ви7 или виста?

Цитата niXman @ 03.12.11, 14:26

neokoder, еще, способы убедить всех в том что микрософт-специфик расширения являются стандартом, будут?

Ты о чем? Тебе не понравились __try __except, я тебе привел пример с try-catch. Не, ну если у тебя try-catch уже не влазиют в стандарт, то пора бы тебе задуматься, что это за стандарт такой. Может он у тебя в голове просто, стандарт этот?

Добавлено 03.12.11, 14:45

Цитата niXman @ 03.12.11, 14:44

neokoder, у тебя ви7 или виста?

Win7 64бит.

Цитата повстанец @ 03.12.11, 14:43

4.5.0 20100311 (experimental)

да ты че... во первых - раритет. во вторых - тестовая версия.

Добавлено 03.12.11, 14:47

Цитата neokoder @ 03.12.11, 14:44

Тебе не понравились __try __except, я тебе привел пример с try-catch.

либо ты прикидываешься, либо второе... в стандарте нет ничего про то, что С++ исключения должны обрабатывать ошибки деления на ноль, разыменование нулевого указателя, и всякие самопальные расширения ОС и производителей компиляторов.

Сообщение отредактировано: niXman - 03.12.11, 14:49

повстанец, C++EH будут в нём работать нормально. Сами по себе, в отрыве от SEH. Можно допилить его до поддержки SEH путём SetUnhandledExceptionFilter(), транслируя в своём обработчике SEH-овые исключения в написанный специально для этого некий класс, и в итоге работая т.о. только с C++EH. Но подружить обе технологии не удастся, в лучшем случае будешь костылять то одно, то другое для тех или иных конкретных ситуаций. Программа одна, кадры исключений долждны быть в едином списке, и те, и другие, однако g++ имеет собственный C++EH движок, отличный от SEH, который предоставляется ОС.

Цитата niXman @ 03.12.11, 14:09

микрософткомпилятор славится своим не соответствием стандарту.

Ни один компилятор не соответствует Стандарту в полной мере. Только не надо путать нарушения Стандарта и расширения Стандарта. Стандарт допускает реализациям расширять предсотавляемые возможности, если они не противоречат Стандарту. G++ и рядом с MS не валялся по части таких "нарушений". MSные компиляторы расширяют синтаксис для поддержки особенности платформы. И делают это в соответсвтие с правилами Стандарта. Чего нельзя сказать о g++. Он меня уже не раз удивлял своими фичами.

Сообщение отредактировано: Qraizer - 03.12.11, 14:50

Цитата Qraizer @ 03.12.11, 14:48

Только не набо путать нарушения Стандарат и расширения Стандарта. G++ и рядом с MS не валялся по части таких "нарушений". MSные компиляторы расширяют синтаксис для поддержки особенности платформы. И делают это в соответсвтие с правилами Стандарта. Чего нельзя сказать о g++. Он меня уже не раз удивлял своими фичами.

ты ведь откровенно лжешь себе(микрософту) в пользу. низко, увы.

Добавлено 03.12.11, 14:53
как можно превратить несоответствие стандарту в расширение стандарта? это же синонимы.

Сообщение отредактировано: niXman - 03.12.11, 14:53

И ещё раз повторю. Глупо говорить о наличии порта под некую платформу, если эта платформа не поддерживается полностью. Ну, пусть не полностью, но ключевые аспекты архитектуры должы быть поддержаны. Ну, пусть не сразу. Но блин, почти 20 лет прошло!

Так я не понял почему у меня не работает MinGW, Что это блин за стандарты такие если они ни хрена не работают?

С MSVC таких проблем не было.

Сообщение отредактировано: neokoder - 03.12.11, 14:56

Цитата niXman @ 03.12.11, 14:51

как можно превратить несоответствие стандарту в расширение стандарта?

Почитай Стандарт. И если уж не согласен и обвиняешь, обвиняй обе стороны.

neokoder встречался с подобным, не твой случай?

Сообщение отредактировано: повстанец - 03.12.11, 14:56

про "соответствие микрософткомпилера стандарту" мы все знаем по этой теме. но что-то подобных тем в сторону gcc/edg/comeau найдено не было.
так что ты этавот...заканчивай с лапшой

Добавлено 03.12.11, 15:00

Цитата neokoder @ 03.12.11, 14:55

С MSVC таких проблем не было.

так ты ведь микрософткомпилер ставил на микрософтвенду. не удивительно что оно работает

Добавлено 03.12.11, 15:01

Цитата Qraizer @ 03.12.11, 14:57

празднуем трёхмесячный дидлайн на проекте

поздравляю!

Добавлено 03.12.11, 15:04

Цитата Qraizer @ 03.12.11, 14:54

если эта платформа не поддерживается полностью.

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

Добавлено 03.12.11, 15:05
neokoder, мне тут подсказывают, что нельзя ставить в корень дисков. а лучше всего в каталог документов пользователя. (сам не проверял)

Сообщение отредактировано: niXman - 03.12.11, 15:05

Цитата повстанец @ 03.12.11, 14:56

neokoder встречался с подобным, не твой случай?

Я прописал в PATH все пути к папкам, вложенным в mingw где есть exe-Файлы. Все равно пишет что "Отказано в доступе" если из другого каталога вызываю g++.
Пришлось скопировать исходник в папку bin и наконец то он заработал, но вот что мне выдал:

seh.cpp:1:21: error: no include path in which to search for windows.h
seh.cpp:2:19: error: no include path in which to search for stdio.h
seh.cpp:9:1: error: 'LONG' does not name a type
seh.cpp: In function 'int main()':
seh.cpp:20:21: error: 'SetConsoleCP' was not declared in this scope
seh.cpp:21:27: error: 'SetConsoleOutputCP' was not declared in this scope
seh.cpp:24:31: error: 'TopLevelUnhandledExceptionFilter' was not declared in thi
s scope
seh.cpp:24:63: error: 'SetUnhandledExceptionFilter' was not declared in this sco
pe
seh.cpp:39:31: error: 'printf' was not declared in this scope
seh.cpp:44:71: error: 'printf' was not declared in this scope
seh.cpp:45:11: error: 'getchar' was not declared in this scope

Ну и что это за хрень? Он что инклуды не видит что ли? Как их подключить то на автомате чтобы при компиляции каждый раз не указывать?

Сообщение отредактировано: neokoder - 03.12.11, 15:12

Цитата neokoder @ 03.12.11, 15:10

Он что инклуды не видит что ли?

не может быть такого. при сборке компилятора оп "запоминает" пути к хидерам/либам относительно бинарников. впервые с таким встречаюсь..

Добавлено 03.12.11, 15:19
архив битым тоже быть не может.

Сообщение отредактировано: niXman - 03.12.11, 15:19

Цитата niXman @ 03.12.11, 14:59

neokoder, мне тут подсказывают, что нельзя ставить в корень дисков. а лучше всего в каталог документов пользователя. (сам не проверял)

Ну поставил в Documents - такая же фигня. Как его настроить то чтобы он инклуды видел? Или хоть как справку по командам получиить чтобы явно указать путь к инклудам при компиляции? Чего только не пробовал /h /help /? -h -help -? ничё не показывает!

Где хоть файл настроек хранится чтобы пути можно было посмотреть?

Сообщение отредактировано: neokoder - 03.12.11, 15:21

Цитата neokoder @ 03.12.11, 15:19

/h /help /? -h -help -?

это же не unix way!
>g++ --help

Добавлено 03.12.11, 15:21
вообще, тебе нужен ключик "-I<path>"

Добавлено 03.12.11, 15:22
у тебя либо какая-то защита вендус не дает компилятору работать, либо антивирус..

А чёрт его знает, с меня самого семь потов сошло пока до ума довёл всё это дело, но мне было легче, я пакеты скачивал и в DEV-С++ пихал, а она уже сама распихивала по директориям и пути прописывала какие надо. Моя задача была чтобы все пакеты друг другу соответвовали, чтобы были более или менее новыми, чтобы были необходимые, чтобы лишних не было, чтобы... А теперь говорят, что я поставил не то!
nixman знает, кому же ещё знать как не ему.

Сообщение отредактировано: повстанец - 03.12.11, 15:28

Цитата повстанец @ 03.12.11, 15:26

чтобы были более или менее новыми

ты же тестовый раритет юзаешь, батенька!

Два вопроса, как ты определил, что тестовый и почему раритет? Апрель 2010 года

Цитата повстанец @ 03.12.11, 15:31

как ты определил, что тестовый

-

Цитата

(experimental)

это тестовые сборки нестабильных версий. тоже, что и у меня в сборках версии 4.7.0.

Цитата повстанец @ 03.12.11, 15:31

и почему раритет?

потому что с тех пор вышла куча новых версий.

да блин виноват, чё же делать?

Добавлено 03.12.11, 15:41

Цитата niXman @ 03.12.11, 15:34

потому что с тех пор вышла куча новых версий.

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

Цитата повстанец @ 03.12.11, 15:37

чё же делать?

в третий(или четвертый?) раз указать на мою подпись?

Да ёлки-палки, а чё такое релиз, а чё такое пререлиз, а чё такое снэпшот? Надо ставить так уж наверное, я поставил уже однажды оказалось тестовой версией.

Цитата повстанец @ 03.12.11, 15:46

чё такое релиз, а чё такое пререлиз, а чё такое снэпшот?

ну гм... это фундаментальные понятия.

Цитата повстанец @ 03.12.11, 15:46

я поставил уже однажды оказалось тестовой версией

значит либо ты не читал примечания к выпуску, либо тебя обманули.

Не набивай себе цену, а? Скажи уж, что ли, просто и ясно.

Разобрался, MinGW конфликтовал с Cygwin. Убрал пути Cygwin'а из PATH, вроде все заработало нормально.

Ну в общем ладно, ловит SEH GCC из сборки MinGW с помощью SetUnhandledExceptionFilter и то хоть хорошо. Только вот стек не будет раскручиваться, потому что поймать SEH-исключение в MinGW(G++) ни с помощью __except, ни с помощью catch невозможно!

Сообщение отредактировано: neokoder - 03.12.11, 15:58

Цитата повстанец @ 03.12.11, 15:46

чё такое релиз

это стабильная версия, прошедшая необходимые тесты.

Цитата повстанец @ 03.12.11, 15:46

чё такое пререлиз

то же что и выше, но в данный момент проходящая тестирование. т.е. еще не сошедшая с "конвейера".

Цитата повстанец @ 03.12.11, 15:46

чё такое снэпшот

разрабатываемая в данный момент версия. т.е. заготовка. нифига не стабильная.

Ну вот, другой коленкор, спасибо, А я правильно понял что выпуски, отличающиеся только расширениями, просто сархивированы по-разному? Я себе обязательно поставлю, только не щас и буду их "дружить" с DEV-С++... Так ты говоришь, о путях можно не беспокоиться, все привязаны к "bin"? Хотя я и не начинал ещё ставить, должно получиться

Цитата повстанец @ 03.12.11, 16:09

выпуски, отличающиеся только расширениями, просто сархивированы по-разному?

да. просто есть пользователи которые не умеют устанавливать 7-zip. по этому качают zip`ы, ибо встроенная поддержка.

Цитата повстанец @ 03.12.11, 16:09

ты говоришь, о путях можно не беспокоиться, все привязаны к "bin"?

ага.

niXman, я так понял ты используешь mingw-w64.
А там у них вроде и есть сборки и для 64-битных систем. А ты почему только mingw32 собираешь?
И вообще я сейчас качаю с их sourceforge mingw-w32-bin_i686-mingw_20111202.zip чем он он твоего отличается то?

Ну то есть я не понял зачем ты чего там собираешь если есть уже готовые сборки mingw-w32 и mingw-w64?

Сообщение отредактировано: neokoder - 03.12.11, 16:21

Цитата neokoder @ 03.12.11, 16:18

ты почему только mingw32 собираешь?

этим вопросом я занимаюсь вот уже несколько дней. будут и 64ех битные.

Цитата neokoder @ 03.12.11, 16:18

чем он он твоего отличается то?

хз.. судя по дате, это снэпшот.

Добавлено 03.12.11, 16:23

Цитата neokoder @ 03.12.11, 16:18

есть уже готовые сборки

а почему ты те сборки считаешь готовыми? а не на оборот

Цитата niXman @ 03.12.11, 16:21

а почему ты те сборки считаешь готовыми? а не на оборот

Да потому что бинарники уже есть и собирать ничего не нужно. Смысл твоих сборок? Можешь четко ответить, по-нормальному, без тролинга.

Цитата neokoder @ 03.12.11, 16:28

потому что бинарники уже есть и собирать ничего не нужно

ну дык. тебе разве что-то нужно собирать? бинарники ведь уже есть и собирать ничего не нужно.

Цитата neokoder @ 03.12.11, 16:28

Можешь четко ответить

ну епс...
у проекта mingw-w64 нет цели в сборках MinGW как таковой. и сам проект имеет несколько другую цель. те бинари что ты видишь, являются побочным продуктом деятельности их проекта, ибо они их собирают для теста своего продукта.

я же собираю по максимуму, со всеми плюшками и расширениями, такими как OpenMP, LTO, Graphite, std_atomics, std_threads, e.t.c...

тут еще можешь почитать.

Сообщение отредактировано: niXman - 03.12.11, 16:48

Понятно.

Цитата niXman @ 03.12.11, 14:59

но что-то подобных тем в сторону gcc/edg/comeau найдено не было.

Та на. За одно только описанное в стартовом посте поведение стоит выкинуть gcc и не вспоминать о нём больше. А там ещё есть 38-й пост, который ну просто без комментариев - никогда, ни до, ни после, мне не хотелось авторам компиляторов физиономии разукрашивать. Поищи-ка нечто подобное в адрес MS.
Что касается EDG, то с ребятами оттуда, в частности Вильямом Миллером, я даже переписывался на предмет одного тонкого момента в Стандарте, где меня убедили, что Comeau, несмотря ни на что, Стандарт не нарушает. Стандарт сам по себе штука не тривиальная, читать его правильно надо ещё уметь. К примеру, вот:

Цитата 5 Expressions

4. If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. [ Note: most existing implementations of C++ ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. —end note ]

Где со стороны MS нарушение Стандарта касательно, скажем, деления на нуль?

Цитата 4.1 Lvalue-to-rvalue conversion

1. ...If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior...

Где со стороны MS нарушение Стандарта касательно разыменования невалидных указателей?

Цитата 2.11 Identifiers

3. In addition, some identifiers are reserved for use by C++ implementations and standard libraries (17.6.4.3.2) and shall not be used otherwise; no diagnostic is required.

Цитата 17.6.4.3.2 Global names

1 Certain sets of names and function signatures are always reserved to the implementation:

• Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
• Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

Где со стороны MS нарушение Стандарта касательно идентификаторов __try/__except/__finally/__leave?

Цитата niXman @ 03.12.11, 14:59

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

Ичё? А что такое "порт" по-твоему? Рекомпиляция и сборка, лишь бы було? Дык это и я смогу, не думаю, что понадобится много времени. Уж точно не 20 лет. Впрочем, кому я это рассказываю, ты сам вон сборки выкладываешь. Я тебя разочарую. Порт на то и порт, что он должен учитывать специфику платформы. Иначе это не порт, а просто частная сборка.

Сообщение отредактировано: Qraizer - 04.12.11, 04:43

Цитата Qraizer @ 04.12.11, 04:34

Та на.

незачет
все дело в том, что если компиляция закончилась без ошибки, то варнинги не выводятся пользователю. это баг LWS, естественно, а не компилятора
вот: http://liveworkspace.org/code/b1fa6b2bcc5c6103db50b5a40a508016
намеренно провоцируем ошибку чтоб не подавились варнинги.

Добавлено 04.12.11, 04:39
как видишь, варнингов там предостаточно, аж целых три!)

Сообщение отредактировано: niXman - 04.12.11, 04:39

Цитата niXman @ 04.12.11, 04:38

все дело в том, что если компиляция закончилась без ошибки, то варнинги не выводятся пользователю

Потрясающе! В рамочку и на стеночку!

Цитата Qraizer @ 04.12.11, 04:34

ещё есть 38-й пост

тоже незачет: http://liveworkspace.org/code/34a50fc5e8f56014a942b6034cce2dd3

Добавлено 04.12.11, 04:43

Цитата Qraizer @ 04.12.11, 04:42

Потрясающе! В рамочку и на стеночку!

ну сорри... есть сложность с диагностикой статуса завершения компиляции..

В общем, gcc фтопку. Как обычно с ОпенСоурс, авторов пруд пруди, но крайних нет, так что никто не виноват в том что, оно вот как-то вот так...

зы
что-то быстро тебя отпустило после вчерашнего)


Добавлено 04.12.11, 04:45

Цитата Qraizer @ 04.12.11, 04:44

gcc фтопку

так компромата-то нет. за что?

Цитата niXman @ 04.12.11, 04:42

тоже незачет: http://liveworkspace.org/code/34a50fc5e8f5...942b6034cce2dd3

Ну знаешь ли... Попробуй это скормить EDG. Или там comeau.

провоцируем ошибку, и voila! http://liveworkspace.org/code/c3b06f4d3eb22fef1cfd2e0576bd5488

Попробовал:

Comeau C/C++ 4.3.10.1 (Oct  6 2008 11:28:09) for ONLINE_EVALUATION_BETA2
Copyright 1988-2008 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C90
 
"ComeauTest.c", line 5: error: argument of type "char *" is incompatible with
          parameter of type "char"
        (void)build_name_object("T", "I", "M", i+1);
                                ^
 
"ComeauTest.c", line 5: error: argument of type "char *" is incompatible with
          parameter of type "char"
        (void)build_name_object("T", "I", "M", i+1);
                                     ^
 
"ComeauTest.c", line 5: error: argument of type "char *" is incompatible with
          parameter of type "char"
        (void)build_name_object("T", "I", "M", i+1);
                                          ^
 
3 errors detected in the compilation of "ComeauTest.c".
 
In non-strict mode, with -tused, Compile failed
Hit the Back Button to review your code and compile options.
Compiled with C++0x extensions enabled.

Компилилось в режиме C89 relaxed.
Компромата достаточно. Прежде чем обвинять других в их мелких несоответствиях, стоило бы сначала свои крупные пофиксать.

ну... один

Провоцировать ошибки компиляции - оно-то, конечно, метод. Только что ж это получается, если у меня не будет ни одного эррора, но 100500 варнингов, я ничего не увижу?

так это мой недочет. я об этом не забыл, ибо иногда встречаю обсуждения LWS подобные тому что ты привел. исправлю. обещаю.

Добавлено 04.12.11, 04:56
на днях исправлю.

Тьфу ты. niXman, компромат - не тема этой темы. Вон той - может быть. Тема этой темы - порт gcc под WinAPI, по крайнем мере Win32. Если мы конечно о порте, а не ресборке. Дык вот пока плучается, что порта-то и нет. А это тоже грустно. И мало того, авторам "порта" даже не упиралось его делать портом без кавычек. От этого уже не просто грусно.

Сообщение отредактировано: Qraizer - 04.12.11, 04:59

Qraizer, какой смысл ты вкладываешь в слово "порт" ? наличие SEH? чего-то еще?

К слову. Я прекрасно себе представляю объём работы в человеко-часах над реализацией поддержки SEH в компиляторе. Я хорошо себе представлю, что и как должен для этого делать компилятор, и что должна на себя взять RTL. Одно время лазал SoftIce-ом по ядрам Win9x и WinXP, чтобы увидеть, как они там с исключениями справляются. Именно поэтому не питаю иллюзий в плане возможности их реализовать самому. У меня столько свободного времени просто не будет, по крайней мере пока не уйду на пенсию. Но с другой стороны, если есть троица, которая этот "порт" ведёт, значит у неё есть для этого возможности. Так в чём дело тогда?

Цитата Qraizer @ 04.12.11, 05:06

Так в чём дело тогда?

дело в том что не видят необходимости. ты наверное мне не веришь, но я только в той теме узнал что такое SEH и для чего оно надо) хотя не первых год код пишу. правда для linux.

Добавлено 04.12.11, 05:09

Цитата niXman @ 04.12.11, 05:08

только в той теме узнал что такое SEH и для чего оно надо

сам термин я знал давно. но что конкретно это такое, только несколько дней назад узнал.

Сообщение отредактировано: niXman - 04.12.11, 05:09

Дык говорилось уже. Поддержка ключевых аспектов платформенной архитектуры. Как бы ты отнёсся в порту Intel C++ Compiler под Linux, если б он не поддерживал ключевые GNUсные расширения? А ведь поддерживает.

Цитата Qraizer @ 04.12.11, 05:09

Поддержка ключевых аспектов платформенной архитектуры.

мне сложно об этом рассуждать, ибо из таковых я пока что знаю что не поддерживается SEH.

Цитата Qraizer @ 04.12.11, 05:09

Как бы ты отнёсся в порту Intel C++ Compiler под Linux, если б он не поддерживал ключевые GNUсные расширения?

а там нет таковых. компилятор ничего не реализует помимо того что написал юзер. если ты не имеешь ввиду языковые расширения GCC, коих огромное множество.

Qraizer будет доволен
http://liveworkspace.org/code/c7c289facf28fd90444f410e9b8acc55
http://liveworkspace.org/code/9e47c13c75f2a960d1077fd84c8ffcc3

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

Цитата niXman @ 03.12.11, 16:35

я же собираю по максимуму, со всеми плюшками и расширениями, такими как OpenMP, LTO, Graphite, std_atomics, std_threads, e.t.c...

niXman, а как ты объяснишь тот факт, что твоя сборка в распакованном виде занимает на диске 215Мб, а mingw-w64(32-разрядная версия) 1Гиг. Что-то это не укладывается в то что ты дополнительные компоненты включаешь. Получается в их сборке доп. компонентов гораздо больше?

Цитата neokoder @ 04.12.11, 14:08

mingw-w64(32-разрядная версия) 1Гиг

"так им и надо"(с)

Добавлено 04.12.11, 14:11
но, честно говоря, я этого не знал)))
страшно представить чего они в архивы пихают %)

Добавлено 04.12.11, 14:21
а я то думал как бы еще объем компилятора уменьшить

niXman, я поставил компилятор твоей сборки, бесполезно:
Вот этот код:

      #include <windows.h>
      #include <stdio.h>
      
      
      
      int z,p=1,d=0;
      
      LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS except_info)
      {
        printf ("Поймали исключение. Код %X\n", (unsigned int)except_info->ExceptionRecord->ExceptionCode);
        return EXCEPTION_EXECUTE_HANDLER;
      
      }
      
      
      int main()
      {
      
        SetConsoleCP (1251);
        SetConsoleOutputCP (1251);
      
      
        SetUnhandledExceptionFilter(TopLevelUnhandledExceptionFilter);
      
        try
        {
           //SEH, деление на ноль
           z=p/d;
        }
        catch(...)
        {
           printf("Попали в catch\n");
        }
      
      
        //исключение bad:alloc (С++ исключение)
          //__int64 *pI = new __int64[0xFFFFFFF];
      
        printf("Программа завершила свою работу. Нажмите любую клавишу...\n");
        getchar();
        return 0;
      }

Выдавал на-гора:

E:\vso_moio\Программирование_на_C++\Новая папка (5)>ra_8.exe
Поймали исключение. Код C0000094
 
E:\vso_moio\Программирование_на_C++\Новая папка (5)>

Я написал об этом раньше, вот тут, далее ты сказал мне чтобы я выдал версию компилятора, я выдал (4.5.0, да ещё и экспериментальная) ты сказал, что у меня раритет и вообще смотрел к тебе в подпись.
Я посмотрел, скачал 4.6.1 Короче вывод тот же самый, а по команде g++ -v:

E:\vso_moio\Программирование_на_C++\Новая папка (5)>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=e:/dev-cpp_nomingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.1/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6.1/configure --prefix=/mingw --host=i686-pc-mingw32 --build=i686-pc-mingw32 --target=i686-pc-mingw32 --enable-languages=c,c++ --with-
tune=generic --with-host-libstdcxx=-lstdc++ --disable-shared --enable-static --enable-lto --enable-cloog-backend=isl --enable-checking=release --enable-libgomp
--enable-fully-dynamic-string --disable-libstdcxx-debug --enable-threads=posix --enable-cxx-flags='-fno-function-sections -fno-data-sections' --disable-bootstra
p --disable-libstdcxx-pch --enable-sjlj-exceptions --disable-win32-registry --disable-nls --disable-werror --with-gmp=/libs --with-mpfr=/libs --with-mpc=/libs -
-with-ppl=/libs --with-cloog=/libs --with-libiconv-prefix=/libs --with-pkgversion='niXman build' --with-bugurl=http://code.google.com/p/mingw-builds/issues/list
 
Thread model: posix
gcc version 4.6.1 (niXman build)

Чё делать? Однажды я уже спросил тебя, ты указал мне на свою подпись. Не помогло, как видишь.

Сообщение отредактировано: повстанец - 10.12.11, 08:28

Цитата повстанец @ 10.12.11, 08:26

бесполезно

а в чем должна была быть польза?

Цитата повстанец @ 10.12.11, 08:26

Поймали исключение. Код C0000094

ну вот, системное исключение поймал. что не так?

Цитата повстанец @ 10.12.11, 08:26

вот тут, далее ты сказал мне чтобы я выдал версию компилятора

да. но не понимаю, что в работе кода тебя не устраивает?

Добавлено 10.12.11, 08:31
да и сменить версию компилятора я предлагал потому, что ты использовал древнюю тестовую сборку. не более.

Сообщение отредактировано: niXman - 10.12.11, 08:35

Цитата niXman @ 10.12.11, 08:30

ну вот, системное исключение поймал. что не так?

Я правильно тебя понял, что вывод в сообщении номер 77 был правилен?

такой же. ты это к чему?

Я спросил он был правилен иле нет? То, что он такой же, я вижу.
Тогда я такого вопроса не ставил, ибо сам не знал, а раз ты спрсил уменя про версию компилятора, то всяко-разно неспроста, наверное чё-то не так у меня было с выводом. Так я подумал.

А спросил я к тому, что на фига ты мне советовал свой компилятор, если я подвижек не вижу?

Но опять же это я отвечаю на твой вопрос (наверное, преждевременно), а ты на мой не отвечаешь. Ещё раз: вывод сообщениия номер 77 был правилен или ты просто толкаешь свои компиляторы налево и направо ползуясь неопытностью людей- моей, в частности?

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

Qraizer, во-первых, я к этому ещё не возвращался. Надо быть последовательным. Щас я разбираюсь с компилятором.
Во-вторых, долго ещё niXman будет меня оскорблять?
Требую забанить его по нику навсегда

Сообщение отредактировано: повстанец - 10.12.11, 12:15

Причину неработоспособности твоего кода я тоже уже озвучивал. Без уверенности, правда, но другого объяснения пока нет, и не только у меня. Если я прав, то твой код и должен так работать, как ты наблюдаешь. Тебе не удастся подружить gcc с SEH иначе, как с помощью того же WinAPI. Ловишь им необработанное SEH-исключение и транслируешь в C++EH-исключение, которое gcc обрабатывать умеет. Мой код не более чем тестовый. Его ещё допиливать надо будет, чтоб по уму. Но это дело техники, главное, чтоб заработало.

Сообщение отредактировано: Qraizer - 10.12.11, 14:31

!

Давайте не опускаться до хамства и личных оскорблений. У нас здесь не балаган, а культурный тематический раздел. И давайте вести себя подобающе, и уважать мнения других.