VY> 1.В чем отличие (в данном контексте) между операторами:
VY> RefQue &= WHAT(AnyQue, 1) и RefQue &= WHAT(AQ:ID)
Ты, вероятно, имел в виду:
RefQue &= WHAT(AnyQue,1) и RefQue &= AQ:ID
Отличие очень большое!
В первом случае оператор WHAT() не обрабатывает, как положено, поле типа ANY. Это — известная недоработка таких оператор, как WHAT/WHO/WHERE. Я уже как-то описывал все особенности их работы.
Так вот, в данном случае, WHAT() просто формирует внутреннюю UFO-переменную (внутренний аналог ANY) и назначает ей ссылку на 4-байтовую область памяти по адресу, равному адресу поля AQ:ID в буфере записи очереди AnyQue.
Во втором же случае уже работает компилятор Клариона, который прекрасно знает, что обе переменные являются ANY-переменными. А по правилам компилятора, при присваивании ANY-переменных происходит следующее: ссылка на переменную из AQ:ID записывается в RefQue. Т.е. в RefQue получаем не ссылку на поле AQ:ID, а ссылку на поле, на которое, в данный момент, ссылается само это поле AQ:ID. В данном случае, т.к. AQ:ID &= Null, то и получаем RefQue &= Null.
VY> 2.Почему если черырехбайтовое поле, то сразу STRING(4)?
Просто из-за того, что строковый тип в Кларионе является самым универсальным и, из-за неявных преобразований, позволяет работать со значениями любых типов.
VY> У меня лично сложилось такое впечатление, что это просто очередной Клашин баг.
VY> Попробую объяснить 🙂VY> PROGRAM
VY> MAP
VY> END
VY> RefQue ANY
VY> AnyQue QUEUE,PRE(AQ)
VY> ID ANY
VY> END
VY> CODE
VY> RefQue &= WHAT(AnyQue, 1)
VY> CLEAR(AnyQue)
VY> RefQue = 13
VY> ADD(AnyQue, AQ:ID)
VY> MESSAGE(‘А теперь GPF.’)
VY> MESSAGE(AQ:ID)
VY> RETURNVY> То есть, RefQue &= WHAT(AnyQue, 1) позволяет получить доступ
VY> через RefQue к некоей черырехбайтовой СЛУЖЕБНОЙ области
VY> ANY поля AQ:ID, и это совсем не превращение
VY> «ANY-поля в обычное поле STRING(4)» (разве, что с точки зрения RefQue),
VY> потому, что любое присвоение RefQue напрочь сносит крышу у AQ:ID,
VY> а это уже криминал.
В вышеприведенном примере все понятно. Оператор RefQue = 13 записал в поле
AQ:ID ’13 ‘ или, в двоичном виде:
‘1’ = 49 = 31h
‘3’ = 51 = 33h
‘ ‘ = 32 = 20h
‘ ‘ = 32 = 20h
итого — 31332020h
Оператор Message(AQ:ID) обрабатывается уже компилятором а он, как я уже писал, прекрасно знает, что надо делать с ANY-переменной. Таким образом, компилятор попытался обработать адрес 31332020h, где, по его мнению, должна была находиться информация о значении этой переменной. Надеюсь, будет лишним объяснять, что он там найдет. Закономерно получаем GPF!
И Кларион тут совсем не виноват! Ты ведь попытался обмануть компилятор и решил работать с переменными практически на низком уровне, через указатели. Как и в С, вся ответственность за «кривые ручки» (не в твой адрес) ложиться на самого программиста! Опять же, я уже как-то писал, что в Кларионе можно сделать практически все, что можно сделать и в С. При этом, естественно, приходится обходить ограничения компилятора и тут уж все зависит от твоего внимания и знаний.
VY> В этой связи вот еще любопытный код, который мне тоже не очень понятен.
VY> PROGRAM
VY> MAP
VY> END
VY> SamAny ANY
VY> RefAny ANY
VY> CODE
VY> RefAny &= SamAny
VY> RefAny = 13
VY> MESSAGE(SamAny)
VY> RETURNVY> Куда RefAny записал 13? (по идее в SamAny, «превратив ее в STRING(4)»)
VY> Почему SamAny об этом ничего не знает (без меня меня женили?)
Ты меня извини, но это все от непонимания сущности ANY-переменных. ANY-переменная представляет собой обычный указатель! Ну или, почти обычный указатель. Дело в том, что сама ANY-переменная содержит указатель на структуру, которая содержит всю необходимую информацию о переменной, на которую ссылается эта ANY-переменная. Грубо говоря, эта структура представляет собой класс для работы с UFO-переменными. UFO-переменная это внутреннее название ANY-переменных.
На внутреннем уровне существует два типа UFO-переменных:
— ValUFO — работает со статическими значениями, например UFO &= 10
— VarURO — работает с переменными или статическими значениями типа String.
Например, UFO &= Var; UFO &= ‘Строка’ Это, вероятно, самое мощное средство языка Кларион, которое и отличает его от всех остальных языков! Практически вся внутренняя «кухня» очередей, классов, неявных и явных преобразований построена на базе UFO-переменных. Возвращаясь к вышеприведенному коду:
в начале программы SamAny &= Null
RefAny &= SamAny => RefAny &= Null
RefAny = 13 — образуется внутренняя ValUFO-переменная, которая не имеет никакой связи с SamAny!
Message(SamAny) — ты просто попросил вывести значение, на которое ссылается ANY-переменная SamAny. Т.к., SamAny &= Null, то и получишь на выходе пустую строку!
Совсем другое дело, если-бы ты написал что-то типа:
SamAny ANY RefAny ANY SVar STRING(10) CODE SamAny &= SVar ! Назначаем SamAny указатель на переменную SVar RefAny &= SamAny ! Теперь и RefAny ссылается так-же на SVar RefAny = 13 ! Аналогично SVar = '13' MESSAGE(SamAny) ! Выведет значение SVar, т.е. - '13'
VY> Такое ощущение, да так оно наверное и есть,
VY> что ANY переменные родились не для всех, а только для программеров TOPSPEED,
VY> когда эти ребята ощутили нехватку указателей в своем языке,
VY> когда маленько отошли в сторону от шаблонов и приступили к
VY> библиотеке ABC. Шаблоны то тем и хороши, что туда можно вставить что угодно,
VY> а вот когда пишешь класс (самый первый C4
VY> ABC, FieldPairsClass, например), попробуй-ка обойтись без указателей.
VY> Вот и придумали ANY, а как с ней остальным
VY> работать, забыли написать. И заточили эту ANY исключительно
VY> под свои нужны (ну не нужен им пока GET/SORT на QUEUE с ANY)
VY> :(((
Читай выше. UFO-переменные были введены в язык с самого начала. Практически, они составляют костяк Клариона. Другое дело, что изначально они были спрятаны от программистов. После, когда стал ощущаться недостаток указателей, сделали простою надстройку для компилятора. Что же касается очередей и операторов GET/SORT, то методы обработки очередей изначально не были рассчитаны на работу с полями-указателями. Взять хотя бы поля-рефералы, типа &STRING/&LONG и пр. Ведь эти типы изначально были допустимы для использования в очередях. Так что, пенять надо не на ANY-переменные, а на леность или недальновидность разработчиков!