Многое, о чем ты говоришь - для меня темный лес, т.к. с c++ не знаком. Однако, рискну предположить, что можно реализовать без хранения и просто при сборке проекта проверять каждую функцию. Если я чего-то недопонимаю, то поправьте меня.
Вид для печати
Многое, о чем ты говоришь - для меня темный лес, т.к. с c++ не знаком. Однако, рискну предположить, что можно реализовать без хранения и просто при сборке проекта проверять каждую функцию. Если я чего-то недопонимаю, то поправьте меня.
Вот если ещё табулирование было как NotePad + то вообще класс было бы ... :blush2:
В структуре symbol для функции уже предоставлен список аргументов со всеми тегами и прочим. Нам нужно лишь сделать универсальный оператор __attribute (format(...)), который будет сообщать строку с форматом и началом переменного кол-ва аргументов (variadic args). Хранить строки вероятно в отдельном списке. Номер ячейки из списка хранить в union x, записав stacksize и идентификатор из таблицы в виде структуры struct func. Памяти будет использовано гораздо меньше, чем мы бы создавали на каждый символ в отдельном поле.
Дополнительный список лучше сделать из-за переменного кол-ва аргументов (их может очень быть много). Можно сделать union для других attribute-параметров.
P.S. мб где-то сказал глупость, но я это так себе представляю.
Ты прав, он годится только для handmade проектов.
Так SA-MP - это по сути и есть handmade-проект.
Я примерно так и описывал его в своём посте выше, разве что без скобок (они не являются обязательными в defined, sizeof и tagof, поэтому для __attribute есть смысл обеспечить ту же логику).
Переменная stacksize объявлена как long - это означает, что в зависимости от компилятора/целевой платформы её размер может быть не только 4, но и 8 байт. Если её и новую переменную объединить в struct, то в сумме их размер может превысить размер struct array.
Как бы то ни было, я только что создал PR'ы с двумя новыми фичами - __addressof и __fallthrough (последняя, к слову, почему-то не очень нравится мейнтейнерам). На следующих выходных попробую реализовать __attribute, если время позволит.
По сути для оператора __attribute нужно будет выделять поле в структуре symbol (указатель, ибо оператор опционален, чтобы хранить всю структуру в symbol), ибо (почти) каждый символ может быть реализован с помощью этого оператора, а специфичную информацию нужно где-то хранить.
Они просто очень любят goto. =) Идея с __addressof очень понравилась :good:
Не нашел в коде константу, которая отвечает за смещение часового пояса . Она есть? (Это было бы полезно, если делать версии мода датой [__date, __time])
P.S: Если ее нет, то я сделаю PR.
Нет, и впервые вообще приходится слышать о необходимости в чём-то подобном (причём, не только в Pawn, но и даже в C/C++, из которых, собственно, и позаимствованы идеи с __date, __time, __file и __line).
Можно поподробнее о том, как такая константа должна использоваться? Может быть я что-то не так понял.
Допустим: использовать дату компиляции скрипта в роле версии мода. Если я живу в Екатеринбурге (допустим), то offset + 2 от Москвы. Как раз таки использую дату компиляции мода для версии мода и появилась проблема, что у второго разработчика не московское время, а нужно чтобы показывалось московское.
Использовать дату и время для версионирования - очень плохая идея. Это не исключает возможности того, что вы и второй разработчик можете в одно и то же (или почти одно и то же) время сделать две разные версии мода с разным новым функционалом/багфиксами. Обычно для таких целей используют хеши коммитов из системы контроля версий, к примеру Git (т.е. можно организовать сборку с помощью файла *.bat или shell-скрипта, и в него перед сборкой добавить вызов git с целью узнать хеш текущего коммита и записать результат в файл *.inc).
Либо вы можете попытаться решить проблему "в лоб", реализовав новую константу в компиляторе, но я очень сомневаюсь, что такое примут в апстрим, не говоря уже о том, что я понятия не имею, как вы будете писать тесты, чтобы они корректно воспроизводились во всех часовых поясах.