Вопросы по Delphi (17 стр)

g-cont
протектед свойств даже в VCL полно. Скажем, есть текстовое поле, у него свойство Text. У него есть наследник "текстовое поле из БД", у которого поле напрямую недоступно, а читается из базы данных.
Или даже проще - есть абстрактный компонент со свойством "высота". А у его наследников - у одних высота доступна напрямую, у других - вычисляется автоматически. Решается тем что у родителя делаем поле protected, а у потомков у каких надо делаем его public.

Вобщем что придумалось навскидку. Пример псевдокласса со свойствами:

class Foo
{
  int  variable;
  int  foo[4];

  int GetVariable( void ) { return variable; }
  int SetVariable( int value ) { variable = value; }
  int SetVariable( string value ) { variable = atoi( value ); }

  int GetFoo( int index )
  {
    assert( index >= 0 && index < 4 );
    return foo[index];
  }
  void SetFoo( int value, int index )
  {
    assert( index >= 0 && index < 4 );
    foo[index] = value;
  }
public:
  prop "MyVar"
  {
    read( program, backend )  variable;
    write( program, backend )  variable;
    write( network )    GetVariable();
    read( network )    SetVariable( int );
    read( txtfile )    SetVariable( string );
    write( binfile )    SetVariable( void* );
  };

  prop "Left"
  {
    read( program, backend )  foo[0];
    write( program, backend )  foo[0];
  };

  prop "Right"
  {
    read( program, backend )  foo[1];
    write( program, backend )  foo[1];
  };

  prop "Top"
  {
    read( program, backend )  GetFoo( 2 );
    write( program, backend )  SetFoo( int, 2 );
  };

  prop "Bottom"
  {
    read( program, backend )  GetFoo( 3 );
    write( program, backend )  SetFoo( int, 3 );
  };
};

Имена свойств можно указывать как обычные имена, так и как строки, возможно для кого-то вариант со строками окажется нагляднее.
В данном примере все имена свойств - строки.
read и write открывают набор перечисления битовых флагов, для чего следует использовать данный вызов. Доступны следующие зарезервированные слова:
program  - доступ из программы (чтение\запись)
backend  - доступ из бакэнда виртуальной машины (чтение\запись)
network  - отправка и приём по сети
txtfile  - чтение и запись в свойств в текстовый файл
binfile  - чтение и запись свойств в бинарный файл
predict  - чтение и запись в машину состояний

Правая часть объявления - что будет вызвано при обращении к свойству в различных ситуациях. Прямой доступ к той или иной переменной, либо вызов функции с заведомо объявленными параметрами. Не объявлять параметры очевидно нельзя - дедуктор перегрузки функций сойдет с ума.
Есть возможность явного доступа в ячейку массива. Передаваемое значение для методов Set объявляется просто как тип, без имени.
Соответственно есть возможность передавать туда не только атомарные типы, но и пользовательские классы (ну по крайней мере из бакэнда).
Теоретически предлагаемая конструкция не завязана на объектах, можно к примеру объявить глобальный property, если это потребуется ( а у меня есть такая необходимость ).
По здравом размышлении от секции property решил отказаться, т.к. всё же остаются некоторые спорные моменты в таком подходе.
Перегрузка свойств осуществляется по обычному принципу наследования. Если какой-то метод доступа уже был в родителе - он будет переопределён. Если в потомке метод не был указан - будет унаследован. Явный запрет на унаследования какого-либо действия можно описать, например как

read( program, backend )  0;

Важно понимать, что всё вышеописанное, пока что плод моей фантазии и пример предлагаемого синтаксиса. Покритикуйте, если вам конечно интересна эта тема. Может здесь где-то притаился UB, который я не заметил.

kipar
ну да, я уже отказался от этой идеи.

> А может есть реализация парсера на С++? Меня интересует только сам формат dfm, а не язык Delphi.

Вы не правильный путь избрали. 
Парсер вам может понадобиться лишь в том случае, если вы пожелаете улучшить функциональность dfm. 
В противном случае исходники dfm просто получить путем разбора бинарного файла dfm /из ресурсов/. 
Его формат прост и разбор его не сложен. 
Говорю об этом не голословно ...

две структуры.

  Enemy[0] := ZeroEnemy[0];
  move(ZeroEnemy[0], Enemy[0], SizeOf(TPerson));

что из них быстрее работает? Или опять самому подсчитывать? )))

сравнил. Второй вариант на 0.01 (примерно) работает быстрее.

Mirrel
> Второй вариант на 0.01 (примерно) работает быстрее.
Второй вариант не безопасен, если структура содержит ARC поля. Например string, динамический массив или интерфейс. Да и при рефакторинге есть риск сломать код, т.к. типы данных не проверяются.

MrShoor, да, это я понимаю. Что там динамические размеры... которые накрыться медным тазом могут быть.
В данном случае статично всё делаю.

Mirrel
> Что там динамические размеры...
Не в динамичности размеров там проблема, а в счетчике ссылок.

MrShoor
> Не в динамичности размеров там проблема, а в счетчике ссылок.
собственно пример:
https://ideone.com/QPyFcd

SRefCount из документации