Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#1: 2006-07-04 23:12:18 ЛС | профиль | цитата
Вот такая ерунда:
  PData = ^TData;
  TData = object
private
dtype:byte;
procedure SetType(t:byte);
public
idata:THiInt;
sdata:string;
rdata:real;
Next:PHI_Event;
ldata:PData;
property Data_type:byte read dtype write SetType;
end;
...................
procedure TData.SetType;
begin
ldata := nil;
dtype := t;
end;
здорово облегчает жизнь....
и во МНОГИХ местах позволяет повыкидывать строки типа:
  ldata := nil;
((а ведь они еще в _hi_CreateEvent не проставлены ))

Это я от безысходности: то в одном месте стрельнет, то в другом.... По прикидкам: число мест, где может еще стрельнуть, измеряется сотнями....
карма: 9

0
vip
#1.1контекстная реклама от партнеров
Администрация
Ответов: 15294
Рейтинг: 1518
#2: 2006-07-05 14:33:45 ЛС | профиль | цитата
Выход конечно, но уж очень не хочется объекты гонять между компонентами
карма: 26
0
Ответов: 9906
Рейтинг: 351
#3: 2006-07-05 14:40:32 ЛС | профиль | цитата
Это я от безысходности: то в одном месте стрельнет, то в другом.... По прикидкам: число мест, где может еще стрельнуть, измеряется сотнями....

карма: 9

0
Администрация
Ответов: 15294
Рейтинг: 1518
#4: 2006-07-05 15:58:27 ЛС | профиль | цитата
Ну читать-то я еще умею

[size=-2]------ Добавлено в 15:58
То что объект это выход из положения - никто не спорит. Но и то, что в кодах элементов не должно быть строк вида:
_Data.data_type := data_xxx;
....
_Data.idata := X;
и т.д. тоже очевидно.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#5: 2006-07-05 17:35:26 ЛС | профиль | цитата
Dilma писал(а):
Но и то, что в кодах элементов не должно быть строк вида: <==========> и т.д. тоже очевидно.

Совершенно не очевидно. И думаю, что не правильно. После этой доработки я убрал MT-fix из LPT и все прекрасно работает в тех же схемах, падение которых и заставило делать этот fix.

Dilma писал(а):
Ну читать-то я еще умею
Сайт падал (или кто-то его блокировал, не будем называть имен ), а я хотел к посту прибавить долго и нудно примерно следующее:
По моему скромному разумению разницы между структурой и объектом (в плане таскания) аж никакой. ЕДИНСТВЕННЫМ отличием в кодах (хотя и в очень большом количестве) будут перехваты присваиваний в data_type.
Вот пример из аттача у меня выдает 28. Под 7-м Дельфи будет 32, надо полагать...

карма: 9

0
файлы: 1test.sha [524B] [407]
Администрация
Ответов: 15294
Рейтинг: 1518
#6: 2006-07-05 22:41:16 ЛС | профиль | цитата
Galkov, очевидность должна заключаться в том, что такой код:
_Data.data_type := data_xxx;
....
_Data.idata := X;

и такой:
CreateXxxData(_Data, X);[/code]
делает одно и тоже, но в первом случае разработчик компонента обязан знать в какие поля чего можно класть, а чего нельзя(ибо такой код распологает к тому, чтобы в data_type засунуть свой собственный тип, что мягко говоря может привести к печальным последствиям). В свою очередь автора пакета код в первом варианте [b]обязывает[/b] отныне и вовеки хранить тип данных в поле data_type, а значение целого типа в поле idata. Да, это конечно очень замечательно, что Delphi позволяет из структуры сделать объект, а из поля - вызов метода, но как только некий Вася написал у себя так:
procedure Test(var t:byte);
begin
Message(t);
end;

procedure onClick(_Data:Tdata; index:word);
begin
test(_Data.data_type);
end;
представленная выше модификация вызовет Error, из-за которого код компилироваться перестанет.

Я уже даже не говорю про того же Васю, который в случае применения указанной постом выше правки, поправив свой исходник таким образом:
procedure onClick(_Data:Tdata; index:word);
begin
new(_Data.ldata);
....
_Data.data_type := data_int;
end;
через пол часа мучений создаст на форуме тему "А почему у меня не выходит сделать MT поток?"


Собственно за примерами далеко ходить не надо: именно это сейчас и наблюдается в CGTShare.

Единственное правильное и надежное решение это потребовать от разработчика компонент для операций с типом TData использовать только стандартные ф-ции.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#7: 2006-07-06 00:07:47 ЛС | профиль | цитата
Это все хорошие слова.
В C++ (имеется ввиду язык а не конкретный компилятор) это делается красивей и еще надежней.
Только объем работы таков, что на этом пути можно еще с год баги из дистрибутивов вытаскивать.
Вот и все. Причем первое второму не противоречит: можно перехватить присваивание в data_type, ликвидировав несметное количество багов, а потом годами высекать из кодов доступ к конкретным полям.
Которые и появились-то из-за неэффективности механизма property в сравнении с аналогичными механизмами в C++.


А с CGTShare происходит не это.
Отсутствие возможности написать CodeGen на fasm, к примеру, не имеет ни какого отношения к использованию предопределенных методов.
А говорит о том, что используемый нами сегодня механизм интерфейсом не является.

Т.е., вот такой совершенно конкретный вопрос: могу ли я написать CodeGen на fasm
Имея информацию ТОЛЬКО о интерфейсе, но НИЧЕГО не зная о версии компилятора, на котором написана среда.
Ответ - нет. Если бы был - да, и проблем не было бы....

[size=-2]------ Добавлено в 00:07

А вот еще одна прелесть:
unit hihiPlugs;
...........
TParam = record
Handle:cardinal;
Desktop:function(Index:smallint):TData;
end;
Это означает, что вызывающая прога (это плаг, который я делаю, скажем) резервирует память под результат TData. А модули среды заполнят поля. Вот только мой компилятор выделит под это дело 28 байт.
А сколько заполнит HiAsm
Гипотеза 32 - соответствует действительности

И такого несть числа....
Типа возврат HiAsm-dll-кой нижней точки типа Array, а версии компиляторов (или даже версии HiAsm) у проги и dll-ки разные....
карма: 9

0
Ответов: 9906
Рейтинг: 351
#8: 2006-07-08 17:01:07 ЛС | профиль | цитата
В принципе, более правильно, с точки зрения программиста, было бы:

  • полностью закрыть от кодов элементов внутренние поля структуры
  • ввести property типа string, real, bitmap, icon, и т.п.
  • ликвидировать в связи с этим все doData и ToXXX - пользоваться перехватами в property
    Почему.
    Потому-что код
        _prop_Data := _DoData('test');[/code]менее эффективен чем такой (имеется ввиду, что string - это property с функциональностью doData): 
    
        _prop_Data.string := 'test';[/code]
    Компилятор, в первом случае: сформирует вспомогательную переменную типа TData; передаст ее указатель в ф-ю doData (которая и заполнит необходимые поля); после этого скопирует всю переменную в _prop_Data; и наконец освободит память под эту вспомогательную переменную. Не считая того, что все это будет обложено блоком try-finaly (освобождение памяти - в блоке finaly)
    Во втором же случае, поля будут формироваться сразу в _prop_Data
  • карма: 9

    0
    Ответов: 24
    Рейтинг: 0
    #9: 2006-07-08 23:07:49 ЛС | профиль | цитата
    А еще эффективнее будет использовать записи типа case of (меньше памяти)
    карма: 1

    0
    Ответов: 9906
    Рейтинг: 351
    #10: 2006-07-08 23:16:37 ЛС | профиль | цитата
    alleo, не очень понятно о чем речь...
    осталось выяснить - кому
    карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1518
    #11: 2006-07-10 18:46:17 ЛС | профиль | цитата
    Имеются ввиду видимо объединения (аналоги union в С)
    карма: 26
    0
    Ответов: 24
    Рейтинг: 0
    #12: 2006-07-10 19:09:55 ЛС | профиль | цитата
    Именно.
    карма: 1

    0
    Ответов: 9906
    Рейтинг: 351
    #13: 2006-07-10 19:19:27 ЛС | профиль | цитата
    Ну так чтобы делать это, и необходимо СНАЧАЛА абсолютно "изолировать" поля структуры от элементов. Что есть не самая маленькая работа....
    А потом уже можно приняться за обсуждение (дай бог - и реализацию) наиболее рационального состава наших данных.

    Собственно говоря, вышестоящее предложение имело это ввиду, в качестве, скажем так - второго хода......
    Были и размышления, что это должно быть похоже на TCOPYDATASTRUCT......
    карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1518
    #14: 2006-07-14 16:48:00 ЛС | профиль | цитата
    Union пока сделать не получится, так как есть элементы использующие несколько полей одновременно
    карма: 26
    0
    Ответов: 9906
    Рейтинг: 351
    #15: 2006-07-14 17:41:57 ЛС | профиль | цитата
    Гм...
    Вообще-то делал акцент на СНАЧАЛА, потому-что уже потом (union там или нет) - это будут БЕСПЛАТНЫЕ вещи.
    В смысле: кодам элементов это будет по барабану.
    ИМХО
    карма: 9

    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)