от неё все ждут разного, кто-то сериализации, кто-то метаклассов, а кто-то констекспровых проверок for (f : this->functions) assert(is_snake_case(f.name));

assert is_snake_case это фашизм :)

фашизм просто нужно правильно готовить, тогда от него сплошная выгода и качественный код получается ^.^ но этой проверке место где-то в стайл-чекере, да, от рефлексии в компилтайме скорее потребуется assert(is_noexcept(f)), и прочее assert(is_pure_virtual(f) && variables.empty())

Господа! Подскажите как реализуется Delay Load library совместно с mingw w64

чот информации по этому поводу вообще ноль в гугле

Этому место конечно в священных войнах, но вообще без войн было бы интересно узнать, статистически, программисты C++ продолжают пользоваться snake_case или выше уровнем только Camel или смесь?

на заводах и нии полно плюсовиков, в Самаре полно заводов и нии, все сходится

Блин, я по поводу плюсовиков с заводов ... ОЧЕНЬ ЗЛОЙ В ПОСЛЕДНЕЕ ВРЕМЯ!

Этому место конечно в священных войнах, но вообще без войн было бы интересно узнать, статистически, программисты C++ продолжают пользоваться snake_case или выше уровнем только Camel или смесь?

snake_case

хотя со временем он кажется всё более и более ужасным

Этому место конечно в священных войнах, но вообще без войн было бы интересно узнать, статистически, программисты C++ продолжают пользоваться snake_case или выше уровнем только Camel или смесь?

мне кажется я даже где-то видел статистику на эту тему, на реддите/медиуме/слэшдоте

Qt программисты - не с++ программисты

интересное заявление

snake_case

Я так люблю snake case, но всё время пишу в camel , как на проклятой Java!

Qt программисты - не с++ программисты

Давай так: Не все Qt программисты - с++ программисты!

Этому место конечно в священных войнах, но вообще без войн было бы интересно узнать, статистически, программисты C++ продолжают пользоваться snake_case или выше уровнем только Camel или смесь?

Венгерская нотация)

Давай так: Не все Qt программисты - с++ программисты!

А то я теперь вот на Qt как раз программирую... Ну ты понял вобщем!

Этому место конечно в священных войнах, но вообще без войн было бы интересно узнать, статистически, программисты C++ продолжают пользоваться snake_case или выше уровнем только Camel или смесь?

camelCase в названиях методов , camelCase и венгерская нотация в членах класса, snake_case - в локальных переменных.

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

PascalCase one love❤️

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

plain-old-data?

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

Никак.

Есть POD — Plain Old Data, может, оно?

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

StandartLayout?

camelCaseIsTrue()

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

Нет термина

Ну как в других языках - проходишься по всем членам и пишешь их в поток. Без рефлексии ты только с помощью какой нибудь магии типа magic-get Такое сможешь провернуть и то только для POD типов.

старый холивар) сейчас до изучаю все сущств. средства сериализации и допилю свой костыль, без макросов

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

trivially copyable?

trivially copyable?

Во, точно, спасибо!

Есть POD — Plain Old Data, может, оно?

Нет, не оно. POD с указателем внутри на свою часть -- и привет!

trivially copyable?

этого не достаточно же!

trivially copyable?

Нененене это тоже не то

Нет, не оно. POD с указателем внутри на свою часть -- и привет!

Согласен, да.

ну видимо в общем случае по типу этого нельзя понять, не обладая высокоуровневой информацией о его устройстве

этого не достаточно же!

Пишут, достаточно. https://en.cppreference.com/w/cpp/types/is_trivially_copyable "Objects of trivially-copyable types are the only C++ objects that may be safely copied with std::memcpy"

— А эти ягоды можно есть? — Можно. Только потом умрёшь.

Можно и не умереть, если правильно приготовить.

Интересно, а как же реализовать рефлексию без макросов?

Интересно, а как же реализовать рефлексию без макросов?

Пока что только дополнительным препроцессингом, к сожалению.

compile-time рефлексии я жду едва ли не больше, чем модулей)

написать свой парсер, как в го генерики делают, генерящий cpp с информацией о типах и вставляющий статический указатель на инфо с рефлексией в каждый класс

но при этом требуется дополнительная хромосома

Пишут, достаточно. https://en.cppreference.com/w/cpp/types/is_trivially_copyable "Objects of trivially-copyable types are the only C++ objects that may be safely copied with std::memcpy"

Это он в смысле С++ копируем через memcpy. А в семантическом смысле -- фиг. В Qt на этом собаку съели, там свой термин.

Блин, никто никуда ничего не сериализует. И все ждут рефлексии.

ЗАбыл какой, но это и не важно

написать свой парсер, как в го генерики делают, генерящий cpp с информацией о типах и вставляющий статический указатель на инфо с рефлексией в каждый класс

Впихнуть в трансляцию кода дополнительный шаг, вы об этом?

я жду когда по америке бахнем

точно, клэнг же поддерживает плагины

точно, клэнг же поддерживает плагины

Надо глянуть есть ли такое в гцц-шке

написать к кленгу плагин, добавляющий рефлексию, звезды на гитхабе

Это он в смысле С++ копируем через memcpy. А в семантическом смысле -- фиг. В Qt на этом собаку съели, там свой термин.

Хм. Почему же в семантическом нет?

гцц вроде бы не расширяемый монолит

гцц вроде бы не расширяемый монолит

Печально если так

Это он в смысле С++ копируем через memcpy. А в семантическом смысле -- фиг. В Qt на этом собаку съели, там свой термин.

В моём понятии, семантика "побитово скопировать" - это получить внешне точно такой же объект, но в другом месте.

Народ, не подскажете, как называется объект (свойство объекта), который можно побитово скопировать без проблем?

Хотя же ему не понятно что и надо было...

Хотя же ему не понятно что и надо было...

Вообще - мне как раз нужен был trivially copyable, но из за того, что я не знал как задать вопрос - задал его криво и получил холивар

Вообще - мне как раз нужен был trivially copyable, но из за того, что я не знал как задать вопрос - задал его криво и получил холивар

Главное — не пытаться теперь переносить этот объект между платформами.

Боже упаси. При необходимости переноса лучше каким-нибудь protobuf воспользоваться или, чтобы не париться какой-нибудь простеньгий json протокол прикрутить для начала, а потом см. доклад с CoLaboratory о переходе на бинарные протоколы

Впихнуть в трансляцию кода дополнительный шаг, вы об этом?

Ага, как делает это MOC.

написать к кленгу плагин, добавляющий рефлексию, звезды на гитхабе

Поискал, и такое уже есть)

шиком было бы написать это на го, все сплюплюсеры были бы зотроллены

интересно, в чате джавы смеются над с++ и рефлексию через макросы препроцессора?

В этом вашем го даже темплейтов нет =)

интересно, в чате джавы смеются над с++ и рефлексию через макросы препроцессора?

не только в чатах ;)

Это и правда уже даже не смешно. 2018 год на дворе, как никак.

До сих пор никак не написать ни одной внятной ОРМ и ни одного внятного сериализатора.

Компайл тайм рефлексия вообще не спасет.

Для того же json она проецирует ограничения языка на именования ключей.

Рефлексия это одно, а ее использование это другое.

И тем более виртуализация использования всех этих type info.

Если извращенный json почему-то хочется запилить в структуру, в которой поля бы назывались так же - то да, не спасёт. А если хочется просто сериализовать/десеривализовать написанную структуру — то очень даже.

у вас вроде есть теперь что-то вроде аннотаций [["json_key"]]

вот через них джсон и задавай, если не можешь через название переменной

у вас вроде есть теперь что-то вроде аннотаций [["json_key"]]

У нас лазутчик?

у вас вроде есть теперь что-то вроде аннотаций [["json_key"]]

Понеслась, см. шарп атрибуты.

у тебя есть решение лучше? буфер?

Не надо, сериализация это не обязательно рефлексия и прочее. Как то и без рефлексии умудряются сетевые протоколы писать.

На уб

как будто с рефлексией уб исчезнет, писать то будут все те же люди на все том же языке

как будто с рефлексией уб исчезнет, писать то будут все те же люди на все том же языке

Исчезнет, можно будет сделать ваши протоколы и выписывать контент подов в зависимости от эндианнесс, поэлементно, рекурсивно

Сейчас это разве что magic_get

у тебя есть решение лучше? буфер?

Буфер отдельная тема, на неё просто никто не отреагировал. Видимо мало велосипедистов :) всем збс tostring, а уж про то что в буфер писать, либыжесть.

в буфер диды писали, когда 640 КБайт на все хватало, теперь людям это не нравится

поэтому не отреагировали

Что за буфер?

у вас вроде есть теперь что-то вроде аннотаций [["json_key"]]

https://t.me/xthon/911

Компайл тайм рефлексия вообще не спасет.

?

Что за буфер?

Как идея, стандартизировать интерфейс динамического byte buffer. Даже не интерфейс, обёртка. Минимализм полный, в духе string_view. Начало, позиция, конец. И виртуальный ресайз.

span?

у вас вроде есть теперь что-то вроде аннотаций [["json_key"]]

Это вроде не то что в шарпе и джаве, то есть это обычно хинты

Вот у меня сейчас куча кода под генераторами, и первая причина, по которой эти генераторы появились вообще, было отсутствие compile time информации о существующих типах

Как идея, стандартизировать интерфейс динамического byte buffer. Даже не интерфейс, обёртка. Минимализм полный, в духе string_view. Начало, позиция, конец. И виртуальный ресайз.

В чём он динамический?

Как идея, стандартизировать интерфейс динамического byte buffer. Даже не интерфейс, обёртка. Минимализм полный, в духе string_view. Начало, позиция, конец. И виртуальный ресайз.

Виртуальный полиморфизм - плохо

Это вроде не то что в шарпе и джаве, то есть это обычно хинты

Это атрибуты момента компиляции

Как идея, стандартизировать интерфейс динамического byte buffer. Даже не интерфейс, обёртка. Минимализм полный, в духе string_view. Начало, позиция, конец. И виртуальный ресайз.

std::vector<byte> напоминает...

Это вроде не то что в шарпе и джаве, то есть это обычно хинты

https://en.cppreference.com/w/cpp/language/attributes

std::vector<byte> напоминает...

+

Виртуальный полиморфизм - плохо

Вам не угодить, полиморфный виртуализм небось тоже не подойдёт?

Виртуальный полиморфизм - плохо

Не плохо. Интерфейс минимален. В минимуме ему соответствует просто массив байтов.

std::vector<byte> напоминает...

хотя плюсам несколько не хватает long_buffer, как вектор, только не более условного мегабайта страницы (отказ от гарантии последовательности в памяти)

Вам не угодить, полиморфный виртуализм небось тоже не подойдёт?

Он хочет более простой streambuf, но стримбуф говно как и весь ио стек