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

[Andrew771]

А че писать то, код это вообще не проблема

Вот что по этому поводу пишет Вяч.Медноногов в своей эпопее про Черного Ворона:

Большой прикол в том, что наиболее трудные места пишутся сначала на Cи на РС, а потом переносятся в ассемблер (ручками, конечно). Получается быстрее и надёжнее. В следующий раз думаю целиком сначала на ИБМ состряпать, а только потом - перенести на ZX

Жаль, тогда еще не было кросс-компиляторов ЯВУ для Спектрума. А сегодня уже есть!

[jerri]

jerri знает секрет как ускорить процесс реверс-инжиниринга?

шта? Jerri знает про реверс инжинеринг очень много.
чтобы не быть голословным он даже поделится с тобой ссылкой
вот те раз
вот те два
вот те три

если кликнуть по ссылкам там будут файлы. Файлы, Карл, их сразу можно использовать. Не ссылки на форумы или картинки.

Хотя и не настолько хорошо (взять хотя бы баги моего бэк-энда - SDCC, которые приходилось править, тратя на это много времени; тоже, кстати, потеря, не связанная с Обероном, не находишь, jerri?)

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

как то так

[Oleg N. Cher]

Господа, быть может, мой подход к портированию игр вовсе и не оптимален, но когда это фанбои слушали голос разума? - они всегда действовали по велению души. Спектрум - фанская платформа.

s_kosorev, так называемые "косяки" Си - это результат общения не только с Паскалем, но с Си в первую очередь, причём общения очень плотного и тесного, сидения в отладчике, переноса кода между платформами и т.п. Как переносимый ассемблер он вполне хорош и по сей день, хотя мог бы быть и получше. Но если роль (удельный вес) в софте ассемблера с течением лет уменьшался, то сегодня людям всё в меньшей степени нужен и переносимый ассемблер. Щас вот набегут спорить, ну ладно, пусть это будет моё субъективное мнение. Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью. PHP, Perl прикрепили к интерпретатору и назвали так же. Ну пусть. Хотя мне всё равно не нравится. Людям подавай быструю разработку софта. Так что я не стал бы идеализировать язык, который никак не возбраняет накосячить в самом что ни есть прикладном куске кода. На нём будто по минам ходишь каждый свой миг, притом то же самое можно сказать и о Паскале в редакции Дельфи/FPC.

Про Оберон скажу так: он в силу концепта более безопасен. Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически. Получается managed код, притом без всяких виртуальных платформ. Это всё притом на синтаксисе Паскаля базируется. Ессно эти все возможности не про честь ZX, но тут уже что поделать. Мне нравится, господа, когда об Обероне рассуждают как о взрослом языке, который может посягнуть на место не только C++, но и C#, и всё это заслуженно. И оберонщики понимают проблемы Оберона. Посмотрите выступление Рифата на Оберон-дне 2015 (это автор компилятора Exaprog Oberon-07) - он высказал очень здравые вещи и про IDE, и про необходимость пошагового отладчика. Всё это нужно, просто делать некому. Вот так вот. s_kosorev, обязательно посмотрите, пожалуйста. Я не против навороченного IDE. Кстати, можно было бы собрать его на основе плагинов Саши Ильина. Просто мне не надо, я обхожусь БлэкБоксом. А делать впрок вдруг кому-то понадобится - это большая роскошь даже для богатых фирм.

Ещё моментик. Даже если выкинуть Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC. И в этом смысле проекту могли бы помочь любители Си, а вовсе не Оберона, однако почему-то они этого не делают. Кроме Sergey, который предложил библиотеку для работы с TR-DOS, и SfS - библиотеку для вывода спрайтов libspr, которые я адаптировал для ZXDev. Респект!

[s_kosorev]

Языки Java, C# прикрепили к платформе и назвали это кроссплатформенностью.

На самом деле в битве кросплатформенных инструментов победил js.

Нету ручного освобождения памяти. Нет возможности из прикладного кода залезть не в свою память. Вообще нельзя. Физически.

Во первых можно, во вторых сейчас таких языков много, очень много, в третьих, блокирование прямого обращения к памяти не увеличивает надежность, есть еще много разных средств/методик/технологий, повышающих надежность ПО.
У от nasa кстати java на слуху и на марс и на луну и просто полетать. А так читал где то, что nasa если не связано с полетами то использует во всю Python

Получается managed код, притом без всяких виртуальных платформ.

C#, java можно компилировать в нативный код при помощи утилит, MS уже из коробки для C# сделала нативную компиляцию, пока для UniversalApp но обещают для всего.

Оберон - ZXDev остаётся самой крупной подборкой ZX-библиотек, адаптированных для использования из SDCC.

если не ошибаюсь, на данный момент самый большой сборник библиотек это z88dk

[Vitamin]

Побуду адвокатом дьявола.

Развитый RTTI: C# да, delphi да, с++ нет

"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.

-строки, динамические динамические массивы на уровне языка: C# да, delphi да, с++ нет

Что значит "на уровне языка"? Для с++ есть std::string. Если считать, что это не в языке, а в стандартной (ключевое слово, если что) библиотеке, то для шарпа/явы строки тоже являются производными типами.

-наличие управления автоматического управления памятью: C# да, delphi местами, c++ нет

Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?

в с++ вообще строк нет

Да ну?

В с++ шаблоны compile time, т.е. хитросделаные макросы, в C# параметрический полиморфизм и ноги растут не от с++ а от какого то функционального языка, от с++ взяли синтаксис, в delphi generics есть, в с++ если в целом то нет.

А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?

[msm]

Олег, выскажу свое ИМХО по поводу Оберона.

Да, с некоторыми доводами я согласен. Но ИМХО главная проблема паскальподобных языков не в плохих IDE и не в плохих отладчиках. Самая большая проблема, которую я вижу - необходимость объявлять переменные и константы в отдельном блоке, а не максимально близко к месту использования. Чем это чревато? А чревато *****кодом, который идет сплошняком от тех, кто долго посидел на паскалеподобных языках.

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

И тому подобный копипаст идет сплошняком на паскалеподобных проектах. И самое нехорошее, что человека, который вот так привык писать - потом хрен переучишь, он такое считает нормальным. Пока это не исправят, Оберон ИМХО лучше не рассматривать вообще. Хотя я видел проект что то вроде Оберон под .NET - там в принципе все есть, вполне хороший язык. Вот только это .Net с другим синтаксисом и ничего больше.

[Advertiser]

[Bedazzle]

row[i].col[j].getPerson().getName();
row[i].col[j].getPerson().getLastName();
row[i].col[j].getPerson().getMiddleName();
row[i].col[j].getPerson().getPosition();

Это от незнания конструкции with.

[msm]

with здесь помогает, но не сильно. Во первых уровень вложенности появляется на пустом месте. А этих псевдопеременных может запросто быть штук 5 - 5 уровней вложенности на ровном месте? Или неоднократная копипаста with в пределах метода?

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

Короче, это искусственные сложности на ровном месте. Тут собственно вполне промышленные языки вроде C++, Java, C# зачастую критикуют за слишком громоздкий синтаксис.

[s_kosorev]

"Развитый" - это что именно? Ибо RTTI какбэ в C++ имеется.

хотя бы как в Qt

Что значит "на уровне языка"? Для с++ есть std::string.

Встроенный в язык тип, var s:string; public string s;

Если предположить, что "автоматическим управлением памяти" называется сборщик мусора, то где его места у delphi?

не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел

Да ну?

в языке нет, есть строковые константы

А щто, у нас определение параметрического полиморфизма уже пополнилось требованием быть сугубо runtime?

естественно

[Vitamin]

хотя бы как в Qt

Это будет нарушением одного из освновополагающих принципов С/С++ - ты не платишь за то, что не используешь.

Встроенный в язык тип, var s:string; public string s;

А разве в C#/Java он встроенный?

не сборщик, подсчет ссылок на объекты и начало процесса уничнотежения объекта когда счетчик в 0 перешел

И где такое в делфях?
В плюсах - читать про std::shared_ptr.

естественно

И где это определение? Ссылочку, пожалста.