Сравнение двух стилей программирования

[Chifu]

shau-kote в сообщении #658885 писал(а):

А чем Ваш вариант лучше тех, что были в этом треде ранее?
Тем, что обращается из подпрограммы к глобальным переменным?

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

[Pavia]

Цитата:

Элемент списка присоединяется к списку (в вершину) одной процедурой. Меньше лишних телодвижений. :) Поскольку указатель на вершину списка глобальный и один, то естесственно список один, что не выходит за пределы задачи. Если нужны ещё списки, то заводим ещё (глобальные)

Глобальные переменные дурной стиль.

[Chifu]

Pavia в сообщении #658940 писал(а):

Глобальные переменные дурной стиль.

Ну ладно, тогда procedure make (var top, lst : lst_ptr); Ещё что исправить?

[Munin]

shau-kote в сообщении #658734 писал(а):

Процедура AddElement() добавляет в список-очередь новый элемент и помещает в него данные.
Соответственно, довольно очевидно, что она должна получать на вход собственно "данные" (число в данном случае) и указатель на конец списка.

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

[Pavia]

{ Создание нового узла списка }
По английски создание это Create или Generate.
А "make" - это "выполнить". Так что лучше переименовать в ElementCreate или ItemCreate, а то не понятно, что делает процедура.

Во вторых ReadLn тут не место.
1. Основная логика программы должна быть отделена от внутренней структуры.
2. Во вторых логически семантически тут ей не место. Так как мы создаем, а не читаем.

Цитата:

shau-kote к сожелению, список может быть зациклен не на стартовый элемент. Например 1->2->3->2->3->2->3->...

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

Цитата:

Процедура AddElement() добавляет в список-очередь новый элемент и помещает в него данные.
Соответственно, довольно очевидно, что она должна получать на вход собственно "данные" (число в данном случае) и указатель на конец списка.

То что она должна получать указатель на конец списка не очевидно. Очевидно что она должна получать список на входе. Для структурирования надо чтобы остальная часть не знала о конце или начале списка. Иначе это не структура, а чёрти что. И ошибок не избежать.

Лучше предусмотреть защиту от дурака и не надеяться на то что он правильно передаст конец списка. И если мы будем передавать список и сами внутри процедуры определять конец списка(к примеру читать из структуры списка), то это будет лучше.
А вот с тем что не требуется проверка конца согласен.

[shau-kote]

Munin в сообщении #658978 писал(а):

должно было быть не меньше полстраницы текста.

А при добавленной обработке всех возможных неприятных ситуаций и их описания будет страницы три?
Синтаксис и примеры использования есть в начале треда. (:
А необходимые предусловия очевидны - памяти должно хватать, типы очевидны, и т.д.

Pavia в сообщении #659212 писал(а):

То что она должна получать указатель на конец списка не очевидно. Очевидно что она должна получать список на входе. Для структурирования надо чтобы остальная часть не знала о конце или начале списка. Иначе это не структура, а чёрти что. И ошибок не избежать.

Лучше предусмотреть защиту от дурака и не надеяться на то что он правильно передаст конец списка. И если мы будем передавать список и сами внутри процедуры определять конец списка(к примеру читать из структуры списка), то это будет лучше.

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

-- 16.12.2012, 17:29 --

Pavia в сообщении #659212 писал(а):

Не может он быть таким. Иначе это нарушение семантики. И надо называть не списком, а графом.

Вот да, я как-то тоже думаю, что у собственно спискам такая структура будет иметь весьма отдалённое отношение.

[Munin]

shau-kote в сообщении #659226 писал(а):

А необходимые предусловия очевидны - памяти должно хватать, типы очевидны, и т.д.

Вот с такими замашками никогда вам не достичь привычек по написанию хорошего кода.

[shau-kote]

Munin в сообщении #659254 писал(а):

Вот с такими замашками никогда вам не достичь привычек по написанию хорошего кода.

Вы хотите сказать, что это не очевидно (не стоит считать очевидным)?

[Shadow]

Pavia, мы обсуждали другую задачу:

Shadow в сообщении #658865 писал(а):

Написать функцию, проверяющая является ли односвязанный список зацикленным. (или заканчивает на nil). Входные параметры: указатель к стартовому элементу. Структура известна.

Pavia в сообщении #659212 писал(а):

И вообще зацикленный список я бы так и называл зацикленным, а не просто списком.

Я тоже. Задача - проверить каким он является.

[shau-kote]

Shadow в сообщении #659382 писал(а):

Я тоже. Задача - проверить каким он является.

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

[Shadow]

Памяти может не хватит... если там плохой указатель.
Подсказака: Ахил и черепаха

[shau-kote]

Shadow в сообщении #659410 писал(а):

Памяти может не хватит... если там плохой указатель.

Памяти не хватит, если будет более 255 указателей. Ну, может, не памяти, но допустимого объёма массива.

Shadow в сообщении #659410 писал(а):

Подсказака: Ахил и черепаха

Ужасная подсказка, если Вы понимаете, о чём я.

[arseniiv]

Pavia в сообщении #659212 писал(а):

По английски создание это Create или Generate.
А "make" - это "выполнить".

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

[rockclimber]

shau-kote в сообщении #659396 писал(а):

Shadow в сообщении #659382 писал(а):

Я тоже. Задача - проверить каким он является.

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

Я слышал эту задачу в более жесткой формулировке. Когда нельзя использовать для хранения промежуточных данных структуры, сравнимые по размером со списком. Например, у вас список из 1000 элементов, а вам разрешается использовать 2 - 3 переменные. Тут уже говорилось еще и о том, что цикл может начинаться не с первого элемента. Например:
1->2->3->4->5->6->7->4->5->6->7
Я придумал, как решить задачу, если находишься на участке 4 - 7 (там двух-трех переменных достаточно независимо от длины цикла), а вот на участке 1 - 3 пока не знаю (не знаю, как сделать именно в жестком варианте).

-- 17.12.2012, 00:33 --

Pavia в сообщении #659212 писал(а):

{ Создание нового узла списка }
По английски создание это Create или Generate.
А "make" - это "выполнить".

make - сделать
execute - выполнить.

[shau-kote]

rockclimber в сообщении #659522 писал(а):

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

Ну можно тогда перебирать список и для каждого элемента проверять равенство со всеми предыдущими.
Но у такого алгоритма сложность будет O$(n^2)$.

-- 17.12.2012, 00:58 --

А, нет, так просто не получится. :(