информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetСетевые кракеры и правда о деле ЛевинаСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ну а если просто передавать в качестве параметра enum и по... 25.06.08 09:19  Число просмотров: 4390
Автор: Heller <Heller> Статус: Elderman
<"чистая" ссылка>
Ну а если просто передавать в качестве параметра enum и по ходу кода понатыкать if'ов-switch'ей? (правда в АСМе это будет еще менее удобно).
<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'ей? (правда в АСМе это будет еще менее удобно).
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach