> -- Илья Ермаков писал(а):
> 1) Вы выбрали совершенно неудачный способ передачи параметров.
согласен
хорошо, что еще не использовал его на самих парах)

> -- Илья Ермаков писал(а):
> Дискриминант - это часть внутренней реализации процедуры решения кв. ур-я - и его не следует выносить наружу! У вас интерфейсный код узнает, есть ли корни, по значению дискриминанта, а должен всего лишь получить TRUE/FALSE - есть ли корни или нет.
опять же согласен
раз процедура возвращает корни, то лишнее в ней ни к чему
если нужен дискриминант для каких-то целей, то наверно лучше отдельную процедуру-функцию выделить для нее в этом модуле
> -- Илья Ермаков писал(а):
> А если мы захотим изменить реализацию процедуры ReshKvUr - и будем вычислять корни, ну, к примеру, численным методом (пусть и маразм), без вычисления дискриминанта? Что возвращать в m[0] будем?
можно было бы возвращать -1 0 1
> -- Илья Ермаков писал(а):
> Думаю, убедил, что так нельзя.
убедили!
переделаю
> -- Илья Ермаков писал(а):
> Теперь по поводу возвращаемого значения процедуры. Ну, самое первое - если процедура имеет OUT-параметры, то возвращаемое значение ей обычно не задают. Это так называемый принцип "чистоты функций". Т.е. если пишем функцию, которую можно будет использовать в выражениях, то она не должна ничего менять ни вокруг себя, ни в своих параметрах, а только возвращать значение (как функция в математике).
понятно
сразу и остальным расскажу
если уж нужен пример с различными параметрами(по значению и по ссылке), и обычные процедуры и процедуры функции, то просто добавлю в пример процедуру-функцию вычисления дискриминанта
> -- Илья Ермаков писал(а):
> А на входе процедуры ставится проверка соблюдения этих предусловий - оператор ASSERT: для вашего случая было бы - ASSERT(LEN(m) >= 3). И все. Что произойдет, если процедуре подадут неверные данные? Попробуйте - увидите, что выскочит окошко сбоя - трепа. Все правильно - нарушение предусловия процедуры - это и есть сбой, и выполнение процедуры немедленно прерывается.
про ASSERT знаю... просто не разобрался еще как окошко трепа читать толком, поэтому хотел обойтись пока без него
да и нас раньше учили в программе учитывать возможность ошибочных данных и сообщать пользователю
привыкли сообщениями
но в принципе ASSERT тоже сообщает пользователю, только не в таком прямом виде

> -- Илья Ермаков писал(а):
> Т.е. в вашем варианте вместо возврата значения надо было бы заводить еще один OUT-параметр: OUT noErrors: BOOLEAN).Однако если мы отказались от массива, то он стал не нужен.
если a=0, то возникает опять же ошибка
получается либо ассертом a проверять(перекладываем проверку на модуль интерфейса), либо оставлять noErrors
[либо, теоретически, создавать тип REAL без нуля и требовать его на вход, если такое возможно]
> -- Илья Ермаков писал(а):
> Кстати, а можно еще вообще не возвращать явно "есть ли корни, нет ли корней". У типа REAL есть особое значение - бесконечность, неопределенность. Записывается как INF.Просто, если корней нет, то вернем x1=x2=INF.А код верхнего уровня будет проверять IF x1 # INF THEN корни есть ELSE корней нет END.
опробую обязательно!

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

второй вариант выглядит проще)
ну в данном примере мне массив уже не понадобится

> -- Илья Ермаков писал(а):
> Почитайте в Общих вопросах, там это обсуждалось.
точно
это я не досмотрел
темы такие часто встречал когда не нужны были)


> -- Илья Ермаков писал(а):
> 4) По поводу указателей.Эээ, батенька, указатели нужно изучить, без них далеко не уедешь.
хорошо, что выяснилось до того, как я дошел до ООП)

> -- Илья Ермаков писал(а):
> Ни одно реальное приложение не знает, сколько и каких переменных ему понадобится в момент выполнения.
...но ведь мы указатели все равно объявляем
т.е. предусматриваем их возможность появления
или от одного указателя можно кучу переменных объявить?...
буду разбираться)

спасибо за конструктивную критику!