Pull to refresh

Comments 9

Думаю использовать xls в качестве входного файла не лучший вариант.
Plain text с каким-то простеньким синтаксисом будет в самый раз.
Ну так скрипт, насколько я понял, генерит из CSV — куда уже проще. А XLS только для удобного наглядного создания. Хотя я бы тоже отдал предпочтение исходнику в чем-то, вроде комментированного JSON
Например, так?
{
    black = 0,  
    darkred = {1, "Bloody Mary"},
    white = 15  -- Snow white won't get commented
}
Для простых вещей выглядит просто и удобно.
Хотя если будет больше двух значений (столбцов) в объекте, то уже нужны будут ключи.
Если задать тип дополнительного столбца и значение по умолчанию, то наглядность потеряется.

В моем варианте тоже есть неудобство, что в систему контроля версий нужно добавлять не только xls, но и csv, чтобы можно было наглядно diff посмотреть.
Скорее так:
enum Color
{
    black = 0,  
    darkred = {1, "Bloody Mary"},
    white = 15  -- Snow white won't get commented
}


Мне кажется языку не хватает встроенной возможности расширения синтаксиса.
А то немного «улучшенную» версию enum'ов пришлось ждать до C++11. И все вкусняшки в языке нужно протаскивать через комитет по стандартизации.

Если бы в языке была бы стандартная возможность расширять синтаксис — хотя бы просто на уровне синтаксического сахара, как в данном примере. То многие улучшения могли быть обкатаны заранее и самые востребованные и «выжившие » в конкурентной борьбе пошли бы в стандарт. По аналогии с расширением стандартной библиотеки за счет переноса каких-то вещей из буста.

Плюс нишевые расширения, а ля Qt moc generator, были бы реализованы без дополнительных зависимостей и пре-генерации (вернее она стала бы стандартным шагом при обработке исходных кодов, наравне с раскрытием макросов, компиляцией и т.п.).

Хотя Страуструп и опасался того, что разные компиляторы C++ вводят дополнительные несовместимые языковые конструкции. Я думаю в этом вопросе нужно было не противостоять этой тенденции, а возглавить её. То есть стандартизировать её и вопрос совместимости сам бы отпал.

Спасибо за информацию!


Мне показалось, что снова идет усложнение синтаксиса. Зачем???
Подход Qt намного проще — они используют обычные возможности С++, но вводят еще один уровень выполнения-генерации когда (Qt-moc). Их решение мне кажется вполне эффективным.


Т.е. надо не придумывать новые конструкции языка в большом количестве, а ввести новое время генерации-выполнения: MacroTime, GenerationTime, CompileTime, RunTime,

По сути так и есть. Мета-классы применяются перед компиляцией.
Никакого усложнения синтаксиса нет — на вход метакалссы принимают синтаксически валидный С++ класс. Сама реализация пишется вполне обычными С++ циклами, условными операторами и т.п. Единственное дополнение — знак $, который они заменят на что-то другое.

Но в вашем подходе нужно будет тоже как-то различать код для этапа компиляции и генерации, тоже нужно вводить какое-то волшебное слово.

Подход Qt — это очень серьезный компромисс, по сути других вариантов не было в тот момент.
Они используют синтаксис макросов, что достаточно ограниченно в выразительных средствах и нам все равно приходится запоминать синтаксис разных Q_PROPERTY или Q_ENUM.
Sign up to leave a comment.

Articles