Сергей Борщ 141 19 апреля, 2014 Опубликовано 19 апреля, 2014 · Жалоба А хидер global.h подключается дополнительно. Ведь и без того одним хидер-файлом не обойдешься.Зачем, ну объясните мне, зачем делать эту общую свалку global.h? Только ради того, чтобы в каждом исходнике писать одну строчку #include "global.h" вместо нескольких, по которым будет совершенно однозначно видно, какие именно другие модули использует этот? И какие файлы надо захватить вместе с этим при копировании этого модуля в другой проект? И что-то я не понял насчет "подключается дополнительно". Если уже подключен заголовочный файл модуля А.h, то включены все необходимые объявления модуля A. Что тогда будет в global.h? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 19 апреля, 2014 Опубликовано 19 апреля, 2014 (изменено) · Жалоба Такой подход имеет право на существование, однако у него все же есть два недостатка: - Пространство имен функций все-таки засоряется. Не получится иметь 100500 функций init(); - На вызов функции и возврат из нее тратится время и память кода. Напрямую с переменной работать эффективнее. Со временем устаканилось две вещи (как ответ на "два недостатка"): 1. Там, где надо 100500 ИНИТов делать - это решается через хэндлы. Как говорят военные, безобразно, зато единообразно. struct _handle { void (*init)(void); void (*done)(void); }; 2. Там, где требуется оченно зашкаливающая эффективность, - там нет таких объемов данных и все сосредоточено в пределах одного модуля. Это все фигня, потому что С++ все-таки дает неквадратные колеса. Если человеку аж чешется ООП, то для чего этим страдать на Си? На Си даже try - catch можно делать, ну и? На GCC можно даже частично RTTI на макросах делать. Но к чему? Изменено 19 апреля, 2014 пользователем _Pasha Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 20 апреля, 2014 Опубликовано 20 апреля, 2014 · Жалоба Зачем, ну объясните мне, зачем делать эту общую свалку global.h? Чтобы пихать туда вещи, которые не принадлежат ни к одному модулю. Глобальные переменные например. В глобально доступных переменных нет сильно большого криминала до тех пор, пока к ним доступ осуществляется атомарно в многопоточных программах. И пока не страдает логика приложения, например всё приложение начинает управляться глобальными флагами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dubov 0 22 апреля, 2014 Опубликовано 22 апреля, 2014 · Жалоба Чтобы пихать туда вещи, которые не принадлежат ни к одному модулю. Глобальные переменные например. В глобально доступных переменных нет сильно большого криминала до тех пор, пока к ним доступ осуществляется атомарно в многопоточных программах. И пока не страдает логика приложения, например всё приложение начинает управляться глобальными флагами. Вот и я о том. когда всё приложение сводится к while(1) и опросу глобальных флагов if (x == 1) то это не хорошо как избежать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 22 апреля, 2014 Опубликовано 22 апреля, 2014 · Жалоба Приложение может строиться разными способами. Ваша задача подобрать такой способ, который будет удобен для вас и расширяем для потенциального роста приложения. 1. Либо это суперлуп (главный цикл) с флагами. Для небольших приложений. 2. Либо это взаимодействие конечных автоматов. Для приложений чуть побольше. 3. Традиционный многопоточный подход с обменом сообщениями между потоками. Почти любого масштаба приложений, но требует высокой квалификации программиста. 4. Всякие вариации в сторону декларативного и функционального программирования. Требует поддержки от компилятора. Это я навскидку составил список. Если упростить, то нужно делать по максимуму модульную программу. Там где это возможно, глобальные флаги заменять на вызов функции соответствующего модуля (например uart_is_data_ready()). Для передачи массива данных делать копию для обработки в подходящем модуле. Граф зависимостей модулей не должен (не желательно) иметь циклы. Если модуль A зависит от модуля Б, а модуль Б от модуля А, то цикл нужно разорвать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
thodnev 0 8 мая, 2014 Опубликовано 8 мая, 2014 · Жалоба Инкапсуляция является одним из подходов к ООП, а С как известно к таким языкам не относится. Тем не менее, пару раз попадался красивый код на чистом С, реализующий инкапсуляцию(поразила красивая работа со структурами). В Вашем конкретном случае с буффером, можно например передавать в функцию указатель на другую функцию, которая и будет вызываться. А вообще, лучше использовать С++ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться