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

Aslan
> Потому что индексы енама могут идти не подряд
А могут и подряд идти. И в 95% случаев они идут подряд.

Aslan

Так любят делать в хеадерах directx 11\12, vulkan , opengl

Почему пишете энам ,а не енум ?
Лучше писать enum, так точно все поймут.

MrShoor
в крестах слишком многое через шаблоны делается. Да и КМК, возможность написать свой шаблонный велосипед всё же удобнее, нежели жестко встроенные в язык средства.

Собственно, если бы была возможно перегружать оператор for или foreach, то реализация бы получилась куда гибче предложенной.

MrShoor
А в 5% случаев посылать юзера нах с таким массивом?

Это же киллер фича такая :)

MrShoor
В Pascal / Delphi индекс массива - любой перечислимый тип, т.е можно писать

array[char] of char;

Aslan
> А в 5% случаев посылать юзера нах с таким массивом?
Да, вполне. Сейчас же например делфи посылает, если ты пытаешься запихнуть энам со значениями 256 и выше в сет.

g-cont
> в крестах слишком многое через шаблоны делается.
Ну наверное комуто удобно вместо готового простого адекватного синтаксиса навертеть гору шаблонов.

> Да и КМК, возможность написать свой шаблонный велосипед всё же удобнее, нежели
> жестко встроенные в язык средства.
Вообще ниразу не соглашусь что удобнее. Гибче - да. Удобнее - нет. Мне когда приходится дебажится сквозь шаблоны это боль и страдания. Если шаблон простой, там один тип скажем, то еще норм. Но когда намешают пяток параметров + всякая выводимая магия, вот это начинается настоящая боль.

Я вот привел простой пример, легко читается, легко используется. Давай, попробуй на шаблонах такое же поведение воссоздать.

> Собственно, если бы была возможно перегружать оператор for или foreach, то
> реализация бы получилась куда гибче предложенной.
А там где не справляются шаблоны всегда помогут макросы. #define for <что-то на эльфийском>. Собственно в этом весь С++, да.

MrShoor

А в чем проблема ?

MrShoor
Не могли сделать vector<bool>

MrShoor
Извечный вопрос, что лучше - дать инструмент которым легко делать некоторые вещи но с ограниченной областью применения и\или наличием UB,
либо дать инструмент который будет работать везде, но его использование будет нетривиальным зачастую.
В крестах выбрали второй путь.

Бегло посмотрел как устроены свойства в C++ от Майков (_declspec( property )), в C# и AngelScript. Везде один и тот же подход, в котором я и сам мыслил еще вчера - это будут непременно такие особые функции, которые надо прописывать вручную. Либо, с вариантом _declspec - хотя бы указать уже заранее написанные функции. В Delphi как раз смысл в том, что использование функций - опция, то есть property как бы легально позволяет прямое обращение к private-члену класса. Теоретически для компилятора наверное разницы нет, потому что get\set методы почти всегда заинлайнятся и издержек на вызов не будет в любом случае. Но гемор для программиста - каждый раз вручную прописывать то, что компилятор потом всё равно уничтожит - это никуда не денется.
Второй момент - мне недостаточно двух методов get\set. То что я делаю - это не просто VM с окошками, это часть игрового движка, а VCL будет использоваться для его редактора. Но сама VM будет так же и для игрового кода. А игровому коду еще нужны свойства сериализации и отправки\приёма по сети. Ну и для предиктинга состояний на клиенте. Это тоже логично реализовать через свойства. Как это сделать под капотом у меня вопросов не вызывает - у объекта будет просто таблица свойств с флагами, обращаться к переменной напрямую или же вызывать какую-то функцию для её чтения\записи. В compile-time эти же свойства будут использовать либо для автоматического доступа к приватному члену класса, либо для вызова заданной функции. Остаётся только один самый важный вопрос - синтаксис для всего этого дела.
Чтобы не выглядело слишком паскально и было достаточно наглядно для всех, кто привык к конструкциям С++. Т.е. чтобы не выбивалось из общей гаммы. Может быть будут какие-то предложения?

g-cont
> Остаётся только один самый важный вопрос - синтаксис для всего этого дела.
json?

skalogryz
нет, я имел в виду синтаксис для описания property в классе.

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

g-cont
> Навскидку, что придумалось. Писать напротив каждого объявления property - очень
> неудобно.

Сами по себе свойства с точки зрения рантайма это просто синтаксический сахар подменяющий .name на другой .real_name или .func_name.
Соответственно если у тебя си-подобный синтаксис, то можно просто объединить декларацию:

int fieldName; // настоящее поле
void setName( int value );
int propName read fieldName write setName; // читаем прямо из поля, пишем через сеттер

и всё. Само наличие ключевых слов read/write говорит об объявлении свойства.
Компиляторы C++ тут ограничены в declspec просто потому что пытаются заковать крупные изменения в языке внутри одного ключевого слова.