В i4040 были добавлены операторы OR и AND, и еще несколько регистров, а так же расширили стек в 2 раза, и в двое увеличили максимальный размер программы (до 8кб) в остальном он даже совместим с i4004
в целом интересная архитектура процессора, хоть особо сейчас и не применима.
то операция разворота списка превратится в простой обмен значениями в следующих парах:
prev <-> next
last <-> first
Честно, всегда так и делал разворот связных списков, зачем отъедать больше памяти, и усложнять понимание происходящего?
Или что-то вам мешает пройтись один раз по всем элементам списка и поменять местами указатели местами, а в конце поменять указатели на первый и последний элемент списка?
Че-то я не пойму зачем для этого связный список превращать в обычный массив.
В моем понимании алгоритм выглядит примерно так (сейчас на скорую руку набросал, тут по хорошему еще проверки правильности указателей должны быть, что бы не обращаться к ложно указанной памяти, но если список пра):
node moveNodeLinks(node Position){ // next <-> prev
node *temp;
temp = Position*.next;
Position*.next = Position*.prev;
Position*.prev = temp;
return temp;
}
void reverse(node &first, node &last){
node *position = first;
// for( position = first; position < last; position = position.next)
while(position != last)
position = moveNodeLinks( position );
// так как последний элемент не меняем в цикле, делаем это после цикла
moveNodeLinks( position );
// first <-> last
position = first;
first= last;
last= position;
}
Вот, что-что, а PascalABC вообще к паскалю только внешней схожестью относиться, работает совершенно иначе, вдобавок имеет намешку от .NET, и совершенно не годиться для написания чего-то серьезного. А еще много чего на нем работает не так как должно. Приходилось как-то помогать писать студенческое приложение для решения простенькой задачи, написал за минут 10, проверел в нормальной среде (для Lazarus и Delphi этот код работал без проблем, более того этот код работал бы и на TurboPascal), но как выяснилось этот код был совершенно неработоспособен в PascalABC, пришлось ставить это чудо и смотреть, что же ему не нравилось, после целого дня возни и экспериментов, выяснилось, что он иначе строит структуру строк, и если дополнительно не приклеивать некоторые символы в конце, то стандартные методы WRITELN начинали падать, как и странно работал READLN, захватывая в строку лишние символы. Возможно с того времени это уже исправили, но все равно многие вещи которым обучают на нем, работают только на нем.
Лучше уж на Lazarus, так же бесплатно и современно, и без лишних примесей, и кроссплатформенно, и вполне можно писать что-то серьезное, начиная от простых десктопных программ, полноценных игр, и заканчивая многопроцессорными комплексными приложениями, или приложениями с высокой нагрузкой и сложной структурой данных.
И все это так же из коробки после установки.
При желании даже CGI-приложения можно легко написать, или мобильное приложение создать (хотя это немного сложнее, так как требует отдельной возни с компилятором).
Глюки версия от версии исправляются, особенно если люди о них сообщают сообществу лазаруса, или сами пишут "патч" и опять таки предлагают его внести сообществу лазаруса.
А вот что мне действительно не хватает в нем, так это такого же мощного отладчика, который был в Delphi.
Его как-то почти не развивают, и если код по нему смотреть еще вполне можно, и текущие данные в переменных, то в сложном многоуровневом дереве структур данных он уже сильно уступает отладчику в Delphi. (например данные вроде: variable: record a:array of record sa: array of record ssa:array of class; end; end;end; То проверяя variable в отладчике Lazarus будет сложно посмотреть что же все таки хранится в данный момент в variable.sa[0].ssa[0].class)
Если вы используете только стандартные оконные компоненты (заметьте что речь идет не о классах вроде TList, а именно о таких компонентах вроде TEdit, TMemo), и не используете специфичный синтаксис языка Delphi (а в Delphi 7 такого сахара отличного от стандарта синтаксиса FreePascal практически нет), то код будет полностью совместимым.
Если же вы используете манипуляцию со стоками (речь идет о кириллице в Ansi), то вместо String надо будет просто указать AnsiString, и тогда тоже никаких проблем не возникнет.
Более того вы сможете скомпилировать приложение под 64-бита и даже на linux, а при желании и на MaсOS.
Delphi 8 это версия Delphi 7 но с компиляцией под .NET платформу, естественно там многое несовместимо стало, тот же тип variant был чисто формально, так как работал совершенно по другому.
И к смерти Delphi это не привело, только к банкротству Borland, но исходники были выкуплены другой студией и развиваются по сей день.
Однако следующие владельцы отказались от этой версии, и продолжили развитие исходников Delphi 7, и совместимость кода практически полностью сохранена, там разве что внутренности record превратили в object, а object в обрезанный class, который самоинициализировался, не требуя ручного создания и удаления. При переходе с Delphi 7 на Delphi 2006 ничего даже не приходилось переписывать, все работало сразу, отличия были только в некоторых ухищрениях, коими я пользовался исключительно для решения задач на саморазвитие вроде "можно ли обмануть компилятор", но такой код никогда и нельзя применять в серьезных проектах.
После Delphi 2010 ситуацию не знаю, помню на нем изменили базовую кодировку, а так как я уже не работал в той компании, где проекты писались на Delphi 2006, а они не планировали переход хотя бы на Delphi 2010, то мне пришлось отказаться от сопровождения одного проекта, даже за неплохие в то время деньги. (п.с. покупать более старую версию, или искать в инете крякнутую, ради возможности продолжать раз в год дополнять новыми шаблонами код, не имело смысла, а переписывать код под новую версию, мне сказали так не делать).
В то же время разработчики Delphi XE заверяли в свое время о полной совместимости старого кода вплоть до Delphi7 и мертвого Kylix, на практике не проверял.
Зато с Lazarus почти полная совместимость кода, даже до сих пор есть режим Delphi 7, который как раз должен помочь безболезненно перенести весь код без изменения (ну разве что в начале модуля добавить надо будет директивы компилятора, которые будут указывать на код D7). Или есть встроенный инструмент преобразования кода Delphi на Lazarus, правда насколько хорошо он работает я не знаю, никогда им не пользовался.
Но и без этих как по мне костылей, как уже было написано выше 90% кода (а то и больше) будет работать без изменения, а небольшая разница легко заменяется аналогами, если не требуется какой-то специфики, выходящей за рамки стандартов (и тут идет речь о самом синтаксисе ЯП и некоторыми классами для оконных компонентов, а не алгоритмов каких-то вычислений).
Один только нюанс, в какой-то момент сообщество Lazarus по умолчанию String прировняли к UTF8String (что вполне логично, так как это давно стало стандартом почти для всех современных ЯП), потому для полной совместимости, если использовались манипуляции с текстом вроде подмены символов, для совместимости необходимо было указать вместо string тип AnsiString. Что занимает несколько минут работы, учитывая что в среде есть поиск по проекту с автозаметой.
В i4040 были добавлены операторы OR и AND, и еще несколько регистров, а так же расширили стек в 2 раза, и в двое увеличили максимальный размер программы (до 8кб)
в остальном он даже совместим с i4004
в целом интересная архитектура процессора, хоть особо сейчас и не применима.
Честно, всегда так и делал разворот связных списков, зачем отъедать больше памяти, и усложнять понимание происходящего?
Или что-то вам мешает пройтись один раз по всем элементам списка и поменять местами указатели местами, а в конце поменять указатели на первый и последний элемент списка?
Че-то я не пойму зачем для этого связный список превращать в обычный массив.
В моем понимании алгоритм выглядит примерно так (сейчас на скорую руку набросал, тут по хорошему еще проверки правильности указателей должны быть, что бы не обращаться к ложно указанной памяти, но если список пра):
Вот, что-что, а PascalABC вообще к паскалю только внешней схожестью относиться, работает совершенно иначе, вдобавок имеет намешку от .NET, и совершенно не годиться для написания чего-то серьезного.
А еще много чего на нем работает не так как должно. Приходилось как-то помогать писать студенческое приложение для решения простенькой задачи, написал за минут 10, проверел в нормальной среде (для Lazarus и Delphi этот код работал без проблем, более того этот код работал бы и на TurboPascal), но как выяснилось этот код был совершенно неработоспособен в PascalABC, пришлось ставить это чудо и смотреть, что же ему не нравилось, после целого дня возни и экспериментов, выяснилось, что он иначе строит структуру строк, и если дополнительно не приклеивать некоторые символы в конце, то стандартные методы WRITELN начинали падать, как и странно работал READLN, захватывая в строку лишние символы. Возможно с того времени это уже исправили, но все равно многие вещи которым обучают на нем, работают только на нем.
Лучше уж на Lazarus, так же бесплатно и современно, и без лишних примесей, и кроссплатформенно, и вполне можно писать что-то серьезное, начиная от простых десктопных программ, полноценных игр, и заканчивая многопроцессорными комплексными приложениями, или приложениями с высокой нагрузкой и сложной структурой данных.
И все это так же из коробки после установки.
При желании даже CGI-приложения можно легко написать, или мобильное приложение создать (хотя это немного сложнее, так как требует отдельной возни с компилятором).
Глюки версия от версии исправляются, особенно если люди о них сообщают сообществу лазаруса, или сами пишут "патч" и опять таки предлагают его внести сообществу лазаруса.
А вот что мне действительно не хватает в нем, так это такого же мощного отладчика, который был в Delphi.
Его как-то почти не развивают, и если код по нему смотреть еще вполне можно, и текущие данные в переменных, то в сложном многоуровневом дереве структур данных он уже сильно уступает отладчику в Delphi.
(например данные вроде:
variable: record a:array of record sa: array of record ssa:array of class; end; end;end;
То проверяя variable в отладчике Lazarus будет сложно посмотреть что же все таки хранится в данный момент в variable.sa[0].ssa[0].class)
Если вы используете только стандартные оконные компоненты (заметьте что речь идет не о классах вроде TList, а именно о таких компонентах вроде TEdit, TMemo), и не используете специфичный синтаксис языка Delphi (а в Delphi 7 такого сахара отличного от стандарта синтаксиса FreePascal практически нет), то код будет полностью совместимым.
Если же вы используете манипуляцию со стоками (речь идет о кириллице в Ansi), то вместо String надо будет просто указать AnsiString, и тогда тоже никаких проблем не возникнет.
Более того вы сможете скомпилировать приложение под 64-бита и даже на linux, а при желании и на MaсOS.
Пляски начинаются только если вы используете что-то выходящее за вышеописанное, но и тут не проблема, есть встроенный инструмент преобразования кода Delphi в код Lazarus, вот тут вроде неплохо описан этот процесс:
https://delphi-devs.ru/index.php/portirovanie-proekta-s-lazarus-na-delphi.html
Delphi 8 это версия Delphi 7 но с компиляцией под .NET платформу, естественно там многое несовместимо стало, тот же тип variant был чисто формально, так как работал совершенно по другому.
И к смерти Delphi это не привело, только к банкротству Borland, но исходники были выкуплены другой студией и развиваются по сей день.
Однако следующие владельцы отказались от этой версии, и продолжили развитие исходников Delphi 7, и совместимость кода практически полностью сохранена, там разве что внутренности record превратили в object, а object в обрезанный class, который самоинициализировался, не требуя ручного создания и удаления. При переходе с Delphi 7 на Delphi 2006 ничего даже не приходилось переписывать, все работало сразу, отличия были только в некоторых ухищрениях, коими я пользовался исключительно для решения задач на саморазвитие вроде "можно ли обмануть компилятор", но такой код никогда и нельзя применять в серьезных проектах.
После Delphi 2010 ситуацию не знаю, помню на нем изменили базовую кодировку, а так как я уже не работал в той компании, где проекты писались на Delphi 2006, а они не планировали переход хотя бы на Delphi 2010, то мне пришлось отказаться от сопровождения одного проекта, даже за неплохие в то время деньги. (п.с. покупать более старую версию, или искать в инете крякнутую, ради возможности продолжать раз в год дополнять новыми шаблонами код, не имело смысла, а переписывать код под новую версию, мне сказали так не делать).
В то же время разработчики Delphi XE заверяли в свое время о полной совместимости старого кода вплоть до Delphi7 и мертвого Kylix, на практике не проверял.
Зато с Lazarus почти полная совместимость кода, даже до сих пор есть режим Delphi 7, который как раз должен помочь безболезненно перенести весь код без изменения (ну разве что в начале модуля добавить надо будет директивы компилятора, которые будут указывать на код D7). Или есть встроенный инструмент преобразования кода Delphi на Lazarus, правда насколько хорошо он работает я не знаю, никогда им не пользовался.
Но и без этих как по мне костылей, как уже было написано выше 90% кода (а то и больше) будет работать без изменения, а небольшая разница легко заменяется аналогами, если не требуется какой-то специфики, выходящей за рамки стандартов (и тут идет речь о самом синтаксисе ЯП и некоторыми классами для оконных компонентов, а не алгоритмов каких-то вычислений).
Один только нюанс, в какой-то момент сообщество Lazarus по умолчанию String прировняли к UTF8String (что вполне логично, так как это давно стало стандартом почти для всех современных ЯП), потому для полной совместимости, если использовались манипуляции с текстом вроде подмены символов, для совместимости необходимо было указать вместо string тип AnsiString.
Что занимает несколько минут работы, учитывая что в среде есть поиск по проекту с автозаметой.
после 11 вопроса переходить дальше на 12 не хочет, и тест завершить нельзя, так и задумано?)
очень интересная залипаловка, продолжайте ее развивать)
А я вот читал, где-то прошлым летом (2017 года), что плутону вернули статус планеты, после получения новых данных о нем.