Evgeny_CD, Архитектор (17.09.2007 19:40, просмотров: 186) ответил bialix на Евгений, как движется претворение ваших синтетических идей в жизнь?
Вот сижу и прикидываю, как бы мне поднять на пЫсюке сеть из базовой станции и 1к периферийный девайсов для симуляции радиосети. Желательно быстрее реального времени (скорость в канале маленькая, 1200). Я согласен с тем, что читабельность превыше всего.
Я пока не придумал изящного решения такой проболемы. Есть два варианта:
* макросы - как Вы описали
* супер-пупер автоматический рафакторер.
Мои эксперименты (придумывал вариант разметки и пробовал писать с ним, естественно без обработки) с различными теговыми системами убедили меня, что фтопку. Код должен быть простым и незамусоренным.
Единственный вариант - это shadow файлы, которые описывают комплементарный файл с кодом. Туда все теги и надо прятать.
Т.е. есть мастер С файл, который компилируется рефакторером в целевой С файл под целевую платформу. В embedded варианте рефакторер рожает
REG = value;
В синтетичеком варианте
SET(REG, value); // REG = value;
естественно, автоматически инклюдится хидер, который раскрывает этот SET хоть в десяток вызовов Win32API.
В shadow файле прописаны теги, и есть отдельно файл - правила рефакторинга.
В общем, сильно продвинутый COG.
Еще вариант - protoC + спецсимволы. Например, вы работаете с файлом вида
. REG = value;
Компилятор protoC компилит в
/* REG = value; */ SET(REG, value);
Кароче, нету у меня пока красивого рецепта борьбы с этой засадой, который бы мне самому нравился. Похоже, проще всего все-таки поднастроить моск, чтобы он адекватно работал с SET(REG, value);
Но рефакторер все равно нужен.
Простой пример - мне надо при симуляции запустить 1к копий кода целевого устройства. Без модификации оного :)
Можно сделать exe из переменной обертки и постоянного кода. Накомпилить 1к exe, затем запустить их как 1к процессов. Вначале офигеет финда, потом офигею я - от "скорости". Потери времени на взаимодействие процессов на порядки больше, чем на то же самое между нитями.
Можено отрефакторить целевой код, сделав его полностью реентерабельным. Но это тупиковая ветвь, ибо то, что в целевом коде мне было удобно делать static, станет выделяться по maloc (зацените объем рефакторинга); то, что было флешовой константой, станет переменной и т.д. - короче, это ужу бедет херня, я не синтетический порт.
Можно сделать С++ обертку к целевому коду, но тут могут вылезти несовместимости С и С++, да и аккурытным надо быть - а то потом отлаженную хреновину пожно в С назад и не портировать. А так фичи С++ по работе с пространством имем было бы очень хорошо использовать.
А проще всего сделать рефакторер.
Есть дир - целевой код. Рефакторер берет, из рожает дир для device_001, ко всем глобальным и статическим сущностям целевого кода добавляя device_001.
Так 1к диров.
Также он рожает make файл для сборки 1к поточного приложения из всего этого. Запускаем на компиляцию, идем обедать :) зато 1к поточное приложение - это куда быстрее, чем 1к процессов. Вот где 4 ядерные процы пригодятся - если не тупить при написании, распаралелится в легкую. Тут и SUN ниагара с 32 потоками самое то будет :)
Осталось придумать стандарт для такого рефакторера. Ну и совсем малость - сделать его :)))))))))