История изменений

отвечу на некоторые вопросы

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 всяко полезен.

отвечу на некоторые вопросы

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 всяко полезен.