Исследовательский проект, можно понять много всякого, пока он делается. Так же спрашивали «на кой черт пыжиться kernel CLang-ом собирать, есть же GCC». Узнать что-то новое о наших инструментах)
Ну и возможно кому-то на практике пригодится тулза которая конвертит исходники на C, например, какой-нибудь видео encoder, скажем, AV1 ;)
Я аж настолько удивился качеству статьи что полез проматывать в начало, не пропустил ли плашку «перевод». Не пропустил.
Спасибо.
Теперь по теме: немного не понятно, в случае если мы создаем копию и потом ее лениво обходим, в чем преимущество? Проще фильтрация? Эффективность-то получается как в старом коде, если не хуже.
Лучше знаете что, уберите весь код вообще на какойто сервис типа хитхаба, и в конце статьи под спойлером ссылку с дисклеймером типа:
НЕ ВХОДИТЬ, АХТУНГ! Писал не программист, к прочтению не рекомендуется, только запускать как пример!
А в статье оставить пару абзацев описывающих только идею.
Я было начал вам в личку писать комментарий «что именно не так», но быстро утомился… извините :(
8.4 Принимая участие в Конкурсе, Участник дает свое согласие на использование Организатором, в том числе в рекламных целях в любых средствах массовой информации, предоставленной им информации, включая его персональные и иные данные (фамилия, имя, город проживания), сведений о полученном Призе без получения предварительного согласия Участника и уведомления Организатором, а так же без выплаты какого-либо вознаграждения.
Да, давайте пойдем сливать карму медиа аккаунту на хабре, и писать в личку гадости человеку, который вообще скорее всего интерн или стажер какой-нибудь и обязан отвечать шаблонно на все эти SMM штуки. Очень умно и взросло. К чему этот ваш коммент? Те кто «рулит» рамблером, я на 100% уверен, хабр даже не читают.
Двойственное ощущение от статьи.
Прежде всего не покидает ощущение, что цель «а давайте поиспользуем новых фич» была превыше «а давайте это все будет читаемо и расширяемо».
Почему-то в статье никак не упомянуты существующие реализации, хотя бы обзорно как-то, например Boost.Serialization, Protobuf, QDataStream, etc, и хотя бы какое-то сравнение, чем наш «велосипед» лучше/хуже их (если честно, вообще не вижу по какому пункту он лучше. Ну ладно, по пункту «не надо тащить буст», объективно, лучше.).
Так же вызывают вопросы многие детали реализации.
// for support a std::deque we forced to use a std::distance()
const auto len = static_cast<std::uint16_t>(
std::distance(value.cbegin(), value.cend()));
std::size — не то?
std::ostream по дефолту не использует исключения. Неплохо бы проверять вообще результаты записи, например.
auto stream_reader<T, void>::read(std::istream& is, T& value)
Почему не аллоцировать весь контейнер сразу, например, чтобы не делать временные значения и push_back?
stream_reader<std::string>::write
Писатель читает, читатель пишет :) все логично.
const auto len = static_cast<typename stream_writer::size_type>(value.size());
os.write(reinterpret_cast<const char*>(&len), sizeof(len));
совместимость сериализуемого size_t между 32 и 64 платформами?
Может быть учет ByteOrder в сериализации?
Да не, и так сойдет.
В общем ваш пример приложения хорош для объяснения как можно применять новые средства языка, но не для полноценной переносимой сериализации.
то читать его удобно, но неудобно вносить изменения в скрипт.
Ну видимо всё и сводится к расхождению мнений по поводу этого утверждения :)
Тут пошли субъективные вещи, поэтому привести какие-то доводы более уже не смогу. Пусть так. Мне в какой-нибудь cmake.in.h (либо в список значений где-нибудь в json или cmake) вносить изменения более чем удобно.
Не буду использовать циркулярную пилу, буду использовать канцелярский нож. Им я хотя бы не отпилю себе руку.
C++ дает контроль на всех уровнях над кодом. Да, он далеко не идеален, и за такой контроль приходится расплачиваться целым букетом недостатков (а так как он дает еще и обратную совместимость (в т.ч. с С), то там еще букет расплаты приходит, и это все перемножается в немыслимых комбинациях).
Ваша мотивация понятна, но в основном С++ избегают не из-за страха инвалидности.
А мне понравилась статья. Поэтапное раскрытие мысли с небольшими примерами кода, а не так что под спойлером простыня на 2 тысячи строк, которая иллюстрирует сразу всё.
Прям вдохновило пойти и проверить те места, где я использовал shared_from_this.
Ну и очень порадовал ответ на самый распространенный обычный вопрос «так никто не пишет! по крайней мере в библиотеках написанных профи!»
Не очень понимаю. Обычно правило на обновление кодогенерации прописано как зависимое от источника этой генерации)
В моем случае действия такие:
— дописал нужный enum где-то в конфиге;
— нажал build / build (target)
все собралось. Т.е. «запуск генератора» никак особо от компиляции не выделяется. Да, вы сборку два раза запускаете, если надо заприменять уже новые значения, но это знаете, минимальное неудобство, имхо.
Главный вопрос, если вы все равно генерируете xml файл prebuild скриптом, почему так же не генерировать ими и хедеры с нужными enum-ами, функциями и тп?
Никогда никакой боли с автогенерацией подобного кода в том же CMake не имел :)
Поэтому «компьютерщики» любят асинхронное общение — IM вместо личных встреч
Зависит от компании. Я работаю в IT компании, тут IM мало кто любит, почти все предпочитают лично подойти и поговорить по любому поводу. Ну либо email. Так сложилось. сперва подгорало знатно)
(Look into comment section too)
Ну и возможно кому-то на практике пригодится тулза которая конвертит исходники на C, например, какой-нибудь видео encoder, скажем, AV1 ;)
Честно говоря, после просмотра видео прохождения, не тянет на «самую худшую игру». По крайней мере она не худшая с точки зрения геймплея это точно.
Спасибо.
Теперь по теме: немного не понятно, в случае если мы создаем копию и потом ее лениво обходим, в чем преимущество? Проще фильтрация? Эффективность-то получается как в старом коде, если не хуже.
НЕ ВХОДИТЬ, АХТУНГ! Писал не программист, к прочтению не рекомендуется, только запускать как пример!
А в статье оставить пару абзацев описывающих только идею.
Я было начал вам в личку писать комментарий «что именно не так», но быстро утомился… извините :(
Простите, нет. Это дно)
Про size — ну так да, у него ж ровно такая же реализация через distance емнип.
Прежде всего не покидает ощущение, что цель «а давайте поиспользуем новых фич» была превыше «а давайте это все будет читаемо и расширяемо».
Почему-то в статье никак не упомянуты существующие реализации, хотя бы обзорно как-то, например Boost.Serialization, Protobuf, QDataStream, etc, и хотя бы какое-то сравнение, чем наш «велосипед» лучше/хуже их (если честно, вообще не вижу по какому пункту он лучше. Ну ладно, по пункту «не надо тащить буст», объективно, лучше.).
Так же вызывают вопросы многие детали реализации.
// for support a std::deque we forced to use a std::distance()
const auto len = static_cast<std::uint16_t>(
std::distance(value.cbegin(), value.cend()));
std::size — не то?
std::ostream по дефолту не использует исключения. Неплохо бы проверять вообще результаты записи, например.
auto stream_reader<T, void>::read(std::istream& is, T& value)Почему не аллоцировать весь контейнер сразу, например, чтобы не делать временные значения и push_back?
stream_reader<std::string>::writeПисатель читает, читатель пишет :) все логично.
совместимость сериализуемого size_t между 32 и 64 платформами?
Может быть учет ByteOrder в сериализации?
Да не, и так сойдет.
В общем ваш пример приложения хорош для объяснения как можно применять новые средства языка, но не для полноценной переносимой сериализации.
Ну видимо всё и сводится к расхождению мнений по поводу этого утверждения :)
Тут пошли субъективные вещи, поэтому привести какие-то доводы более уже не смогу. Пусть так. Мне в какой-нибудь cmake.in.h (либо в список значений где-нибудь в json или cmake) вносить изменения более чем удобно.
C++ дает контроль на всех уровнях над кодом. Да, он далеко не идеален, и за такой контроль приходится расплачиваться целым букетом недостатков (а так как он дает еще и обратную совместимость (в т.ч. с С), то там еще букет расплаты приходит, и это все перемножается в немыслимых комбинациях).
Ваша мотивация понятна, но в основном С++ избегают не из-за страха инвалидности.
Прям вдохновило пойти и проверить те места, где я использовал shared_from_this.
Ну и очень порадовал ответ на самый распространенный обычный вопрос «так никто не пишет! по крайней мере в библиотеках написанных профи!»
В моем случае действия такие:
— дописал нужный enum где-то в конфиге;
— нажал build / build (target)
все собралось. Т.е. «запуск генератора» никак особо от компиляции не выделяется. Да, вы сборку два раза запускаете, если надо заприменять уже новые значения, но это знаете, минимальное неудобство, имхо.
Никогда никакой боли с автогенерацией подобного кода в том же CMake не имел :)
Зависит от компании. Я работаю в IT компании, тут IM мало кто любит, почти все предпочитают лично подойти и поговорить по любому поводу. Ну либо email. Так сложилось. сперва подгорало знатно)