Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[PPC]

Да его уже лет 15 хоронят. Что дальше?

Эээ, дорогой Vitamin, тут вы очень мягко ещё сказали. На моей памяти, C++ хоронят аж с года с 91го, с самого страус трупа первого, с x3.169, а то и ранее, когда один cfront был препроцессирующий. Хоронят яростно, иступлённо-фанатично, с рвением и горящими глазами.
Правда, за это время, многие из тех кто хоронили как-бы сами помре, но тихонечко, в уголку. А кое-кто из хоронящих даже реинкарнировался. Microsoft Java, никто не помнит что такое и откуда и куда? ;-)
Синтаксис, семантика, новые выразительные средства, лямбды, мусорщики, насаждение одной определённой memory management policy (будь то COW, reference counting, потом reference linking) как панацеи от всего, прорыв в будущее rapid SW development, кибернетические олигофрены из Rational Rose с их идеями о "программист-это вред" и "последний программист ещё в нашем тысячелетии" (знаком лично) автоимплементацией из сиквенс и стэйт диаграм, Power Builder с кошмарной промежуточной кодогенерацией, пи-коды всех мастей, пост-компилируемый PEF, языки с промоутом смарт поинтеров одного жёсткого типа, сколько всего было...
И где это? APL, Lisp, F, Pascal, Ada (толстая и говорливая женщина), Модула, пи-эли, эйффели, Алголы, Коболы, Сноболы, жабы,языки с обратной польской нотацией типа Форта, ООП-нашествие, фанатичный Никлаус, упёртый Седжвик, проблемно-ориентированный кошмар VLC, скриптовое нашествие, новые волны managed конструкций, упрощения Бэйсика (кухарки, управляющие империями), библиотеки поддержики, размером с Большую Советскую Энциклопедию, где есть всё, кроме того что вам нужно, время контролов (умрут все языки, но контролы будут жить). Они все с нами, конечно. Но как тараканы - пр нишам. Все они в той, или иной мере, пытались ограничить возможности программиста, отгородить его от машины, вогнать в рамки "новых космических парадигм", проверить и уличить "нерадивого". И у всех-одна беда - они были задуманы против программера. А C и плюсы -за программера. Не для программера, а ЗА Программера с Большой буквы. И compile-time полиморфизм, дедукция шаблонов, тайп листы, частичная специализация и лямбды в Cxx.11 не императива, а расширение выразитедьных средств-не более того. И никто не обидится на ваш собственный пролог код, выбранный вариант динамической линковки или лично вами прописанную rtl для какой-то платформы, или small object allocator, выделяющий память по 3 бита на Марсе. Хотите модульность-используйте. Любите ООП -занаследуйтесь до ациклического визитора, или законтейните все контейнеры stl как матрёшка в матрёшку. Проверяйте поинтеры при входе, не проверяйте -делайте как хотите. Хотите корявый дизайн с динамическими апкастами и rtti - да пожалуйста. Хотите разбить весь код на 100500 модулей до уровня строка-на модуль - ради бога. Раздельная компиляция и линкер вам в помошь. Или хотите запихать весь ваш код, включая Nucleus , STL port и SQL ядро в один файл-ваше дело, вам дерзать (только с пространствами имён разберитесь). Хотите за$$ть весь код ассемблерными вставками, и закондитить компиляцию под 100 платфлрм, создать алиас на сегмент кода и модифицировать его как сегмент данных-ради бога.
Нет ребята, С и С++ не вечны, но они погибнут только тогда, когда появится язык предоставляющий программеру БОЛЬШЕ свободы. Свобода-это стимул к совершенствованию, а человек так устроен, что он не может не совершенствовать потому, что он при этом совершенствует себя.
А какой-то одной фичей (православная модульноссть, встроенный мусоропровод) или парадигмой кого, вы удивиить хотите!?
Ну тока что для, кайфа. Сорри за некий флейм, но тема вполне стала его достойна имхо.

[Advertiser]

[Vitamin]

Уже ничего хорошего услышать про Оберон от тебя и не жду, Vitamin, но вот один вопрос я бы хотел обсудить, если есть что сказать. Это генерация кода с ЯВУ в машкод, сопоставимая по качеству с ручным кодированием на асме, сделанного опытным специалистом, или даже превосходящая эту планку. Назовём условно это сверхкодогенерацией.

Сферической конь в вакууме.
1) что есть качество кодирования? Четкий формальный критерий пожалста
2) для каких объемов кода меряется качество? Как известно, чем больше выборка, тем она достовернее. Проблема в том, что человек всегда будет отставать от компилятора.

Проблема сверхкодогенерации ведь не решена, а отодвинута сверхмощным железом в долгий, почти вечный ящик. А ведь проблема интересная. И могла бы быть обкатана на спеке и поюзана на других архитектурах, вытесняя нафиг виртуальные машины, интерпретаторы и прочее зло на законно полагающееся для них место - фтопку.

Зачем сужать кругозор? Те проблемы, которые на одних платформах решаются путем невероятных усилий, на других просто не существуют. Это как живой мир- есть размножение, скрещивание, мутации. Выживают лучшие по каким-либо важным показателям. Меняются приоритеты- меняются лучшие.

И ведь не скажешь что фидошник. Алё, ты меня помнишь по фидо, балбес?

Не могу помнить, балда! У меня никогда не было поинта, а число постов через гейт можно пересчитать по пальцам на руке.

---------- Post added at 09:37 ---------- Previous post was at 09:31 ----------

PPC, и мне отсыпьте

[PPC]

[/COLOR]PPC, и мне отсыпьте

Аминь! :-)

[Oleg N. Cher]

Значит за 4 месяца (время внедрения поддержки текстового формата) это полчеловека. Банально не долждался.

Говорю тебе ещё раз: поддержка экспорта в текст и импорта из текста в среде ББ, на которой базируется XDev, есть уже давно. И готовые подсистемы поддержки раскраски синтаксиса есть (как минимум 3), хоть и не встроены в базовый дистрибутив, так что моя вся работа была - прикрутить кодировку 1251 (да, знаю-знаю, это заслуживает всяческой критики, а надо UTF-8) и внедрить подсистему для раскраски в сборку XDev, маленько адаптировав выбранную мной готовую подсистему под новое ядро ББ 1.6, под котороге она не была заточена изначально.

Так что если уж перефразировать твоё "на дождался", то как минимум в "не больно-то и хотелось", согласен?

попробуйте реализуйте вменяемый dependency injection в среде оберона, поломаетесь, придется лезть в компилер и среду исполнения, вот это убогость среды

Это гнусная лжа. :-) Не придётся лезть не в среду, ни в компилер. И вот почему.

Дело в том, что средства, достаточные для реализации dependency injection введены в первый Оберон (не только в систему, а в язык) около 25 лет назад, заметьте, когда не было ещё никаких яв с дотнетами. В Си и Паскале их тоже можно достичь, но только статически (путём использования указателей на процедуры/функции) или же средствами вышележащей среды исполнения - такими механизмами как динамические библиотеки, которые не являются частью языков Си и Паскаль, хотя и к Си, и Паскалю (Дельфи) они были прикручены потом навесными средствами; а такая докрутка влияет не самым положительным образом на сбалансированность средств языка и является костылём, который вам уже настолько примелькался, господа, что вы его не замечаете и считаете незаменимым средством в вашей работе.

Оберон весь состоит из подпорок недоделанных

Такое резкое высказывание неплохо бы проаргументировать несколькими примерами. В отношении Си и Паскаля - вот это чистейшего вида подпорки в языке:

extern "C" __declspec(dllexport)  error WINAPI roseInit(const HWND hWnd);

или:

function RasSetEntryPropertiesW(lpszPhonebook, szEntry: PWideChar; lpbEntry: Pointer): Longint; stdcall; external 'rasapi32.dll' name 'RasSetEntryPropertiesW';

И Дельфи, и Си на сегодняшний день состоят из таких подпорок, но вот Оберон - совсем другое дело. Разумеется, в некоторых реализациях Оберона есть и [stdcall], но это не часть языка, а системное средство, широкое использование которого по всему коду ограничено (и это благо) - его можно использовать в системных модулях для связки с готовыми библиотеками. Но вернёмся к dependency injection. Перво-наперво я перепутал его с code injection который безусловно достижим в Оберон-среде.

Но после того как нам милостиво объяснили что это такое и мы поняли:

Вместо прямого вызова каких-либо функций из кода зовутся функции посредника. А вот этот посредник (точнее, разные его реализации), уже и выполняет деятельность.
Например, ты пишешь выводилку списка файлов. Только если вместо прямого вызова методов библиотеки/winapi/posixapi будешь звать соответствующие методы посредника (обладающего специализированным протоколом, удобным для использования именно этой выводилке), то получится изоляция алгоритма (вывод списка файлов) от способа получения входных данных. И один и тот же кусок кода
у тебя используется и для перечисления файлов в папке и для перечисления файлов в архиве- ему пофиг на разницу если предоставляемый посредник соблюдает установленный протокол обмена.
В общем, полиморфизм во весь рост.

Это называется "мы придумали велосипед потому что плохо учили матчасть, но зато назвали его умным словом". И заметьте, Оберон, оставляя в чистоте концептуальную сторону вопроса предлагает нам решение, которое не требует многих мегабайт дотнета и явы-рантаймов (плюс всё, что к этому прилагается в виде обязательного лицензирования своей JVM и ласковых рук мс на юзерском горле), а ограничиваясь компактным ядром Оберон-среды исполнения (в ББ оно занимает около 30 кб кода). Оставим за бортом достоинства дотнетов, вместо этого сосредоточимся на их недостатках, которые вовсе не так уж безобидны и преодолимы.

Господа, а вы в курсе, что загрузчик модулей в ББ реализован именно описанным способом? И ему по барабану откуда грузить модуль - из файла .ocf, распаковывать из EXE (реализовано) или же загружать по сети в зашифрованном виде (предусмотрены слоты для расширений подобного рода). Или почему ББ называется расширяемой и компонентной системой?

Ещё пример из ББ. Files это работа с файлами. PackedFiles устроен также, но это работа с пакованными файлами. Переключиться между работой с обычными и пакованными файлами - строчка кода. HostFiles и HostPackedFiles - реализации. Пожалуйста, добавляйте свои собственные HostFilesAtDropBox или HostFilesAtYandexDisk, если угодно.

И ББ реализован так весь. Смотрите Files и HostFiles, Dialog и HostDialog. Вообще подсистема Host - это сплошной dependency injection со всеми его рулезностями, позволяет чуть ли не ОС приложению менять на ходу. Загружать, выгружать и переключать реализации в рантайме, иметь их миллион штук; идеально для плагинов и т.д. Всё - средствами Оберон-среды исполнения без вышележащих механизмов ОС типа динамических библиотек. Но что самое важное - всё достигнуто без привлечения дополнительных концептуальных наслоений в языке. Чтобы этого достичь - пришлось добавить в Оберон не __declspec(dllexport) и stdcall, а более практичные средства проектирования каркасов больших систем - атрибуты ABSTRACT, EMPTY, LIMITED и EXTENSIBLE всё тех же записей, которые и объекты, и структуры. Так из Оберона и получился Компонентный Паскаль.

а язык в отрыве от среды это конь в ваккуме, не говоря уже о отсуствии юнит тестирования

Угу, а ещё травка зеленеет и солнышко блестит. Всмысле, я не спорю. :-)

Если средство разработки не позволяют мне убедиться что изменив код процедуры я ничего не поломал, то такое средства идет лесом, ценю личное время (это как энтузиаст)

А тебя как энтузиаста не угнетает тот факт, что твой код помрёт вместе с ms, что не за горами?

Я как энтузиаст лучше буду искать способы независимой деятельности энтузиаста. Сегодня Оберон можно транслировать как в Си и Java, так и в байт-код .NET и JVM. Завтра будут другие платформы. Где дотнет и Java будут реализованы силами третьих лиц. А если нет? Если придумают что-то более другое? Придётся переписывать весь код. А то могу рассказать грустную историю о том как я учился 3 года программить под палмы, а они взяли да и сдохли. А вот Оберон развернётся и там, и заточить все свои разработки будет достойным (и весьма возможным) делом для энтузиастов.

Примеры? Ну хотя бы вот: http://norayr.arnet.am/weblog/2010/0...fach-portieren

И юнит-тестирование не такая уж мудрая штука, чтобы быть несовместимой с Оберонами. Или это повод чтобы переориентировать всю свою разработку под крылышко одной весьма сомнительной фирмы? И доверить ей успех своего бизнеса, своей деятельности и своей жизни. Чувствуете разницу? И я бы ставил вопрос именно так, а не как "вменяемый dependency injection [ | unit-тестирование ] крутая и незаменимая штука, без неё нельзя жить, а её нету в Оберонах". Подумаешь. Придумали как эмулировать одно API средствами другого. Т.е. изобрели эмулятор. Воистину нет ничего нового под этим солнцем!

[Oleg N. Cher]

И в какой-то момент, устав от избыточной сложности, хорошо бы предпочесть искать простые решения. Это не впадание в старческий маразм (я надеюсь), а всего лишь ступенька в эволюционном развитии программиста. Я получал письма от людей, которые рассказывали мне о проектах, развалившихся под собственной сложностью, о проектах, которые просто не были закончены. Дело здесь не только в объёмах работы и её организации. Отчасти, проблема в том, что один человек уже не то что не может отслеживать в одной голове все детали проекта, а просто берётся за голову как свести несводимое, грозящее рухнуть под собственным весом как Колосс на глиняных ногах.

Также я получал письма от людей, которые сделали большие коммерческие проекты на Обероне силами маленьких коллективов. Реализовали поддержку нужных им платформ и фич, взяв за базис систему ETH Oberon. Поскольку проекты их коммерческие - они вовсе не торопятся делиться своими решениями, т.к. затратили на это свои личные средства и ресурсы. Возможно, проблема Оберона ещё и в том, что для него нету мощной поддержки платформы (примерно как AppStore). Но рано или поздно должно появиться стойкое неприятие избыточной сложности. Да, поиск простых решений безусловно требует нетривиального подхода, и сложность такого поиска отнюдь не сопоставима с написанием очередного калькулятора для бизнеса. Но искать такие решения нужно, потому что у нас перед носом который-то на очереди кризис п/о. А знаете как звучит один из базовых тезисов Вирта в отношении современного состояния информатики? "Мощность железа растёт меньшими темпами, чем замедляется софт". И это не голословное высказывание мэтра Вирта, оно весьма подкреплено фактами.

Вам, господа, нужно знать что есть некоторое количество весьма умных людей, которые предпочитают минимальный подход Оберона. То, что их мало не должно вас смущать. Причины этого уже неоднократно анализировались. Оберон сейчас в неблагоприятной конкуренции с другими средствами (ему просто не находится место в умах программистов, оно вытеснено другими средствами), поэтому его развитие сейчас происходит замедленными темпами, поэтому, например, нету юнит-тестирования. Или может быть есть. Я не знаю. Но это вовсе не из позиции, что оно неполезно. Просто не хватает сил потянуть всё сразу. А тут пришёл чел, поковырял среду 15 минут (или попытался открыть бинарь в блокноте) и поставил вечный диагноз. У меня тут книжица лежит "Разработка операционной системы и компилятора. Проект Оберон", выпущенная в ДМК пресс тиражом в 200 экземпляров. Раритет практически. Думаете неинтересная? Да уж поинтереснее сишарпов для чайников за 21 день, поверьте на слово. Какие тут могут быть вопросы по развитию Оберона, если программерское сообщество в массе своей охотно купается в избыточной сложности, ест с неё хлеб, орудует ею и не видит других путей вообще никак. Собственно, есть и подход "Я не верю в простое решение сложных задач. Сложные задачи требуют сложных средств" (Жан Ишбиа, автор языка Ада). И можно поспорить, существует ли вообще простое решение. А кто-то, устав от гонки в никуда, просто уходит из программирования вообще.

А то тут говорили много хороших слов про язык Си. Да, прекрасная затея, пользуемся. Но багрепортим. Не доверяется как-то продукту, который не был бы вылизан десятками умных голов и сотнями бетатестеров за годы и годы. Где здесь есть ниша для простого подхода? А если надо заточить кодогенерацию под другой проц? Уже надо переписать тысячи строк кода, и снова бетатестирование и прочее. Оберон-компиляторы, как правило, дают не очень хороший код. Их просто не вылизывают до такой степени, это требует лет и лет. Но зато заточить под новый кодогенератор проще. Это не оправдание компиляторов Оберона. Это не повод делать плохие сишные компилеры. Это пример того как, пожертвовав избыточной сложностью, получить одни достоинства за счёт отказа от других. Это повод искать как упростить сам подход к кодогенерации. Например, разработкой оптимизированных под это дело железных процессоров. Чтобы не пришлось по-комсомольски героически решать ненужные задачи. А кто построил плохие процессоры? Дяди, которым надо было делать быстрые деньги. И потом тогда никто не знал как лучше проектировать процессоры. Но теперь ведь знают. Но продолжают городить thumb поверх arm, и закончится это тем самым, до чего дошла архитектура i8086. Т.е. избыточностью, рудиментарностью и т.п. Но прощаем. Арму прощаем, он ещё молод. Оберону прощаем, он всё ещё так мал. Сишарпу не прощаем, ему двигаться почти некуда. Не будет надмножеств сишарпа, как есть C++ и Objective C над Си. Не будет никогда и универсальности. Не будет и энтузиастов, которые возьмутся облагораживать этот язык просто за то, что он хорош. Неподъёмное дело.

Избыточная концептуальная перегруженность (в т.ч. и в языках программирования) воспринимается совершенно с младенческим восторгом. Слышь, во что за штука такая, да! Улёт! Но я могу легко объяснить своей племяннице что такое модуль, но затрудняюсь ей объяснить что такое сборка (коллекция классов), экземпляры классов и прочие This. И это только маленький пример того, как наслоение таких моментов на бедный ум девелопера приводит к появлению клана избранных-очень умных-элитных, куда простым смертным зась, а как второе - к появлению кучи глючащего и странно работающего софта, ошибки в котором скрыты годами и пылью лет. И какие бы решения не предлагала промышленность - чаще они уводят от сути или незавуалированно являются теми же яйцами в профиль, но под другим "фирменным" соусом, т.е. практическое средство конкурентной борьбы за умы. И появляется догма "Нет синтаксиса, удобнее сишного, и C# пророк его...", которая на ура хавается благодарным сообществом из-за новых (хорошо забытых старых) плюшек.

И в то же время в Оберон-среде можно найти аналог (или по крайней мере разработать) любой из фирменных плюшек. Как языковых, так и среды.

Не останавливайтесь на сказанных мной словах, я могу иметь понимание, но быть в затруднении передать его программистам, которые с молоком матери всосали Си [C++, C#, Java, Python и т.д.]-парадигму со всеми её достоинствами и недостатками. И если о достоинствах принято кричать на все углах, то мы с вами как честные люди должны поднять вопрос об их недостатках, не ограничиваясь тёплым и уютным кружком задач, с которых мы едим свой кусок хлебца.

Я наверно повторюсь, но как-то больше веры людям, разработавшим за год или пару лет язык, компилятор и ОС, а не к поддержаторам-калькуляторов-на-плаву. Пусть такая формулировка даже кого-то задевает. В мире, полном конкуренции, предполагается конкурентная борьба, а она закономерно стимулирует чувство соперничества. Но если мы сейчас опустимся до пиписек, то диалог наш будет происходить малость неконструктивно и на эмоциях. Впрочем, кому-то - решать уютные задачи по калькуляторам. Но это не значит, что так могут жить (и работать) все.

и кто то учит нас модульности...

Но если как бы понимаешь что такое модульность в Обероне - откуда такие восторги по поводу dependency injection? Которая реализуема с помощью этой модульности аж на ура и безо всяких усилий, т.к. прямо поощряется идеологией Оберона.

И даже более того - данная возможность была заложена неодобряемым вами г-ном Виртом в ОС Оберон ~25 лет назад! Ещё задолго до появления таких монстров как .NET и Java.

И еще Вирт кричит на каждом углу что отладка жесть и для ламерюг (при этом ничего кроме трапа не предоставил), а у самого компилер умеет INT3 ставить после каждой строки сырка и дебаг информацию собирает но никуда не пишет, вот так...

Вирт просто пытается искать и утверждать новые подходы к отладке, что ему простительно как опытному профессору. Он говорит "я бы пошагово сборщик мусора не отладил". А ты бы отладил? И многопоточные риэлтаймовые программы тоже? С учётом всех взаимовлияний и зависимостей?

А INT3 такие могут быть полезны не только для отладки, но и для многих других применений, например, для профилирования кода.

а прозвучало это так, как будто вы тут один что-то делаете, а остальные вообще здесь лишние

Может быть я просто хочу бурной и активной публичной коллективной деятельности по облагораживанию Спектрума. Во оптимист, да?

P.S. Ответил сегодня сколько успел, буду отвечать позже, если не утону в мессагах.

[Vitamin]

Так что если уж перефразировать твоё "на дождался", то как минимум в "не больно-то и хотелось", согласен?

Ага. Очевидно, что тебе не очень-то и хотелось, но все же сделал. Нет проблем.

Такое резкое высказывание неплохо бы проаргументировать несколькими примерами. В отношении Си и Паскаля - вот это чистейшего вида подпорки в языке:

А как в оберонах выглядит объявление функции-колбека, который отдается в дебря системы (например, winapi)?

Это называется "мы придумали велосипед потому что плохо учили матчасть, но зато назвали его умным словом". И заметьте, Оберон, оставляя в чистоте концептуальную сторону вопроса предлагает нам решение, которое не требует многих мегабайт дотнета и явы-рантаймов (плюс всё, что к этому прилагается в виде обязательного лицензирования своей JVM и ласковых рук мс на юзерском горле), а ограничиваясь компактным ядром Оберон-среды исполнения (в ББ оно занимает около 30 кб кода). Оставим за бортом достоинства дотнетов, вместо этого сосредоточимся на их недостатках, которые вовсе не так уж безобидны и преодолимы.

Куча оффтопа ниочем. Пруф на обязательное лицензирование JVM пожалста.

Ещё пример из ББ. Files это работа с файлами. PackedFiles устроен также, но это работа с пакованными файлами. Переключиться между работой с обычными и пакованными файлами - строчка кода. HostFiles и HostPackedFiles - реализации. Пожалуйста, добавляйте свои собственные HostFilesAtDropBox или HostFilesAtYandexDisk, если угодно.

У HostFiles/HostPackedFiles есть общее описание интерфейса, которое можно использовать при написании кода, в который позже можно передать ссылку на конкретную реализацию? Или переключение делается сменой подключаемого модуля на этапе сборки?

Почитал статьи на тему модульности. Абсолютно непонятно чем обероновская модульность лучше оной в яве, например.
В С/С++ как языках более низкого уровня нежели оберон, модульность слабее, но все плюшки прекрасно реализуются. И плагинизация и динамическое подключение и т.п.

[Oleg N. Cher]

Ага. Очевидно, что тебе не очень-то и хотелось, но все же сделал. Нет проблем.

Конечно, сам-то я без этого прекрасно обходился. Но и когда заюзал, тоже понравилось.

А как в оберонах выглядит объявление функции-колбека, который отдается в дебря системы (например, winapi)?

Так же как и объявление обычной функции. Потом можно присвоить эту функцию указателю на функцию того же типа и передать куда угодно, или, если это метод, передать ссылку на объект, или же взять прямо низкоуровневый адрес использованием SYSTEM.ADR(Fn)

Пруф на обязательное лицензирование JVM пожалста.

Это ты сам ищи, я в яве не контингент, просто краем уха слышал.

У HostFiles/HostPackedFiles есть общее описание интерфейса, которое можно использовать при написании кода, в который позже можно передать ссылку на конкретную реализацию?

Так можно. Интерфейс описан в Files. HostFiles - это одна из реализаций, которая вставлена в слот как дефолтная.

Или переключение делается сменой подключаемого модуля на этапе сборки?

И так тоже можно. Навскидку - для статической компиляции набора модулей с упаковыванием их в отдельный EXE, который будет использоваться без Оберон-среды.

Почитал статьи на тему модульности. Абсолютно непонятно чем обероновская модульность лучше оной в яве, например. В С/С++ как языках более низкого уровня нежели оберон, модульность слабее, но все плюшки прекрасно реализуются. И плагинизация и динамическое подключение и т.п.

Да, но какими средствами? И потом, ты давно багрепортил баги в багтрекер SDCC? Я - недавно. Значит опять скатываемся к хорошо вылизанному продукту десятка лет и сотен тысяч баксов? Который будет развиваться именно так, как надо _им_, или даже не развиваться, а "развиваться". Кроме того, что в Си слабее модульность, там ещё и приходится пользоваться средствами ОС, плодя непереносимости или же костыли на подпорках с макропроцессором. Если говорить о Java, то там модульность через призму ООП, что сбивает с толку и заставляет вырезать аппендикс через гланды.

Объясни, пожалуйста, зачем я здесь должен распинаться, особенно с учётом того, что ты не хочешь сам ничего читать и пробовать, а хочешь чтобы всё разжевали и в ротик положили?

---------- Post added at 18:16 ---------- Previous post was at 17:24 ----------

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

И того же понимания хотелось бы в ответ.

[Vitamin]

Так же как и объявление обычной функции. Потом можно присвоить эту функцию указателю на функцию того же типа и передать куда угодно, или, если это метод, передать ссылку на объект, или же взять прямо низкоуровневый адрес использованием SYSTEM.ADR(Fn)

А как быть с разными стандартами на передачу параметров/очистку стека (то, для чего нужны всякие там stdcall и прочая)?

Это ты сам ищи, я в яве не контингент, просто краем уха слышал.

Круто, чо. Краем уха слышал, зато написал кучу гневных постов.

Так можно. Интерфейс описан в Files. HostFiles - это одна из реализаций, которая вставлена в слот как дефолтная.

Т.е. можно ли писать чтото вроде:
procedure MyFunc(files : Files)
{
files.List();
...
}

И в одной и той же программе вызвать
MyFunc(HostFiles);
и
MyFunc(PackedFiles);
?

Да, но какими средствами? И потом, ты давно багрепортил баги в багтрекер SDCC? Я - недавно. Значит опять скатываемся к хорошо вылизанному продукту десятка лет и сотен тысяч баксов? Который будет развиваться именно так, как надо _им_, или даже не развиваться, а "развиваться". Кроме того, что в Си слабее модульность, там ещё и приходится пользоваться средствами ОС, плодя непереносимости или же костыли на подпорках с макропроцессором.

Я же сразу сказал- С/С++ находится на более низком уровне, нежели оберон. А это значит может делать все, что могут языки более высокого уровня, но многословнее. Равно как и на ассемблере можно тоже сделать все, что на С/С++, но еще многословнее.

Объясни, пожалуйста, зачем я здесь должен распинаться, особенно с учётом того, что ты не хочешь сам ничего читать и пробовать, а хочешь чтобы всё разжевали и в ротик положили?

Я прочитал то, что ты дал и задал вопрос. В ответ- батхерт в стиле "не знаю что это такое, но оно хуже".

А мне просто интересно все, что касается программирования.

[Oleg N. Cher]

Глубокоуважаемые вагоновожатые господа сишники, хочу испросить вашего совета.

У меня в подсистеме XDev/WinDev есть модуль Console, и в его сишной реализации XDev/WinDev/Lib/Console.c используется такой код:

#if defined(WIN32) || defined(_WIN32)
#  include <windows.h>
#endif

#include "Console.h"
#include "SYSTEM.h"

Он прекрасно компилируется, но если его изменить на:

#include "SYSTEM.h"
#include "Console.h"

#if defined(WIN32) || defined(_WIN32)
#  include <windows.h>
#endif

начинаются самые непонятные глюки:

Console.c:17: error: incompatible types for redefinition of 'Console_WriteStrLn_WinAPI'

Компилить лучше всего конечно в самой XDev, для этого качаем её из репа, запускаем BlackBox.exe и открываем WinDev/Lib/Mod/Console.Mod (выберем тип файла Oberon module (*.Mod)) и компилим F11. Как всё это устроено - даёт понять батник WinDev/Lib/Bin/compile.bat, вызываемый с параметром-имя файла:

\XDev\WinDev\Lib\Bin\> compile.bat Console

А то в Обероне я привык перечислять в секции импорта модули в любом порядке, и считаю это удобным.

Это к вопросу о том, что Си ну вот нисколечко ещё не протух на сегодняшнее время. И дизайн в нём прекрасный, и всё прозрачно. А для больших программных систем - так вообще не жисть, а рай сущий.

Спасибо!

P.S. Вообще-то работает и без этого, но блесните мудростью, просветите народ, в чём тут пень. В целях повышения всеобщей образованности, тыкскыть.

[ZEK]

Это гнусная лжа. :-) Не придётся лезть не в среду, ни в компилер. И вот почему.

Еще раз читаем что такое IoC/DI до просветления

каким образом по запрашиваемому контракту найдет необходимый модуль (множество модулей удовлетворяющих контракту), иницициализирует переменные ссылками итд, т.е. как будет работать Service locator (паттерн такой)

Это называется "мы придумали велосипед потому что плохо учили матчасть, но зато назвали его умным словом"

это ты конкретную реализацию примера зацепился

Я к примеру помню как в бутылке мега модно расширяется менюха, в ББ не помню как (вроде как тоже таким караличем), надо ручками в конфиг файл лезть и прописывать информацию о расположении, наименовании и обработчике менюхи

А так по нормальному вы объявляли бы к примеру какой нить интерфейс для работы менюшек, среда при запуске сканировала окружение (Service Locator) находила все модули в которых надо смыкнуть функцию для получения описания пункта меню и обработчика, заполнила бы ссылками на эти процедуры какую нить коллекцию потребителя этих контрактов (иньекция зависимостей) и без каких либо напрягов, к примеру добавил новый модуль, у которого есть реализация контракта для добавления менюхи, система его автоматом подхватит

И вот тут самое главное: не будет возникать рассинхронизации между метаданными менюхи и кодом, а так код надо поправить, потом в ресурсы лезть и прописывать там менюху, а у вас в результате рефакторинга выкинул один обработчик за ненадобностью, другому дали имя более вменяемое и все, свалилось все

что твой код помрёт вместе с ms, что не за горами?

код на дельфи не помер со смерью борланд, до сих пор могу спокойно откомпилить
Темболее средства тестирования есть далеко не только от MS, куча вариантов свободных Unit тестирование это не кнопка от MS, а методолгия придуманная одними энтузиастами и принятая на вооружение в том числе и проф. разработчиками

И по поводу дров на С#
ATA http://cosmos.codeplex.com/SourceCon...ardware/ATA.cs
PCI Bus http://cosmos.codeplex.com/SourceCon...ware/PCIBus.cs