OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 11 Декабрь, 2019 21:57

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 42 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 13:18 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Axcel писал(а):
А я считаю, что с помощью Рефал-0 Ильи Ермакова организовать препроцессинг нефиг делать.

Вот бы пример увидеть -- какое-никакое а ФП... :lol:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 13:38 

Зарегистрирован: Среда, 31 Октябрь, 2007 18:58
Сообщения: 214
Откуда: Austria, Bruck
Роман М. писал(а):
  • PlatformUnixModuleloader - реализация UNIX-части
  • PlatformWinModuleloader - реализация Windows-части
  • HostModuleloader - связующий модуль. Что он должен содержать? Я что-то не въезжаю.

==
  • HostUnixModuleloader - реализация UNIX-части
  • HostWinModuleloader - реализация Windows-части
  • Moduleloader - интерфейсный модуль.

Собсно, Moduleloader описывает общие структуры данных, переменные, фабрики объектов и хуки (указатели на функции) и т.п. Именно его будут импортировать другие модули программы.

А Host...Moduleloader реализует платформо-зависимый код и фабрики объектов и инициализирует хуки.
Код:
MODULE Moduleloader;
VAR
   LoadSomething*: POINTER TO PROCEDURE(fname: String);
END Moduleloader.


Код:
MODULE HostUnixModuleloader;
IMPORT Moduleloader;
  PROCEDURE UnixLoadSomething(fname: String);
  BEGIN
   ...
  END UnixLoadSomething;
BEGIN
   Moduleloader.LoadSomething := UnixLoadSomething;
END Moduleloader.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 13:51 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Geniepro писал(а):
Axcel писал(а):
А я считаю, что с помощью Рефал-0 Ильи Ермакова организовать препроцессинг нефиг делать.

Вот бы пример увидеть -- какое-никакое а ФП... :lol:

Мои примеры связаны с разбором XML. Применительно к данной теме больше подойдут примеры из описания (Рефол-0). Вообще для данной задачи проблемы именно в организации: где держать модуль прототип, куда помещать модуль после обработки "Рефалом", "кнопку" удобно сделать. Но эти проблемы согласитесь не то, чтобы тривиальны, но и не сверх чего-то там.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 15:36 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 864
Откуда: Казань
Valery Solovey писал(а):
Rifat писал(а):
Все эти комбинации по разным модулям разнести практически невозможно, так получится "комбинаторный взрыв".
Комбинаторного взрыва не получится. По крайней мере, пока не произойдёт комбинаторного взрыва виндов. Для каждой версии системы достаточно иметь свои константы, вот и всё.

Здравствуйте, Валерий
Я не совсем понял, почему вы говорите, что "каждой версии системы достаточно иметь свои константы, вот и всё".
Значение константы может зависеть от версии windows.
Описание структуры может зависеть от того _WIN64 или нет.
Описания функций зависят от того UNICODE или не UNICODE.
Возможно есть еще много разных параметров которые влияют на значения констант, описания структур и функций.
Пусть версий Windows - 10, 64 битность добавляет еще коэффициент 2, юникодность еще 2. Итого имеем 10*2*2=40 версий модулей для разных случаев.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 16:20 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
bohdant писал(а):
Так там и "так" и "так" делают. Беда в том, что IFDEF проще применять, когда не продумана архитектура.

А вот я попросил бы земляка Кладова не обижать :)
Не факт, что он думал об архитектуре меньше, чем все мы вместе взятые.

У него стояла другая задача - изобрести "патерн", в результате которого в целевой код из библиотеки попадет ТОЛЬКО минимально необходимое.
У кого-то могут быть другие приоритеты, но и его позиция тоже - достойна внимания и уважения. А не заявлений о непродуманности.
И не его вина, что в технологии "надежного программирования" это недостижимо.

Собственно, это и является результатом его эксперимента. Можно даже сказать, что не изобрели еще (после многих десятилетий упорных трудов) таких технологий компилирования, которые позвляют решать эту задачу без потери эффективности.
Не говоря уже о "надежности"

Вот и получилась технология Zero errors (можно даже сказать, что вся либа - это один большой чит), да еще и требующая от пользователя достаточно хороших знаний архитектуры библиотеки.
Но для "пустой формы" пристегивается из ВСЕЙ библиотеки (по функциональности - VCL от Бормана) всего лишь ~6К.
И такого больше никто не умеет. Полноценных альтернатив как-то и нет... :(


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 20:36 
Аватара пользователя

Зарегистрирован: Суббота, 15 Март, 2008 20:00
Сообщения: 297
Откуда: Київ, Україна
Galkov писал(а):
А вот я попросил бы земляка Кладова не обижать

а я и написал:
bohdant писал(а):
из уважаемой мной библиотечки Кладова KOL:

Пример показывал трудность восприятия кода. У меня даже был случай, что я правил код, который не включался, условие его исключения было несколькими "экранами" выше, а нужный код мне ниже находился на несколько экранов ниже...
Действительно при создании Чита, приходится идти на жертвы.
Еще раз повторюсь, что к библиотеке Кладова весь флейм отношения иметь не может, т.к. там абсолютно другие задачи ставились.

Цитата:
И такого больше никто не умеет. Полноценных альтернатив как-то и нет... :(

Есть. Есть например ACL (там кстати IFDEF почти отсутсвуют).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 23:03 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
bohdant писал(а):
Есть. Есть например ACL (там кстати IFDEF почти отсутсвуют).
Неееее.
Не буду изучать (приходится фильтровать базар) :)
А вот сомнения - выскажу: не тот парень Кладов, чтобы начать делать чего-то с нуля, если БЫ можно было чего-то развивать.
И дельфи он выбрал из некотрых качеств компилятора (точнее - его линкера). Не применишь ту же технику на C-компиляторах...


bohdant писал(а):
Действительно при создании Чита, приходится идти на жертвы.
На данном форуме, как мне показалось, из данного обстоятельства принято делать вывод, что правильно жертвовать эффективностью
Посмотрите, старттоперу очень быстро объяснили, что пользоваться вычислениями в Compile-Time (именно это ведь и есть тот самый IFDEF) - жутко несовременно. Разрешать эти вопросы в Run-Time - вот где "золотая пуля"
У меня другое мнение на сей счет.
Правильно: придумывать "язык", чтобы и к надежности вопросов не было, и на жертвы идти не приходилось.
И никаких компромисов, если говорить о правильности.
ИЛИ-ИЛИ - это разговор адекватный зарождению технологии (в данном случае - IT). А несколько десятилетий таки уже прошло :wink:


bohdant писал(а):
Пример показывал трудность восприятия кода. У меня даже был случай, что я правил код, который не включался, условие его исключения было несколькими "экранами" выше, а нужный код мне ниже находился на несколько экранов ниже...
Аналогично.
Самое элементарное: видишь багу, правишь паскаль-код, а включен асм по умолчанию


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 17 Ноябрь, 2009 23:30 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9164
Откуда: Россия, Орёл
Galkov писал(а):
На данном форуме, как мне показалось, из данного обстоятельства принято делать вывод, что правильно жертвовать эффективностью
Посмотрите, старттоперу очень быстро объяснили, что пользоваться вычислениями в Compile-Time (именно это ведь и есть тот самый IFDEF) - жутко несовременно. Разрешать эти вопросы в Run-Time - вот где "золотая пуля"


Тут у нас с Вами какое-то недопонимание.

Речь же идёт не о какой-нибудь интерпретации в рантайме. А просто о коммутации модулей (виртуальный вызов по переменному адресу вместо статически прошитого). Для области не-микроконтроллеров несерьёзно обсуждать какую-то потерю эффективности на этом (в общем случае, для таких служб, как файлы и т.п.), а качество решения принципиально иное (ну вот часто хоть убейся надо всё перетыкать "на лету" - например, серверные службы не остановишь и не заменишь на заново слинкованную версию). Так же как в общем случае несерьёзно отказываться от контроля границ массивов ради выжимания капель скорости (и то на локализованных числодробилках).

Что касается класса серверного ПО (и пошире, там много родственных систем - "массовое интерактивное обслуживание" обозвать их, что ли...), там вообще мелкогранулярные выигрыши (какие-нибудь проценты, пусть даже десятки процентов, на конкретной операции в коде) значение теряют, за просадками на вводе-выводе - диск, сеть..
А вот архитектура реально играет значение - и на эффективность в том числе (например, удачный свой диспетчер параллелизма может дать нехреновый эффект. Кроме того, если удаётся держать систему компактной и модульной, она быстро, разумеется, работает).

Кроме того, отмечу такой факт (раньше нигде не встречал, так что на приоритет мысли ставлю свой (С) :) ), что если система разбита на мелкие части, которые соединяются через виртуальные ОО-интерфейсы, в ряде случаев резко падает количество IF (т.е. принятия решений). Потому что ту или иную опцию я указываю не параметром, который где-то ниже обрабатывается выбором варианта поведения; а непосредственной коммутацией из кирпичиков с нужными свойствами. (т.е. принятие решения идёт автоматом по таблице виртуального вызова).
Объяснять, почему уменьшение IF-ов сильно повышает верифицируемость и тестируемость (в смысле прогонов для защиты от опечаток), думаю, не надо. Любой IF удваивает число маршрутов в программе и в плане глупых ошибок гораздо опаснее любого сложного цикла (который нормально по индукции доказан и один раз протестирован для защиты от опечаток - и уже железобетонен).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 18 Ноябрь, 2009 00:22 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
...если система разбита на мелкие части, которые соединяются через виртуальные ОО-интерфейсы, в ряде случаев резко падает количество IF
А мне казалось, что это основное следствие ООП... "Скажи IF-ам нет!"


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 18 Ноябрь, 2009 01:46 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Роман М. писал(а):
давайте рассмотрим модуль moduleloader.pas для межплатформенной динамической загрузки библиотек
Код:
MODULE Moduleloader;

  TYPE
    TModuleHandle = POINTER TO RECORD END;
    SymbolType = POINTER TO RECORD END;
    Module = POINTER TO RECORD    END;

    Directory = POINTER TO RECORD END;
       
  VAR dir- : Directory;
       
PROCEDURE (m : Module) Load (...) : BOOLEAN; BEGIN END Load;
PROCEDURE (m : Module) LoadEx (...) : BOOLEAN; BEGIN END LoadEx;
PROCEDURE (m : Module) Unload (...); BEGIN END Unload;
PROCEDURE (m : Module) GetSymbol (...) : SymbolType; BEGIN END GetSymbol;
PROCEDURE (m : Module) GetSymbolEx (...) : SymbolType; BEGIN END GetSymbolEx;
PROCEDURE (m : Module) ReadData (...) : BOOLEAN; BEGIN END ReadData;
PROCEDURE (m : Module) WriteData (...) : BOOLEAN; BEGIN END WriteData;

PROCEDURE (d : Directory) NewModule(VAR m : Module, name : ARRAY OF CHAR);
BEGIN
END NewModule;

PROCERURE SetDir(d : Directory);
BEGIN
  dir := d;
END

END Moduleloader.

Код:
MODULE WinModuleloader;
(*Реализация. Здесь содежится только то, что для win*)
  IMPORT Moduleloader;

  TYPE
     TModuleHandle = POINTER TO RECORD (Moduleloader.TModuleHandle) END;
     SymbolType = POINTER TO RECORD (Moduleloader.SymbolType)
     END;(* возможно, этот тип платформонезависим и мог бы реализоваться в Moduleloader *)
    Module = POINTER TO RECORD (Moduleloader.Module)        END;
       
     Directory = POINTER TO RECORD (Moduleloader.Directory)  END;
       
PROCEDURE (d : Directory) NewModule(VAR m : Module, name : ARRAY OF CHAR);
BEGIN
        (*конструктор*)
END NewModule;

END WinModuleloader.

WinModuleloader знает о Moduleloader, а значит, знает всё то, что может потребоваться его клиентам. Он это реализует. Moduleloader наоборот - ничего не знает о реализациях. Их может быть сколько угодно.

Moduleloader.SetDir() запускается из другого модуля. Назовём его конфигурационным.

Если требуются минимальные изменения в проекте, то Moduleloader можно сделать таким:
Код:
MODULE Moduleloader;

   TYPE
     TModuleHandle = POINTER TO RECORD END;
     SymbolType = POINTER TO RECORD END;

   VAR LoadModule- : PROCEDURE (...) : BOOLEAN;
     LoadModuleEx- : PROCEDURE (...) : BOOLEAN;
     UnloadModule- : PROCEDURE (...);
     GetModuleSymbol- : PROCEDURE (...) : SymbolType;
     GetModuleSymbolEx- : PROCEDURE (...) : SymbolType;
     ReadModuleData- : PROCEDURE (...) : BOOLEAN;
     WriteModuleData- : PROCEDURE (...) : BOOLEAN;
       
PROCEDURE SetLoadModule (p : PROCEDURE (...) : BOOLEAN);
BEGIN
   LoadModule := p
END SetLoadModule;

(*...*)

END Moduleloader.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 18 Ноябрь, 2009 03:32 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Речь же идёт не о какой-нибудь интерпретации в рантайме. А просто о коммутации модулей (виртуальный вызов по переменному адресу вместо статически прошитого)
Это вы мне объясняете :?: :D
В известной Вам среде (в "классическом" пакете) именно так все и устроено.
Можно даже сказать, что сверх-так: даже if-ы и циклы сидят на этих ((не побоюсь этого слова)) "абстрактных разъемах".
И подтверждаю - все надежно, аж до безобразия. Баги могут сидеть только в кодах элемента (читай - модуля), написанных на скриптовом языке.
И поиск такого элементика - тупой до немогу: методом "деления пополам". Выделил (тупо) половину схемы, удалил, посмотел на багу, принял решение про нужную половину - и т.д., рекурсивно.
Кстати говоря, именно из-за этого "сверх-так" и заметнее у нас "потери на разъемах"



Илья Ермаков писал(а):
Для области не-микроконтроллеров несерьёзно обсуждать какую-то потерю эффективности на этом (в общем случае, для таких служб, как файлы и т.п.), а качество решения принципиально иное (ну вот часто хоть убейся надо всё перетыкать "на лету" - например, серверные службы не остановишь и не заменишь на заново слинкованную версию). Так же как в общем случае несерьёзно отказываться от контроля границ массивов ради выжимания капель скорости (и то на локализованных числодробилках).

Сразу про главное: ЕСЛИ речь идет идет о выборе меньшего из двух зол, то я категорически выберу надежность.

А теперь о деталях :wink:
1) Какими малыми не казались потери, их, во-первых, надо сравнивать с чем-то, а не просто так "несерьезно". Во-вторых, и числодробительные задачи в природе существуют, и области для микроконроллеров отмирать как-то не очень собираются. И в-третьих, давайте задумаемся о причинах, ради которых следует мириться дже с незначительными потерями.
2) Про во-первых. Как-то я упоминал FastMathParse... Так вот, написать в нем такую формулищу, время исполнения которой хотя бы сравнимо с временем "прохода сигналов через разъемы" (аргументы для вычислений тоже запрашиваются через "разъемы", хотя раньше я об этом не упоминал) - крайне затруднительно. Это экспериментальный факт.
Да, не каждый день у меня спрашивают "а чё оно работает медлене явы". Но когда спросят, я испытываю некий дискомфорт от необходимости объяснять, что на алгоритмической ветке (это у нас так принято называть структурную единицу алгоритма) цикла в его схеме сидит под сотню тех самых "разъемов".
3) Про во-вторых забыл сказать. Поставить клиенту микро-ось со всеми необходимыми каркасами - это вариант, допустим даже, что и достойный уважения. Но существует задача "отсечения всего лишнего". И достойная не меньшего уважения. Причины могут быть самыми разными. И embeded - одна из простейших, и далеко не единственная. Ровно в тот момент, когда мне скажут, что это уже "несовременно", я буду категорически возражать. Скажите ???
А вот тут, должен Вам отметить, что технология раздельной компиляции интеферирует с ООП просто кошмарным образом. Грубо говоря, ни один линкер не определит, что подавляющее количество методов в VMT никогда не используюся в этом конкретном проекте. И именно эта "интерференция" и делает в основном из банальных задач многометровые exe-шники.
4) Ну и наконец про причины, по которым я должен мириться ДАЖЕ с "микронными" потерями. Она могла быть только одна - все сразу не делается, придет время и будет нам счастье.
Не придет, если мы будем сидеть и ждать пока оно придет. Как отмечал уже выше - не первое десятилетие ждем.
И что же я слышу ??? Что оптимизация - это от лукавого, оказывается
Кстати говоря, даже т.н. мелкогранулярная оптимизация - вещь заметная, хоть и не настолько кошмарная, как вышеупомянутая интерференция. Правда тут я могу уверенно судить про те компиляторы, которые хорошо знаю.
Вроде бы Дельфи не самый худший из них... И если вспомнить, не к ночи упомянутый KOL, то там на многие коды есть их же асм-версии. Хорошо знаю код AlignChildrenProc. Так вот, НЕ будучи профессионалом (так, за выходные), я обошел дяденьку Бормана в полтора раза (~600байт против ~1К). А ведь там была та самая мелкогранулярная оптимизация... Про FPC даже и говорить не буду, чтобы не растраиваться.
Спрашивается почему я должен терять эти 30-40% эффективности ??? Потому-что говорить об этом не серьезно, что ли ???


Почему я говорил про это... Потому-что все время как-то так получается, что золотая пуля давно найдена, а все остальное - "несерьезно".
Нефига она не найдена ((может в этом и есть то самое "какое-то недопонимание"?))
И я ее не нашел еще. Но я зато знаю, что ее надо искать :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 18 Ноябрь, 2009 09:01 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Galkov писал(а):
Посмотрите, старттоперу очень быстро объяснили, что пользоваться вычислениями в Compile-Time (именно это ведь и есть тот самый IFDEF) - жутко несовременно.

Вычислять в компиле-тайме -- сейчас самый писк моды.
Но не примитивные IFDEF, а нормальные вычисления -- вычисления в системе типов, суперкомпиляция, даже несколько устаревшие шаблоны в С++.
В идеале, программа, которая не зависит от внешних ресурсов, после компиляции должна просто выдавать готовый ответ без всяких расчётов в ран-тайме...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 18 Ноябрь, 2009 14:29 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Ну, немножечко плавали...
У нас в пакете Fasm коды элементов есть макросы, которые генерируют другие макросы, производящие макросы, генерирующие реальный код.
От такого писка может и ухи заложить :lol:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Воскресенье, 29 Ноябрь, 2009 01:14 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Galkov писал(а):
У нас в пакете Fasm

У Вас в Fasm - Вы что, разработчик FASM??! Или - разработчик HiAsm?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Воскресенье, 29 Ноябрь, 2009 02:54 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
"У нас" - уже означает HiAsm, есть "подразделения", одно из которых и называется "пакет fasm"

В HiAsm когда-то давно произошло разделение разработки на собственно разработку, и кодогенерацию.
Последняя - просто стала плагином, который доступен к написанию пользователем.
Есть такая CodeGen.dll (которую особо умный пользователь и сам написать может), которая получает от среды некий "интерфейс", опираясь на который может узнать все детали и подробности схемы.
И сделать чего угодно, вообще-то говоря.
Классический пакет (элементная база + CodeGen.dll), делает код для Дельфи (FPC), есть пакет для web (скажем php на выходе). Ну и есть который делает код для fasm-а


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Четверг, 23 Февраль, 2012 17:58 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 350
Откуда: Украина, Днепропетровская обл.
bohdant писал(а):
Я не знаю как сделано в ЧЯ, расскажу как сделано в ГБ.
Системные функции (или лучше сказать платформ-зависимые) выносятся в отдельные модули (ядро) типа:
Unix.Platform.Mod, Win32.Platform.Mod и т.п.
В зависимости от целевой платформы компилируется нужный модуль(компонентная система однако), и это происходит незаметно со стороны пользовательской программы(модуля)
В ЧЯ имеется аналогичная возможность. Платформенно-зависимые участки кода также выносятся в отдельные файлы модулей типа:
SubsysUnixPlatform.odc, SubsysWin32Platform.odc и т.п. (Здесь Subsys — подсистема ББ; UnixPlatform и Win32Platform — модули внутри неё), Междуплатформенный модуль выглядит так:
Код:
MODULE SubsysPlatform;
...
END SubsysPlatform.
Модуль с уровня исходного Оберон-текста имеет имя SubsysPlatform, но на уровне имени исходного файла модуля можно применить другое имя, что даёт возможность иметь разные реализации одного модуля для разных применений, выбираемые при компиляции и линковке статически. Может не совсем задокументированная возможность, но полезная.

В коммандере вызываем компиляцию, в другом линковку (пример из портируемой мною на КП библиотеки KOL):

Код:
# Compile UNICODE version of KOL:
[O]DevCompiler.CompileThis
KolObjects KolTypes KolStrings KolRegistry KolIniFiles KolIO KolFiles ~

# Compile ANSI version of KOL:
[O]DevCompiler.CompileThis
KolObjects KolTypesA KolStringsA KolRegistryA KolIniFilesA KolIOA KolFilesA ~

На этом этапе компилируются перечисленные имена файлов модулей, объектники создаются того же имени, что и имя исходного модуля (не файла модуля) (без имени подсистемы, но внутри её папки); т.е. модуль с именем Platform.odc (но сохранённый в файле Win32Platform.odc) будет скомпилирован в кодовый файл Platform.ocf (и символьный Platform.osf), а в коммандере вызова компиляции мы указываем имя файла модуля, но не имя самого модуля.

Линковка:
Код:
# Generate UNICODE application:
[O]DevLinker.LinkExe dos KolIniFilesTest.exe := Kernel+
KolTypes KolStrings KolObjects KolIO KolIOWin KolFiles KolIniFiles KolIniFilesTest$ ~

# Generate ANSI application:
[O]DevLinker.LinkExe dos KolIniFilesTestA.exe := Kernel+
KolTypesA KolStringsA KolObjects KolIOA KolIOWin KolFilesA KolIniFilesA KolIniFilesTest$ ~
Примерно также можно изменить KolIOWin на KolIOLin и получить уже приложение для Linux.
Такой способ конечно не позволяет изменить реализацию модуля в рантайме, но в ББ для этого есть и другое средство — динамически загружаемые модули. Чем иногда имеет смысл не пользоваться. Например, маловероятно, что нашему приложению в рантайме заменят ОС, и оно будет вынуждено перейти с KolIOWin на KolIOLin в рантайме. В этом случае лучше будет обойтись без излишних накладных расходов. Что реализуемо показанным мною выше способом.

Возможность эта очень мощная, и ею надо пользоваться с осторожностью внутри компонентной системы. Пожалуй, она хороша только для генерации независимых программ. Покажу как можно нарушить запускаемость среды ББ таким способом. Вот есть 2 коммандера для компиляции-линковки программы под 1) Win и 2) Linux:

Код:
# Generate BB-independent Win32 console application w/o icon:
[O]DevCompiler.CompileThis
Kernel KolTypes KolIO KolIOWin KolStrings KolIOTest ~

# Generate BB-independent Linux shared object:
[O]DevCompiler.CompileThis
LinKernel KolTypes KolIO KolIOLin KolStrings KolIOTest   ~

Теперь если мы нажмём на них в порядке следования (1, потом 2), закроем ББ и запустим снова - оп-ля. ББ не запускается. Происходит это потому, что ядро для Win32 после вызова второго коммандера и компиляции файла LinKernel заменено на ядро для Linux. Файл LinKernel (модуль Kernel) сел на место модуля Kernel самой системы ББ. Теперь, естественно, приходится чинить систему, подпихивая ей кодовый-символьный файлы виндового ядра.

Если знаете решение как собирать приложения под линукс, не портя кодового/символьного файлов виндового ядра, поделитесь.

Rifat писал(а):
Пусть версий Windows - 10, 64 битность добавляет еще коэффициент 2, юникодность еще 2. Итого имеем 10*2*2=40 версий модулей для разных случаев.
С Рифатом здесь я совершенно согласен. Количество модулей (причём очень сильно похожих друг на друга) может вырасти значительно, и в этом случае отслеживать все изменения в каждом из них и актуализировать состояние всех и каждого, особенно при активной разработке, очень сложно и громоздко. Поэтому применение условной компиляции в таком случае было бы оправдано. Но во многих случаях ею пользуются как безплатным довеском, что вовсе не украшает код.

Пример. Я делаю биндинги для библиотеки SDL. Win32 и Linux варианты отличаются крайне незначительно, вносить правки сразу в оба файла напрягает. Каждый раз вносить правки, отличающие Linux-вариант от Win32-варианта, тоже напрягает. Здесь не помешал бы внешний препроцессор, который просто будет вносить правки по заданному паттерну автоматически. Но это простой пример. Достаточно усложнить его, например, желанием иметь ещё и варианты для разных диалектов Оберона. Добавим AO и XDS, уже вариантов будет 6, и так далее.

Владимир Кладов разработал, кстати, неплохой способ, чтобы обойти указанные сложности. Называется GlueCut. Гуглируйте. Нам бы что-то подобное для Оберонов.


Последний раз редактировалось Oleg N. Cher Суббота, 03 Март, 2012 09:25, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Суббота, 25 Февраль, 2012 23:49 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Пока читал ветку, возникла мысль и .... вы ее уже озвучили :D
Хорошо что до конца дочитал.
Остается только подтвердить пригодность сего способа 8)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Воскресенье, 26 Февраль, 2012 12:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Oleg N. Cher писал(а):
...
Пример. Я делаю биндинги для библиотеки SDL. Win32 и Linux варианты отличаются крайне незначительно, вносить правки сразу в оба файла напрягает. Каждый раз вносить правки, отличающие Linux-вариант от Win32-варианта, тоже напрягает. Здесь не помешал бы внешний препроцессор, который просто будет вносить правки по заданному паттерну автоматически. ...
Имеется в виду, что он ищет и заменяет заданный паттерн (скажем, в зависимости от заданного фактора выбора - того же назначения результирующего файла) сам? Или в исходном файле пишущий указывает "вот здесь место для паттерна №..." (хранимого под этим номером в его "коллекции" во всех нужных вариантах), а внешний препроцессор только подставляет вариант паттерна по месту каждого указания (и по заданному фактору опять же)?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Вторник, 28 Февраль, 2012 13:39 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 350
Откуда: Украина, Днепропетровская обл.
Владислав Жаринов писал(а):
Имеется в виду, что он ищет и заменяет заданный паттерн (скажем, в зависимости от заданного фактора выбора - того же назначения результирующего файла) сам? Или в исходном файле пишущий указывает "вот здесь место для паттерна №..." (хранимого под этим номером в его "коллекции" во всех нужных вариантах), а внешний препроцессор только подставляет вариант паттерна по месту каждого указания (и по заданному фактору опять же)?

Не, ну для автоматической продвинутой замены чего-то на чего-то (даже с регулярными выражениями) по тексту лучше использовать SED. Кажется, А.Ильин даже с его помощью перегонял сишные заголовки SQLite в интерфейсный модуль для XDS.
GlueCut же работает по-иному. Это узкоспециализированный инструмент, разработанный специально для облегчения адаптации KOL с Delphi на FreePascal.
Прямо в исходном тексте в комментариях специального вида препроцессору указывается что убрать и что добавить. Примерно так:
Код:
{ ---------------------------------------------------------------------
                  TObj - base object to derive all others
---------------------------------------------------------------------- }
//[TObj DEFINITION]
   TObj = {-} object( _TObj ) {+}{++}(*class*){--}
   {* Prototype for all objects of KOL. All its methods are important to
      implement objects in a manner similar to Delphi TObject class. }
   {= Базовый класс для всех прочих объектов KOL. }

И тогда Delphi спокойно компилирует это, потому что вставка внутри комментария. А GlueCut создаёт вариант для FPC, убирая то, что помечено {-}, добавляя, что помечено {+}.

Ещё по теме. Аналог препроцессора может быть достигнут в ББ с помощью селекторов.

http://oberoncore.ru/wiki/blackbox/devselectors
viewtopic.php?f=1&t=435


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Замена условным директивам ifdef
СообщениеДобавлено: Среда, 29 Февраль, 2012 12:18 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Спасибо! В общем, тянет на чисто текстовый механизм "областей с подстановками", наверное... :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 42 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB