Мне приходилось только несколько раз вводить код в C, и, похоже, каждый раз, когда я это делаю, это становится неуправляемым зверем.
Я проделал большую часть своих программ на C # и .Net, поэтому я очень привык к архитектуре стиля classа, но я не могу понять организацию в приложениях C. Должен ли я помещать функции, связанные в определенный файл, задавать определения функций в одном файле и обрабатывать в другом и т. Д. Есть ли там какие-то хорошие ресурсы по этому вопросу?
См. Также: Борьба с C из объектно-ориентированной земли?
Вот аналогия, которая может вам помочь:
Класс – это некоторая структура данных и набор функций для доступа к этим данным и управления ими. Язык c не предоставляет никакого синтаксического сахара для организации этих отношений для вас, но вы все равно можете создать свой код вокруг этой идеи. Итак, просто сделайте это: спроектируйте проект вокруг кучи «classов».
Организация кода обычно принимает одну из двух форм:
.h и один файл реализации с расширением .c Итак, вы уже знаете, как это сделать …
C Интерфейсы и реализации Дэвида Хэнсона объясняют красивую схему удобной организации в первой главе (если я правильно помню) и показывают ее использование в остальных, которые разрабатывают существенные библиотеки.
старое « структурированное программирование » способа кодирования программ C состоит в их модуляции в файлы. Вместо того, чтобы иметь код в объектах, убедитесь, что вы поместили весь связанный код в отдельные файлы.
Если вы думаете о файле как об объекте бедного человека, вы будете в основном участвовать в организации своих C-приложений, подобных вашим C #.
Поскольку у вас есть опыт работы на C #, вас могут заинтересовать ответы на мой вопрос SO: « Object-Orientation in C ». Если вас это интересует, может быть полезно взглянуть на ответы на соответствующий вопрос: « Можете ли вы написать объектно-ориентированный код в c? ». Если вы планируете использовать схему, подобную любой из упомянутых в ответах на вышеупомянутые вопросы, пожалуйста, имейте в виду, что самое главное – это ваш дизайн, а не синтаксический сахар, который может / не может выглядеть так красиво.