Войти
ПрограммированиеФорумОбщее

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

Страницы: 112 13 14 15 16 17 Следующая »
#225
(Правка: 22:09) 22:08, 20 июня 2022

ronniko
> fasm такое могет.
Могёт что? Могёт не скомпилироваться, если ты добавил в энам еще одно значение, а проапдейтить const забыл?

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

#226
(Правка: 22:14) 22:11, 20 июня 2022

Aslan

Потому что индексы енама могут идти не с 0 и не подряд

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


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

#227
(Правка: 22:15) 22:13, 20 июня 2022

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

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

#228
22:13, 20 июня 2022

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

#229
(Правка: 22:15) 22:14, 20 июня 2022

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

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

#230
22:19, 20 июня 2022

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

array[char] of char;
#231
(Правка: 22:38) 22:37, 20 июня 2022

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

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

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

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

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

#232
(Правка: 22:40) 22:40, 20 июня 2022

MrShoor

если ты пытаешься запихнуть энам со значениями 256 и выше в сет.

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

#233
23:07, 20 июня 2022

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

#234
8:54, 21 июня 2022

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

#235
9:05, 21 июня 2022

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

#236
9:10, 21 июня 2022

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

#237
10:12, 21 июня 2022

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

#238
10:51, 21 июня 2022

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

#239
(Правка: 11:09) 11:08, 21 июня 2022

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

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

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

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

Страницы: 112 13 14 15 16 17 Следующая »
ПрограммированиеФорумОбщее