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

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

Я ваще на самом деле против того чтобы все начинали писать объектики в потоки

Я ваще на самом деле против того чтобы все начинали писать объектики в потоки

А есть хорошие реализации объектных потоков?

Ну будут наверн

Ща завезут с++26

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

это точно безопасно?

Ща завезут с++26

Просто корутины во многом должны быть ими, но пока там ручник

Я не понял

А мне надо именно объектные потоки

Ну корутины очень близки к объектным потокам

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

Посмотри их "zero copy" streams

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

zero copy стримс это как? есть массив указателей и кол-ва байт по указателю?

Хз, но вот так они их называют :)

это не кеш френдли

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

имхо тема категорически не раскрыта

Короче, стрим это типа штото куда ты пишешь и всё, оно двигает каретку.

короч стрим инвазивный а буфир нет, стрим содержит каретку и сам её двигает, у буфера нет каретки и каждый кто хочет сам заводит каретку и её двигает извне

гениально!

У мну есть буфер в два байта. Которые надо заслать. Как средствами c++ записать туда uint16?

У мну есть буфер в два байта. Которые надо заслать. Как средствами c++ записать туда uint16?

Взять нижний и верхний

Точно не memcpy если ты об этом

Точно не memcpy если ты об этом

Ойли?

Берите мемсру, и не парьтесь

А теперь на структуру{uint64_t; uint8_t}

если не проверять endianess то и memcpy и взять нижний и верхний приведут к одному результату

И пиши в свой буффер

Удачи

но разному на разных компах

Да-да, а я не хочу по разному. Потому и говорю, может кошерный вариант будет? :)))

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

Разница может быть такая, я пишу сложную структуру. Могу просто зарезервировать место для записи размера и потом записать или пишу потоком.

Либо двойной обход с расчетом размера сериализации, который может быть сравним с самой сериализацией или так вот.

ЯННП

в сериализации самое сложное - написать сериализацию

если надо что-то параллелить это решается на уровне типов данных по жизни

в сериализации самое сложное - написать сериализацию

Как правило она уже написана, protobuf, json, asn, xml...

ну... почти

остается только данные подогнать как они хотят

остается только данные подогнать как они хотят

Да, например записать в network byte order число. В один байт, в два, в три..

остается только данные подогнать как они хотят

И они иногда это ты например.

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

со вводом сложнее

и если перед выводом надо еще надо картинки прокодировать, это совершенно точно делает не резервированием места в выводном буфере с последующим запуском потока :)

со вводом сложнее

Не всегда, можно точно так же написать намного более простой по сравнению с istream парсер готового буфера.

потоковый ввод это про бинарные форматы

В общем если говорить про ввод, там тоже все парсеры это обертки над string_ref, не более

Ну если ввод бинарный - да

А, это я тоже про упрощённые парсеры...

Которые не умеют через глубинные жопы требовать очередного ввода.

В общем есть streams, которые по большому счету шикарны.

Но мне всегда надо глубже ;(

Вывести в строку thread id

Работа с датами ...

я когда-нибудь обязательно доделаю свой сериализованный велосипед :)

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

есть пруф что каша динамической неопределенности типов не должна быть инкапсулирована внутри класса-обертки представляющей конкретный тип и с RAII на борту?

Например std::function

у текущего io стека как раз торчит все наружу, как в джаве сишарпе или кьюте, но это чтото из 90-х\

есть пруф что каша динамической неопределенности типов не должна быть инкапсулирована внутри класса-обертки представляющей конкретный тип и с RAII на борту?

Предлагаешь обертку на каждый unique_ptr<interface> писать? Вроде, это избыточно Другое дело, что типоудалялки под контракты вещь, похоже, правильная

есть пруф что каша динамической неопределенности типов не должна быть инкапсулирована внутри класса-обертки представляющей конкретный тип и с RAII на борту?

Никакого rai не подразумевается, интерфейс чистая обёртка.

Предлагаешь обертку на каждый unique_ptr<interface> писать? Вроде, это избыточно Другое дело, что типоудалялки под контракты вещь, похоже, правильная

да, предлагаю

но короче какаято часть логики выйдет как раз в эту обертку

а виртуальными останутся какието типа трейтсы и данные

да, предлагаю

Тут вопрос, юзеровская реализация по этому контракту конечная или промежуточная, видимо. Сложно, не могу формализовать

Т.е. раcтипизированный xml-источник данных вот просто хочется возвращать как unique_ptr<источник_данных>

Видимо, std::function возникает, когда тебе нужно растипизировать и сохранить контракт одновременно

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

модули сделай сначала, потом будем думать, когда не наследовать

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

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

от вас эмбеддедщики бегут в страхе, увидев cout

без стека ио намного проще жить

а вообще имхо будущее за отглагольным кодированием и внешними предикатами

ООП тупиковое направление

в части инкапсуляции методов

надо переходить на FORTH

Хз, никогда не зависел от того что введет пользователь. Хотя обычно это конфиги...

Я тут выше по деревьям чот высказался, но вот например gcc перебалансировку в либу тащит, а llvm нет.

надо переходить на FORTH

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

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

так кажется про все можно сказать

так кажется про все можно сказать

tag dispatching это на самом деле почти то, что надо

еще бы пространства имен для всяких swap разрешили, вообще было бы найс

Наркоман)

Наркоман)

ну я не знаю, какими сумеречными гениями надо быть, чтобы в случае qualified name lookup запретить перегрузку универсальных методов

using std::swap; //I LOVE THIS LANGUAGE swap(a, b);

а вообще имхо будущее за отглагольным кодированием и внешними предикатами

Imho The future is in silver bullet development

Imho The future is in silver bullet development

тяжело

The portion of the declaration preceding [ applies to the hidden variable e, not to the introduced identifiers. int a = 1, b = 2; const auto& [x, y] = std::tie(a, b); // x and y are of type int& auto [z, w] = std::tie(a, b); // z and w are still of type int& assert(&z == &a); // passes