Комментарии 9
Думаю использовать xls в качестве входного файла не лучший вариант.
Plain text с каким-то простеньким синтаксисом будет в самый раз.
Plain text с каким-то простеньким синтаксисом будет в самый раз.
0
Ну так скрипт, насколько я понял, генерит из CSV — куда уже проще. А XLS только для удобного наглядного создания. Хотя я бы тоже отдал предпочтение исходнику в чем-то, вроде комментированного JSON
0
Например, так?
{
black = 0,
darkred = {1, "Bloody Mary"},
white = 15 -- Snow white won't get commented
}
0
Да, вполне ничего
0
Для простых вещей выглядит просто и удобно.
Хотя если будет больше двух значений (столбцов) в объекте, то уже нужны будут ключи.
Если задать тип дополнительного столбца и значение по умолчанию, то наглядность потеряется.
В моем варианте тоже есть неудобство, что в систему контроля версий нужно добавлять не только xls, но и csv, чтобы можно было наглядно diff посмотреть.
Хотя если будет больше двух значений (столбцов) в объекте, то уже нужны будут ключи.
Если задать тип дополнительного столбца и значение по умолчанию, то наглядность потеряется.
В моем варианте тоже есть неудобство, что в систему контроля версий нужно добавлять не только xls, но и csv, чтобы можно было наглядно diff посмотреть.
0
Скорее так:
Мне кажется языку не хватает встроенной возможности расширения синтаксиса.
А то немного «улучшенную» версию enum'ов пришлось ждать до C++11. И все вкусняшки в языке нужно протаскивать через комитет по стандартизации.
Если бы в языке была бы стандартная возможность расширять синтаксис — хотя бы просто на уровне синтаксического сахара, как в данном примере. То многие улучшения могли быть обкатаны заранее и самые востребованные и «выжившие » в конкурентной борьбе пошли бы в стандарт. По аналогии с расширением стандартной библиотеки за счет переноса каких-то вещей из буста.
Плюс нишевые расширения, а ля Qt moc generator, были бы реализованы без дополнительных зависимостей и пре-генерации (вернее она стала бы стандартным шагом при обработке исходных кодов, наравне с раскрытием макросов, компиляцией и т.п.).
Хотя Страуструп и опасался того, что разные компиляторы C++ вводят дополнительные несовместимые языковые конструкции. Я думаю в этом вопросе нужно было не противостоять этой тенденции, а возглавить её. То есть стандартизировать её и вопрос совместимости сам бы отпал.
enum Color
{
black = 0,
darkred = {1, "Bloody Mary"},
white = 15 -- Snow white won't get commented
}
Мне кажется языку не хватает встроенной возможности расширения синтаксиса.
А то немного «улучшенную» версию enum'ов пришлось ждать до C++11. И все вкусняшки в языке нужно протаскивать через комитет по стандартизации.
Если бы в языке была бы стандартная возможность расширять синтаксис — хотя бы просто на уровне синтаксического сахара, как в данном примере. То многие улучшения могли быть обкатаны заранее и самые востребованные и «выжившие » в конкурентной борьбе пошли бы в стандарт. По аналогии с расширением стандартной библиотеки за счет переноса каких-то вещей из буста.
Плюс нишевые расширения, а ля Qt moc generator, были бы реализованы без дополнительных зависимостей и пре-генерации (вернее она стала бы стандартным шагом при обработке исходных кодов, наравне с раскрытием макросов, компиляцией и т.п.).
Хотя Страуструп и опасался того, что разные компиляторы C++ вводят дополнительные несовместимые языковые конструкции. Я думаю в этом вопросе нужно было не противостоять этой тенденции, а возглавить её. То есть стандартизировать её и вопрос совместимости сам бы отпал.
-1
Похоже лед тронулся:
metaclasses
metaclasses
0
Спасибо за информацию!
Мне показалось, что снова идет усложнение синтаксиса. Зачем???
Подход Qt намного проще — они используют обычные возможности С++, но вводят еще один уровень выполнения-генерации когда (Qt-moc). Их решение мне кажется вполне эффективным.
Т.е. надо не придумывать новые конструкции языка в большом количестве, а ввести новое время генерации-выполнения: MacroTime, GenerationTime, CompileTime, RunTime,
0
По сути так и есть. Мета-классы применяются перед компиляцией.
Никакого усложнения синтаксиса нет — на вход метакалссы принимают синтаксически валидный С++ класс. Сама реализация пишется вполне обычными С++ циклами, условными операторами и т.п. Единственное дополнение — знак $, который они заменят на что-то другое.
Но в вашем подходе нужно будет тоже как-то различать код для этапа компиляции и генерации, тоже нужно вводить какое-то волшебное слово.
Подход Qt — это очень серьезный компромисс, по сути других вариантов не было в тот момент.
Они используют синтаксис макросов, что достаточно ограниченно в выразительных средствах и нам все равно приходится запоминать синтаксис разных Q_PROPERTY или Q_ENUM.
Никакого усложнения синтаксиса нет — на вход метакалссы принимают синтаксически валидный С++ класс. Сама реализация пишется вполне обычными С++ циклами, условными операторами и т.п. Единственное дополнение — знак $, который они заменят на что-то другое.
Но в вашем подходе нужно будет тоже как-то различать код для этапа компиляции и генерации, тоже нужно вводить какое-то волшебное слово.
Подход Qt — это очень серьезный компромисс, по сути других вариантов не было в тот момент.
Они используют синтаксис макросов, что достаточно ограниченно в выразительных средствах и нам все равно приходится запоминать синтаксис разных Q_PROPERTY или Q_ENUM.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Генератор умных перечислений, EnumGenerator