Средства и методы разработки

Сершилось! По дороге на работу меня настигло очередное озарение в части C++. Спасибо =AlexD= -> http://caxapa.ru/265019.html
Вот есть RTSOка. Которая состоит из ядра и сервисов – семафоры всякие там и прочее. Пусть она изначально на С. Все, кто пользуется ею, используют: * Специфические типы данных * Глобальные переменные и константы * Управление памятью * Вызовы функций * Макросы как гарантированное средство inline кода Если мы будет сравнивать API разных Осек, то найдем там немало схожего. Например, в Win32 порождение потока выглядит так: HANDLE WINAPI CreateThread( __in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes, __in SIZE_T dwStackSize, __in LPTHREAD_START_ROUTINE lpStartAddress, __in_opt LPVOID lpParameter, __in DWORD dwCreationFlags, __out_opt LPDWORD lpThreadId );

lpThreadAttributes [in, optional] A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle can be inherited by child processes. If lpThreadAttributes is NULL, the handle cannot be inherited. The lpSecurityDescriptor member of the structure specifies a security descriptor for the new thread. If lpThreadAttributes is NULL, the thread gets a default security descriptor. The ACLs in the default security descriptor for a thread come from the primary token of the creator. dwStackSize [in] The initial size of the stack, in bytes. The system rounds this value to the nearest page. If this parameter is zero, the new thread uses the default size for the executable. For more information, see Thread Stack Size. lpStartAddress [in] A pointer to the application-defined function to be executed by the thread. This pointer represents the starting address of the thread. For more information on the thread function, see ThreadProc. lpParameter [in, optional] A pointer to a variable to be passed to the thread. dwCreationFlags [in] The flags that control the creation of the thread.

http://msdn.microsoft.com/en-us/library/ms682453(v=vs.85).aspx http://msdn.micros …brary/ms682453(v=vs.85).aspx В RTEMS все по POSIXint pthread_create( pthread_t *thread, const pthread_attr_t *attr, void (*start_routine)( void *), void *arg ); http://www.rtems.o …/posix_users00359.html Видно, что если приять в качестве универсальной модели RTEMS, то можно написать код, который трансформирует вызов API RTEMS в вызов API Win32 без влияния на процесс, работающий с RTEMS. О трудности обратного M$ позаботилась, но не суть. Т.е. если мы напишем некую совокупность классов, описывающий обобщенную Оську, а затем для каждой Оськи напишем соответствующие классы с полями и методами, и целевой код будет работать только с этой «обобщенной ОСью», то ему будет глубоко изопениссуально, под какой ОСькой он живет. Аналогично для устройств. Есть унас есть модель UART (не на уровне регистров, а на уровне логики, полей и методов), то нам плевать - мы работаем через дрова, или через виртуальную сетевую шнягу, которая материализует COM порт на другой стороне шарика. БИНГО!!! Это уже универсальная идеология синтетических портов!! Несмотря на все минусы C++, сделать на нем такое гораздо проще, чем придумать какое-то аццкое расширение Ц имени себя, гениального, и потом сдохнуть на его саппорте. Но! Исходники нужно писать ни в коем случае не в обычном редакторе! Ибо если исходники Ц еще можно распарсить тулзой умеренной сложности (и, значит, анализировать код для подсказок пишущему), то парсингом ЦПП лично я заниматься не хочу… Исходники надо писать примерно так: * Создаем базу тегов. Всех имен как текстовых строк * Создаем класс. Делаем двусторонную ссылку на тег с его именем * Создаем поля и методы. Ручками из раскрывающихся меню ставим ссылки на теги и сам класс и всякие там private, protected и пр. * Хочем написать камент – ставим ссылку на узел графа программы, и пишем текст. В самом тексте можно ставить ссылку на другие узлы для понятности. И квалификаторы каментта – надо ли его ставить в код иди просто сделать в исходниках пометку ./* comment #6r47644*/ * Автоматический визуализатор иерархии – что в ходит в класс, от чего наследовано, что породили. Красивые графы строить мгновенно! * Разрешитель ссылок – выделил тег (подогнал курсор – он сам выделился) – тут же по нему все данные ПО ВСЕМУ ПРОЕКТУ. * Анализатор зависимостей – что и от чего, по каким сущностям зависит. Очень поможет анализировать код и улучшать его * Синтезатор кода для компилятора – генерация того, что будет скормлено компилеру. Красиво и единообразно отформатированный текст заметно облегчит отладку потом * Правим только этот суперграф, компилерные исходники НЕ ПРАВИМ НИКОГДА, только синтез. * Как быть с SVN – пока не знаю, нужно делать срезы БД по тегам и связям. При современной емкости винчей можно и тупо архивировать срез базы. Отличия искать так трудно будет, но ничего, придумаем что-нибудь. Вроде технология дельта синхронизации баз проработана… * На основании этого построение автоматического генератора документации сложная, но линейная задача. Зато какая дока будет!!! * Емкости и скорости. 8G ОЗУ и SSD хотя бы на 30G со скоростью 100к+/4к транзакций сек можно считать доступными всем хоть немного продвинутым. * Пусть у нас исходники занимают 100м (п-ц какой мегапроект). В ОЗУ можно выделить 4G для in memory DB, думаю 40 кратный запас достаточен для превращения кода в базу. Там, кстати, нехилая экономия будет, по сути сжатие:– вместо тега – его ID, С операторы и ключевые слова вообще u8 закодировать можно :) * Скоростью любого процессора для этой системы будет нелишней, но там недорогие 8-ядерники от AMD на подходе… Что касается эффективности кода, то, может я тупой, но пока не вижу – а с чего бы размеру кода увеличиться? Если не использовать ЦППшные понты типа STL и вывода в стиле << >>, а настроить моск на продолжение работы в микроконтроллерном стиле, то объем кода можно и уменьшить. Связи все как на ладони – оптимизировать одно удовольствие. Проектирование сверху вниз тоже хорошо просматривается. Есть системный архитектор, который набивает БД прототипами классов с подробным описанием полей и методов. Потом платформ - мантейнеры берут эту базу и пишут код под свои платформы. Все у всех единообразно, название тегов одинаковые – уже большой +! Причем все это совсем не противоречит С мышлению, в моем понимании. Как автоматически разложить С исходник на классы и поля – не знаю, но если перевести его в «связанный список тегов», то руками трансформировать такой список в cpp не так уж и сложно. Т.е. от++сить можно исходники почти любой операционки, если я все правильно понимаю. И разработка превратится в куда более эффективное мероприятие. Все разработчики будут работать параллельно, никто никого не ждет, все, что придумали архитекторы, тут же используется разработчиками, без маразмов типа Word и Excell. Ну и виртуализация достигнет небывалых высот. Могу какую-то обработку написать в matlabe и прикрутить ее такому синтетическому проекту. Можно потом реализовать то-же на dsPIC и устроить прогон – давать им на вход одинаковые данные и смотреть – совпали ли результаты. Красота! Критика и комментарии СИЛЬНО приветствуюся!