Исправление Iron_Bug, (текущая версия) :
отвечу на некоторые вопросы
1. malloc обрабатывать обязательно. каждый. в идеале перед выходом лучше закрыть все системные дескрипторы и прочие ресурсы, которые софтина может использовать.
2. велосипеды со строками изобретать не нужно, лучше юзать стандартные библиотеки. тем более если тебе нужны всякие китайские иероглифы (хотя я не видела не-китайцев, которые бы использовали 4-байтный юникод). интернационализацию вообще надо продумывать сразу, потом её впиливать очень тяжело. но вообще проще работать с фиксированной длиной символа, чем с мультибайтом. мультибайт требует много накладных расходов на перевод строк туда-сюда для работы с текстом.
3. как тебе больше нравится. если есть проблемы конкретно с выделением памяти (например, программа выделяет очень большой объём памяти или в процессе работы возникает сильная фрагментация) - можно писать свои. в простых случаях можно не заморачиваться и юзать любые готовые.
4. в маздае не знаю. в лине любой админ тебе скажет, что в syslog. но если это юзерская софтина, можно и в консоль.
5. зачем такие сложности? я не понимаю, что ты таким образом хочешь сэкономить.
6. лучше всегда по указателю. но если структура будет удалена после передачи в функцию или может быть изменена, пока функция не завершилась - тогда, естественно, по значению. зависит от того, как собираешься её использовать.
7. одинаково. но в 64 бита можно упихать 2 по 32. хотя это не создаст тебе измеримого на практике ускорения в 99.99% случаев.
8. зависит от знаковости и от конкретной ситуации. "!=" не есть конкретно больше или меньше.
9. всегда. ну, в пределах одной машины.
12. зависит от количества. если будет существенный выигрыш в экономии памяти - то нужно делать хранение дубликатов в виде ссылок на общие данные. но если данные часто изменяются - может получиться геморрой.
13. если мало - map, если много - хэш. вид хэширования зависит от того, насколько часто приходится добавлять элементы (некоторые хэши шустрее, но не равномерно распределены и могут вызывать коллизии).
14. в дебаге - да. на практике, теоретически, можно (через дебаг). но в общем случае сложно. в частных вариантах можно попробовать через самописные аллокаторы.
15. фрагментация кучи может быть актуальна, если данных много или выделяются большие непрерывные куски памяти.
16. многопоточность - системная функция. вряд ли есть что-то быстрее обычных системных API. к тому же, они примитивны и не вызывают проблем.
17. если твой ini-файл меньше гигабайта, проецировать нет смысла :) читать пофигу как. опять же, если он невелик.
18. для простых регекспов в юниксах есть позиксовский регексп в libc. ограниченный по возможностям, но довольно шустрый. емнип, в маздае его нет. хотя не поручусь. внешние библиотеки для работы с регекспами зависят от степени навороченности функционала. обычно чем более полная поддержка фич - тем медленнее работает.
19. зависит от твоих целей. но -Wall всяко полезен.
Исходная версия Iron_Bug, :
отвечу на некоторые вопросы
1. malloc обрабатывать обязательно. каждый. в идеале перед выходом лучше закрыть все системные дескрипторы и прочие ресурсы, которые софтина может использовать.
2. велосипеды со строками изобретать не нужно, лучше юзать стандартные библиотеки. тем более если тебе нужны всякие китайские иероглифы (хотя я не видела не-китайцев, которые бы использовали 4-байтный юникод). интернационализацию вообще надо продумывать сразу, потом её впиливать очень тяжело. но вообще проще работать с фиксированной длиной символа, чем с мультибайтом. мультибайт требует много накладных расходов на перевод строк туда-сюда для работы с текстом.
3. как тебе больше нравится. если есть проблемы конкретно с выделением памяти (например, программа выделяет очень большой объём памяти или в процессе работы возникает сильная фрагментация) - можно писать свои. в простых случаях можно не заморачиваться и юзать любые готовые.
4. в маздае не знаю. в лине любой админ тебе скажет, что в syslog. но если это юзерская софтина, можно и в консоль.
5. зачем такие сложности? я не понимаю, что ты таким образом хочешь сэкономить.
6. лучше всегда по указателю. но если структура будет удалена после передачи в функцию или может быть изменена, пока функция не завершилась - тогда, естественно, по значению. зависит от того, как собираешься её использовать.
7. одинаково. но в 64 бита можно упихать 2 по 32. хотя это не создаст тебе измеримого на практике ускорения в 99.99% случаев.
8. зависит от знаковости и от конкретной ситуации. "!=" не есть конкретно больше или меньше.
9. всегда. ну, в пределах одной машины.
12. зависит от количества. если будет существенный выигрыш в экономии памяти - то нужно делать хранение дубликатов в виде ссылок на общие данные. но если данные часто изменяются - может получиться геморрой.
13. если мало - map, если много - хэш. вид хэширования зависит от того, насколько часто приходится добавлять элементы (некоторые хэши шустрее, но не равномерно распределены и могут вызывать коллизии).
14. в дебаге - да. на практике, теоретически, можно (через дебаг). но dв общем случае сложно. в частных вариантах можно попробовать через самописные аллокаторы.
15. фрагментация кучи может быть актуальна, если данных много или выделяются большие непрерывные куски памяти.
16. многопоточность - системная функция. вряд ли есть что-то быстрее обычных системных API. к тому же, они примитивны и не вызывают проблем.
17. если твой ini-файл меньше гигабайта, проецировать нет смысла :) читать пофигу как. опять же, если он невелик.
18. для простых регекспов в юниксах есть позиксовский регексп в libc. ограниченный по возможностям, но довольно шустрый. емнип, в маздае его нет. хотя не поручусь. внешние библиотеки для работы с регекспами зависят от степени навороченности функционала. обычно чем более полная поддержка фич - тем медленнее работает.
19. зависит от твоих целей. но -Wall всяко полезен.