Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Чем более фундаментален кирпич, тем больше из него можно построить 25.06.08 09:45 Число просмотров: 4279
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 25.06.08 10:13 Количество правок: 2
|
> Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80
> малюсеньких подрограмм нельзя назвать удачным решением и
> упрощением программы
Зато когда эти (подозреваю, что существенно меньше 80, состояний-то 16) подпрограммы будут написаны, можно будет макросами (а затем макросами макросов итд, т.е. квазиструктурно) сделать не только читабельное решение данного вычпроцесса, но и добавить к нему дополнительных ветвей без ущерба для мозга, времени, а также оптимальности результата
|
|
<theory>
|
Средства для упрощения создания полиморфных модификаций… 22.06.08 17:16
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
|
Посоветуйте средства для упрощения создания полиморфных модификаций фрагментов кода
Вопрос шибко заумный, но очень актуальный.
Попытаюсь объяснить, в чём суть. Надеюсь, что у меня это получится.
Объяснение построю на примере решения конкретной задачи.
Имеется 4 флага состояния некоего вычислительного процесса. Соответственно имею 16 возможных состояний вычислительного процесса. А значит 16 ветвей алгоритма. Пишу на АСМе. Но это не существенно для обсуждаемой проблемы – так как с подобными проблемами мы сталкиваемся при написании программы на любом языке: СИ, СИ++ и т.п.
Каждая ветвь представляет собой фрагмент кода, который отличается от любого другого из 16-ти в 3-4-х местах. Например, вместо команды SUBI, команда SBCI, или вместо регистра ZH в команде используется XH. Сам же размер кодовых фрагментов порядка 50-ти ASM-команд.
Так вот. Хотелось бы не переписывать каждый раз 50 команд во всех 16-ти ветвях, а просто указать директивой какой кодовый фрагмент нужно взять за базовый и в каких местах и что нужно заменить.
Макросами не получиться. Потому что изменения каждый раз в разных местах – получается более 30-ти параметров. Указывать при вызове макроса все его 30 параметров вряд ли можно назвать упрощением решения задачи.
Есть ли в каких-нибудь языках средства, позволяющие генерировать новые кодовые фрагменты путём указания кодового фрагмента-прототипа, который нужно взять за базовый и указания что в нём нужно заменить для получения нового фрагмента кода.
Т.е. в каких-нибудь языках программирования средства, упрощающие и облегающие создание полиморфных модификации фрагментов кода? Если есть, то что это за средства.
|
|
Всё это очень похоже на процедуры\функции 24.06.08 15:09
Автор: Ustin <Ustin> Статус: Elderman
|
> Так вот. Хотелось бы не переписывать каждый раз 50 команд
> во всех 16-ти ветвях, а просто указать директивой какой
> кодовый фрагмент нужно взять за базовый и в каких местах и
> что нужно заменить.
Если разбить "некий вычислительный процесс" на несколько "неких вычислительных процессов", которые будут представлять из себя "до различия", "после различия" и собсно "во время различия" (которых будет несколько), а потом на основании флагов состояния ходить в определённый кусок кода с последующим возвратом?
Понятно, что случай не общий, но приблизиться к решению задачи таким образом можно (а попутно мы также приближаемся к структурному, а затем к объектно-ориентированному программированию)
|
| |
Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80... 25.06.08 00:05
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
|
> > Так вот. Хотелось бы не переписывать каждый раз 50
> команд
> > во всех 16-ти ветвях, а просто указать директивой
> какой
> > кодовый фрагмент нужно взять за базовый и в каких
> местах и
> > что нужно заменить.
> Если разбить "некий вычислительный процесс" на несколько
> "неких вычислительных процессов", которые будут
> представлять из себя "до различия", "после различия" и
> собсно "во время различия" (которых будет несколько), а
> потом на основании флагов состояния ходить в определённый
> кусок кода с последующим возвратом?
> Понятно, что случай не общий, но приблизиться к решению
> задачи таким образом можно (а попутно мы также приближаемся
> к структурному, а затем к объектно-ориентированному
> программированию)
Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80 малюсеньких подрограмм нельзя назвать удачным решением и упрощением программы
|
| | |
Чем более фундаментален кирпич, тем больше из него можно построить 25.06.08 09:45
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 25.06.08 10:13 Количество правок: 2
|
> Не катит.. Ибо разбивать код 16-ти ветвей на более чем 80
> малюсеньких подрограмм нельзя назвать удачным решением и
> упрощением программы
Зато когда эти (подозреваю, что существенно меньше 80, состояний-то 16) подпрограммы будут написаны, можно будет макросами (а затем макросами макросов итд, т.е. квазиструктурно) сделать не только читабельное решение данного вычпроцесса, но и добавить к нему дополнительных ветвей без ущерба для мозга, времени, а также оптимальности результата
|
| | | |
Состояний 16, а микропераций, на которые можно разбить 16... 25.06.08 14:15
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
|
> > Не катит.. Ибо разбивать код 16-ти ветвей на более чем
> 80
> > малюсеньких подрограмм нельзя назвать удачным решением
> и
> > упрощением программы
> Зато когда эти (подозреваю, что существенно меньше 80,
> состояний-то 16) подпрограммы будут написаны, можно будет
> макросами (а затем макросами макросов итд, т.е.
> квазиструктурно) сделать не только читабельное решение
> данного вычпроцесса, но и добавить к нему дополнительных
> ветвей без ущерба для мозга, времени, а также оптимальности
> результата
Состояний 16, а микропераций, на которые можно разбить 16 ветвей более 80-ти.. Так что не правильно подозреваете
|
| | | | |
Докладываю. 27.06.08 00:05
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
|
Докладываю.
Решил проблему с помощью препроцессорных директив #include и #define.
Удалось сократить размер исходника с 890 строчек до 278 строчек при упрощении его структуры и увеличении читабельности за счёт того, что явно выделены отличия порождаемых фрагментов от прототипа. Также удалось с помощью применения такого подхода наконец-то похерить все ошибки, возникавшие раньше из-за не внимательности при переписывании/копипастинге по 16 раз одних и тех же мелких кусочков кода. Также удалось увеличить лёгкость внесения изменений.
Реализовал парадигмы «объектно-ориентированного» и одновременно «порождающего» программирования. У меня в коде прототипа используются виртуальные метки, переменные, константы, …., вообще произвольные фрагменты текста исходника.
Сам прототип оформил как отдельный файл, а порождение его полиморфных модификаций реализовал так.
1.Линкуем виртуальные идентификаторы с помощью директив #define
2.#include “PrototipFile”
|
| | |
Ну а если просто передавать в качестве параметра enum и по... 25.06.08 09:19
Автор: Heller <Heller> Статус: Elderman
|
|
Ну а если просто передавать в качестве параметра enum и по ходу кода понатыкать if'ов-switch'ей? (правда в АСМе это будет еще менее удобно).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
