Re: Конвертация внутреннего представления переменных в Tcl
On 2009.10.08 at 15:31:09 +0400, Alexey Pechnikov wrote:
> Hello!
>
> В tcl-расширении потребовалось определить тип данных в
>
> переменной, что реализуется проверкой возвращаемого значения
>
> функции Tcl_ConvertToType(interp, objPtr, typePtr)
Вообще-то она не это делает. Она пытается преобразовать текущее
представление данных в указанный тип, и если не получается, возвращает
TCL_ERROR.
Поэтому использовать этот механизм для проверки типа - занятие довольно
стремное. А вдруг там была строка, которую почему-либо УДАЛОСЬ
преобразовать в boolean, но имелось в виду совсем не это?
Я бы ПРОВЕРЯЛ тип объекта посредством
strcmp(obj->typePtr->name,"ожидаемый тип")
(благо, и поле typePtr в Tcl_Obj, и поле name в Tcl_ObjType -
документировано)
При таком подходе я могу быть увереным, что никаких неявных
преобразований моя проверка не вызвала.
(а то напарывался я как-то с такой проверкой. Была у меня структурка
данных с 6-мегабайтным строковым представлением, и из-за ошибки в
расширении, куда в качестве параметра могла быть передана либо эта
структурка в виде моего собственного ObjType, либо список, оно
по циклу сериализовывалось/десериализовывалось столько раз, сколько
строк было в этой таблице. А все из-за того, что я сначала попытался
проверить, не список ли это, и оно честно пыталось сконвертить объект в
списочное представление).
> Вопрос: каким образом в расширении выполнить конвертацию
>
> типа данных переменной, не таская с собой все исходники Tcl?
В норме это делается так - просишь сконвертить в НУЖНЫЙ тебе тип.
Чем-то типа Tcl_GetBooleanFromObj. А оно уж само разбирается, что там
было, и как можно это сконвертить. Ну и возвращает TCL_ERROR, ежели не
получилось.
Вот со строками и ByteArray ситуация может быть значительно веселее.
Если ты не знаешь по смыслу, бинарные у тебя данные или нет, то
определить какое представление тебе больше подходит - строковое или
ByteArray - штука весьма затруднительная, особенно в задачах где бывает
и то, и то, например в задачах электронной подписи.
Reply to: