Comments 11
Извините, а на русском языке заголовок нельзя было написать?
0
Каждый раз, когда читаю такие статьи, задаюсь вопросом, «почему я все еще пишу на плюсах, это ведь такой адъ?»
+2
Спасибо за статью. Этот элемент нового стандарта прошел, почему то, мимо меня.
Все красиво, но опять же, т.к. это compile-time, нельзя построить простого JSON/XML/HTML/e.t.c парсера, а ведь конструкция так и напрашивается на это. То есть динамическое отображение «строка->тип» ну очень хочется иметь без кучи if else или switch.
Все красиво, но опять же, т.к. это compile-time, нельзя построить простого JSON/XML/HTML/e.t.c парсера, а ведь конструкция так и напрашивается на это. То есть динамическое отображение «строка->тип» ну очень хочется иметь без кучи if else или switch.
0
Можно сделать, например, compile-time JSON-парсер, но т.к. сам JSON должен быть объявлен до компиляции, а не в runtime, практического смысла от этого никакого, кроме образовательного. С другой стороны можно сделать compile-time генератор парсеров для объявленной json-schema: парсер в runtime получает текст и выдает статически-типизированную структуру, если источник соответствует схеме, или исключение в противном случае.
Впрочем, это не совсем тот случай, на который я хотел бы обратить внимание. Подобная техника может быть крайне полезна не для парсеров, а для ORM, на что и нацелен пример из статьи. Все кто имел дело с статически-типизированными ORM в C++ прекрасно понимают как неудобно определять структуры данных без использования дополнительных препроцессоров.
PS. Кстати, следующую статью я как раз хотел посвятить части библиотеки моего С++ web-фреймворка (который хотелось бы полностью перевести на opensource) — библиотеке для работы с JSON. Однако, возможно более интересной темой была бы реализация ORM, использующего вышеозначенную технику (единственное, что меня смущает, — пока еще неопределенный статус данного типа литералов в будущем стандарте). Что вы думаете?
Впрочем, это не совсем тот случай, на который я хотел бы обратить внимание. Подобная техника может быть крайне полезна не для парсеров, а для ORM, на что и нацелен пример из статьи. Все кто имел дело с статически-типизированными ORM в C++ прекрасно понимают как неудобно определять структуры данных без использования дополнительных препроцессоров.
PS. Кстати, следующую статью я как раз хотел посвятить части библиотеки моего С++ web-фреймворка (который хотелось бы полностью перевести на opensource) — библиотеке для работы с JSON. Однако, возможно более интересной темой была бы реализация ORM, использующего вышеозначенную технику (единственное, что меня смущает, — пока еще неопределенный статус данного типа литералов в будущем стандарте). Что вы думаете?
+2
Безусловно! Когда набор данных фиксирован(таблица БД), то тут особых проблем быть не должно. Большую часть Вы уже раскрыли в этой статье. Единственное, как красиво в это дело встроить механизм транзакций. Поэтому, с большим удовольствием почитал бы Вашу статью с вариантом реализации ORM.
Еще чуть-чуть и сделаете свою реализацию boost.serialization на новом стандарте.
Еще чуть-чуть и сделаете свою реализацию boost.serialization на новом стандарте.
0
Круто, спасибо.
+1
Вот сейчас как раз понадобилось, но оказалось — это не стандарт даже 17. И конструкции вида
template<typename CharT, CharT ...String>
constexpr str<String...> operator"" _s()
{
return str<String...>();
}
например msvc не поддерживает — печаль0
Sign up to leave a comment.
Literal operator templates for strings