Доброго времени суток...

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

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

В общем пытаюсь найти золотую середину, но пока не могу...

Заранее спасибо...

Это сообщение отредактировал(а) kosmonaFFFt - 19.6.2012, 18:48

Ну во есть такая фигня как регистр флагов, через него можно возвращать ненавязчиво состояние функ

а мне понравилось как в WinAPI (тфу-тьфу-тьфу, сгинь) - делать ф-цию типа GetLastError:


Это сообщение отредактировал(а) borisbn - 19.6.2012, 20:49

Можно организовать нечто очень похожее на исключения.
смотрите стандартные функции: setjmp (), longjmp (), и т.д.

А как у этого метода с потокобезопасностью? Если например две функции, вызванные параллельно выдадут ошибку одновременно?



Ага, даже нашел несколько библиотек, реализующих "исключения", например http://sourceforge.net/projects/libexcept/, но есть сомнения, не вызовет ли это еще больше багов, как будут обрабатываться непойманные "исключения" и т. д. Если знаете какие-нибудь надежные существующие решения под некопилефт лицензиями (Apache, MIT, BSD, WTFPL, и т. д.), был бы рад про них узнать...

UPD.
Так же интересуют способы получения стектрейсов в случае ошибки...

Это сообщение отредактировал(а) kosmonaFFFt - 20.6.2012, 07:49

Никак. Этого не было в задании )))
Я, вообще-то, думал, что ты переходишь на Си, потому, что нужно писать на какой-нить контроллер, а там, обычно, у процессора одно ядро и несколько потоков только замедлят работу.


http://www.codeproject.com/Articles/11132/...g-the-callstack
замечательная штука, но Windows/Linux only. Там, правда, на Си++, но это только обёртка. Её можно "снять" и получишь на Си

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

Добавлено через 2 минуты и 21 секунду

Похоже вообще только Windows-only

Если только для Windows - OuputDebugString() + утилита DebugView для просмотра (скачивается с сайта microsoft.com)

Спасибо, но интересуют только кроссплатформенные решения...

упс... пардон. у меня, просто,  водном каталоге лежал StackWalker и ещё одна приблуда (call_stack_gcc.cpp и call_stack_msvc.cpp)
Прикрепляю архив

Присоединённый файл ( Кол-во скачиваний: 5 )
 stacker.zip 3,45 Kb

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

В библиотеке делаете указатель на функцию, которая быдет вызываться библиотекой в случае ошибки. По умолчанию там стоит заглушка (пустая функция). Указатель может инициализировать пользователь библиотеки своей функцией (а уж в ней делать что хочет - ругаться в консоль, убивать программу или делать аналог exception'ов через setjmp/longjmp)

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

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

Для этого есть thread-local переменные. Они есть на всех платформах, но синтаксис их увы отличается.

Ок, погуглю на эту тему...

А почему нельзя написать внутренности библиотеки на C++, а экспорты сделать на C с возвратом кодов ошибок?

Тогда неудобно получается работать с функциями, которые должны что-то возвращать... Внутренности конечно можно на С++ написать, но опять же, даже исключениями нормально не воспользуешься...

Я пока склоняюсь к мысли протаскивать в каждую функцию последним аргументом указатель на структуру, в которую класть код ошибки и информацию о файле/строке, где ошибка произошла (и если хочется ошибку игнорировать, просто передавать NULL)...

Да вроде как вполне удобно. Многие функции в винапе такие. По указателю передавать переменную, в которую будет писать результаты своей деятельности.
А насчет исключений можно по-подробнее? Мы же их кидать в приложение не будем.

Это сообщение отредактировал(а) Randajad - 25.6.2012, 12:06

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

Смысл - для удобства разработки библиотеки. 
Али религия не позволяет писать на С++? 
С слишком аскетичен.

Это сообщение отредактировал(а) Randajad - 25.6.2012, 12:07

Для моих целей вполне хватает и C, а все плюшки C++ типа ООП, исключений и шаблонов вместе с STL разбиваются об необходимость иметь интерфейс на C.

Randajad, Ну вот допустим, библиотека написана на C++ с C-интерфейсом. Пользовательская программа - тоже на C++.
1. Библиотека и пользовательская программа компилируется одним и тем же компилятором - Ок, но зачем тогда C-интерфейс?
2. Библиотека и пользовательская программа компилируются разными компиляторами, для каждой нужна своя runtime-библиотека, могут быть проблемы.
Я как-то пытался состыковать программу, наприсанную на C++ Builder 6.0 с dll, написанной на C++ Builder 5.0 - проще оказалось перекомпилировать библиотеку на C++ Builder 6.0 чем заставить нормально работать вместе разные версии компилятора.

Значит, религия.
Как ни крути, а количество кода, при написании на С резко увеличивается. Даже буста нету.
То, что экспортируемый интерфейс на С - не причина отказываться от многих возможностей языка. Тем более, 11 стандарт как никак.

Добавлено @ 12:54
Библиотека динамическая? Линкуем статически CRT.

Добавлено @ 12:56
С интерфейс нужен для каких-либо плагинов. Если же и библиотека и приложение разрабатываются одним автором, причем библиотека планирует использоваться только в этом приложении - зачем она тогда вообще нужна? Если же он ее позиционирует еще как отдельный продукт- это уже его дело, делать ей С интерфейс, или нет.

Добавлено @ 12:59
Вообще, я крайне не люблю тех, кто линкует CRT динамически. Особенно это касается студии. Из-за того, что люди не хотят, чтобы их экзешка распухла на 30 килобайт, юзверям приходится устанавливать метры всяких MSVC Redist...

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

Это сообщение отредактировал(а) Randajad - 25.6.2012, 13:07

Пользовательская программа будет с большой степенью вероятности на чем-то высокоуровневом, типа python+pyqt или .NET, соответственно C-интерфейс нужен для возможности создания биндингов в высокоуровневый язык...


Обычно нормальные авторы тогда делают нормальные инсталляторы, которые сами ставят редист...