Иди по стопам Страуструпа и делай свой препроцессор для С, который разворачивает try / catch / finallly. Макросы С для этой цели не годятся совсем; Мне влом дублировать сюда все афоризмы Герба Саттера и Ко по поводу макросов. В библиотеке Qt есть например препроцессор который привязывает напрямую оконные сообщения к вызовам функций. Я мельком смотрел исходный код DOOM 3 - там с помощью ихнего отдельного препроцессора обходится другое слабое место С++ - отсутствие быстрых делегатов.sergey_kovtunenko писал(а):Речь шла о компиляторах для AVR, PIC, 8051... Я не знаю нормальных С++ компиляторов для них.
Это хорошо.sergey_kovtunenko писал(а): То программер, который использует библиотеку получает обычные функции с обычными кодами возврата.
GDI Тоже непереносимо.sergey_kovtunenko писал(а): __finally есть только в винде и такой код непереносим на другие платформы.
Речь не о том кто должен освобождать память. Речь идет о том что память освобождается с помошью free() только в тех модулях *.c, которые ее выделили. Другие модули должны использовать destroy_other_module_entity(..). Исключения возможны только в виде функций типа _dup(), возвращаемое значение которых надо освобождать с помощью free(...)sergey_kovtunenko писал(а): Не всегда это возможно, освобождать память там, где выделялась. Это ведь одна из ключевых проблем языков вроде С++: Кто будет выделять память, а кто будет её освобождать?
Проблемы были решены загрузкой всех сторонних компонент в рамки другого процесса и использованием RPC. Когда память выделенная под другой процесс превышала конфигурируемое значение, процесс грохался и загружался по новой. Но это неправильно.sergey_kovtunenko писал(а): Да, но полностью самому написать систему 24\7 практически сейчас нереально, приходится использовать сторонние компоненты. А кто даёт гарантию, что там проверялись все коды ошибок, возвращаеммые функциями?