Отправлено: 08.05.06 11:11. Заголовок: Ещё одно несоответствие xHarbour и Clipper

Обнаружилось ещё одно несоответствие xHarbour и Clipper: присвоение := значения в строке объявления Static переменной в xHarbour выдаёт ошибку, а в Clipper проходит на "ура".
Таким образом я отслеживаю, первый раз выполняется модуль с момента запуска программы или не первый (присвоение переменной указанного в строке объявления Static значения производится только при первом выполнении модуля).

 Отправлено: 08.05.06 11:45. Заголовок: Re:

Проверил.
Работает и в Clipper 5.2e и в Xharbour 0.99.61 !!!!!!

 Отправлено: 11.05.06 08:07. Заголовок: Re:

Dima пишет:

цитата:

Работает и в Clipper 5.2e и в Xharbour 0.99.61 !

Извиняюсь, дело оказалось в другом.
Компилирую модуль KNIGY.PRG:

Static w_instr,;
w_screen

Procedure Knigy
do Sklad with 9
return

В компиляцию автоматически (!) включается модуль SKLAD.PRG:

Static w_instr,;
w_screen

Procedure Sklad
return

В итоге ошибка:

SKLAD.prg(2) Error E0004 STATIC declaration follows executable statement

1 error

No code generated

Разговор на похожую тему уже был - дело касалось одинаковых названий Static процедур и функций, которые при подобной "общей" компиляции выдавали ошибку Error F0002 Redefinition of procedure or function (впрочем, я проверил - выдают и сейчас, в Xharbour 0.99.61). А теперь выясняется, что со Static переменными та же самая беда...
Можно, конечно, переименовать файлы модулей, чтобы они не цеплялись автоматически...

Ура, нашёл у Harvbour ключ -m, который позволяет не цеплять другие модули!

Но всё равно - непорядок это...

 Отправлено: 11.05.06 08:26. Заголовок: Re:

Лукашевский
Подходы какие то древние ;) Но на вкус и цвет как говориться .......
я про вызов процедур посредством DO
Попробуй так :
Было do Sklad with 9
Стало Sklad(9)

Может и проблема уйдет ? ;)

 Отправлено: 12.05.06 03:13. Заголовок: Re:

Dima пишет:

цитата:

Попробуй так :

Я уже объяснял, почему DO. Для данного конкретного примера это не важно, но вообще при вызове серез DO все параметры передаются по умолчанию ПО ССЫЛКЕ, а при вызове функции - ПО ЗНАЧЕНИЮ. Иногда такое разделение бывает очень удобным.
Опять-таки, всё, что я вызываю через DO, у меня оформлено как PROCEDURE, а функции - как FUNCTION. Соотв., большинство моих функций (всё, что возвращает какое-либо значение) запихано в отдельный PRG-модуль функций, а большинство процедур - в отдельный PRG-модуль процедур. Для внутренней логики программы это тоже весьма неплохо - всегда знаешь, где что искать.

Dima пишет:

цитата:

Может и проблема уйдет ? ;)

Проблема-то, может, и уйдёт, но пол-программы придётся перелопачивать
Нет, я уж лучше ключиком -m воспользуюсь.

 Отправлено: 12.05.06 03:48. Заголовок: Re:

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

А опция -m была еще во времена clipper5.01. Всегда ей пользовался

 Отправлено: 12.05.06 04:15. Заголовок: Re:

Еще одно небольшое замечание. Про procedure забыл тогда же и никогда ими не пользовался. Функция полностью ее заменяет и более богата по возможностям. Единообразие - хороший стиль программирования для понимания логики программы и не надо применять разные вызовы для вызова функций и процедур, чтобы потом понимать, что ты вызываешь функцию или процедуру.
Могут возразить, что процедура быстрее из-за того что ничего не возвращает. На сегодняшний день - это мелочи и может сказаться лишь в условиях глубокой рекурсии, скажем если вы расчитываете прогноз на неделю барических полей. Хотя конечно в этом примере на клиппере замена функции на процедуры не сыграет никакой роли. Какая разница, что программа на клиппере на среднем оффисном компе будет считать 1 месяц 16 дней 0 часов или 1 месяц 16 дней 0 часов 15 минут - с прогнозом все равно уже опоздали .

 Отправлено: 13.05.06 00:21. Заголовок: Re:

dar пишет:

цитата:

компилятор совершенно правильно ругается на двойное объявление одной и той же переменной с одной областью видимости, причем неявной

Почему с одной областью видимости? Насколько я понимаю, объявление Static действует в Clipper только и исключительно для процедур и функций какого-то ОДНОГО PRG-модуля. Другой PRG-модуль - другие Static. Не надо путать с PRIVATE...

 Отправлено: 15.05.06 07:18. Заголовок: Re:

Все верно, я ничего не путаю и хорошо понимаю разницу между static, local, private переменными. Только у вас идет неоднозначное толкование области видимости из-за того, объявление статик переменной идет вне области действия процедуры sklad. Тем самым вы сознательно ставите в тупик компилятор. Естественно, он предполагает статик переменную вне области действия процедуры sklad, а не так как вы задумывали.
Вот Ваш код:

цитата:

Компилирую модуль KNIGY.PRG: Static w_instr,; w_screen Procedure Knigy do Sklad with 9 return В компиляцию автоматически (!) включается модуль SKLAD.PRG: Static w_instr,; w_screen Procedure Sklad return

Объявляйте статик переменные внутри процедур, тем более, что вы, по всей видимости, используете опцию /N компилятора

 Отправлено: 16.05.06 06:28. Заголовок: Re:

dar пишет:

цитата:

Объявляйте статик переменные внутри процедур,

У меня все Static переменные во всех PRG-модулях описаны в самом начале модуля, и в Clipper никогда никаких проблем это не вызывало.
В этом для меня весь смысл именно STATIC переменных - чтобы их можно было использовать во многих функциях модуля, не возясь с передачей параметров, с одной стороны, и чтобы эти переменные не выходили за пределы модуля, с другой стороны! Именно это и достигается объявлением Static переменных вне процедур. Во всех остальных случаях гораздо более естественно использовать LOCAL или PRIVATE и не глумить голову!

 Отправлено: 17.05.06 05:14. Заголовок: Re:

цитата:

У меня все Static переменные во всех PRG-модулях описаны в самом начале модуля, и в Clipper никогда никаких проблем это не вызывало В этом для меня весь смысл именно STATIC переменных - чтобы их можно было использовать во многих функциях модуля, не возясь с передачей параметров, с одной стороны, и чтобы эти переменные не выходили за пределы модуля, с другой стороны!

Да, clipper такое допускает. Но ведь именно здесь и кроется неоднозначность. В вашем примере, static перемнная используется как private с глобальным временем жизни. Хотя вообще говоря, static переменная - это локальная переменная с глобальным временем жизни. Разработчики Clipper допускали такое вольное толкование static - то как local, то как private переменные с глобальным временем жизни, в зависимости от того где она объявлена. А вот разработчики хХарбор видимо так не считают.
Для меня весь смысл static переменных - это глобальное время жизни в сочетании с локальной областью видимости. Как простейший пример использования static переменной - хранение результата расчета в калькуляторе вызываемом из программы по горячей клавише.

 Отправлено: 17.05.06 08:47. Заголовок: Re:

dar пишет:

цитата:

А вот разработчики хХарбор видимо так не считают.

Угу. Они и Global добавили....

 Отправлено: 07.02.07 01:24. Заголовок: Неточность в COLORWIN()

Нашёл ещё одно несоответствие, в TOOLSовской функции COLORWIN().
Вариант COLORWIN(0,0,23,79,"B/W,W/B") в Clipper (как 5.01, так и 5.2) даёт правильный результат - переокраску указанной области экрана синим на сером фоне, а в xHarbour (по крайней мере 0.99.70) - просто очистку указанной области экрана, аналогично как если бы я написал COLORWIN(0,0,23,79,"N/N")

 Отправлено: 11.03.07 03:50. Заголовок: Re: dar

dar пишет:

цитата:

Да, clipper такое допускает. Но ведь именно здесь и кроется неоднозначность. В вашем примере, static перемнная используется как private с глобальным временем жизни.

Clipper не просто это "допускает", а этот способ описан в руководстве по 5.01 как РЕКОМЕНДУЕМЫЙ способ использования Static переменных. Это факт (у меня есть официальное русское руководство к 5.01 (русификация СП "Магнит"), и я его прочитал перед началом серьёзного программирования на Clipper и не единожды перечитывал в процессе).
Насчёт "как private" тоже не согласен - оператор макроподстановки & с такими переменными использовать в REPLACE, например, не получится.

 Отправлено: 11.03.07 03:53. Заголовок: Re:

Обнаружилось ещё одно несоответствие xHarbour и Clipper: некорректно работает функция FT_CTRL(). По крайней мере, у меня она выдаёт значение .T. после нажатия клавиши PgDown.

 Отправлено: 11.03.07 16:58. Заголовок: Re:

Лукашевский пишет:

цитата:

Clipper не просто это "допускает", а этот способ описан в руководстве по 5.01 как РЕКОМЕНДУЕМЫЙ способ использования Static переменных. Это факт (у меня есть официальное русское руководство к 5.01 (русификация СП "Магнит")

Официальное руководство к 5.3

In CA-Clipper, DO is a compatibility statement and therefore not recommended.
Calling a procedure or function on a line by itself is the preferred method. Since this preferred calling convention normally
passes parameters by value, you must preface an argument with the pass by-reference operator (@) in order to pass by reference.

На одном из форумов прочитал сетования пользователя на "несоответствие" Clipper 5.01 и xHarbour.
И сердитый ответ разработчика, что он
1) официально пользуется руководством Clipper 5.3
2) не обязан повторять все баги Clipper 5.3, за исключением случаев, когда баг общеизвестен, и им активно пользуются
3) "ты б еще Summer'87 вспомнил"

Неужели кто-то серьезно думает, что если бы Clipper "дожил" до сегодня, то он ничем бы не отличался от Clipper 5.01 - 5.3?.