return cast(R)value не катит?

"вредные советы"

короче, возвращаясь к старой теме. Максимально костылизирую.

с -m64 работает?

что бы постоянно ручками не прописывать (скрин), хочется автоматизировать это хозяйство

Ну указывай возвращаемый тип как еще один параметр шаблона, так же можно?

Ты же знаешь в каждой строке какой тип должен вернуться

"Максимально костылизирую."

Я правильно понимаю что лень руками прописывать тип this.td_id?

Я так и не понял что требуется

)))

Я правильно понимаю что лень руками прописывать тип this.td_id?

Точно!

в таком случае легче ссылку кинуть.

Используй обьявление через type(thisCall(....)) td_id;

Или trait(ReturnType, thisCall))

Не могу с мобильника попробовать

Учитывая, что возвращаемое значение не является частью сигнатуры, в большинстве случаев хватит auto.

https://run.dlang.io/is/se9e1F

ReturnType!(f!(int)) id; сокращается до int id;

или так https://run.dlang.io/is/ElDZUR

ReturnType!(f!(int)) id; сокращается до int id;

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

Пример был не очень наглядным. Второй лучше.

CTFE не знает границ?

Есть одна смешная - не может double в строку перевести в CTFE. А в остальном все действительно очень круто, у меня щас в компайл-тайме проводятся символьные раcсчеты с дифференцированием, обращением матриц, упрощением тригонометрии и т.п., а из результата генерится D код и вставляется через mixin.

магия а почему double не может? может на форуме пожаловаться - авось в следующем релизе запилят как с pow было )

Я глубоко не копал причину. Но выдает прям заготовленное сообщение, что вот именно это format в CTFE не могёт.

Небольшой бенчмарк сериализации данных в D. Принимали участие std.json cerealed msgpack-d drmi.sbin Jsonizer + std.json Победителем в нашей номинации "Лучший" стал Сerealed. Поздравляем его! Немного отстал MsgPack. Поздравим его со вторым местом. Спасибо за внимание" Отчётик mega.nz/#!H6pX3a7B!63rcZr4XzbPRqDGryRzUpCkgK0tnOvI3PBn_wIUTHUA https://github.com/DarkRiDDeR/test-d-speed-serialization

Если вам нужна скорость просто не юзайте json

а asdf?

они вроде хвастались типа оч быстрое всё у них )

https://github.com/tamediadigital/asdf

Если вам нужна скорость просто не юзайте json

А что ещё?)) xml?

А что ещё?)) xml?

у вас осталась последняя попытка!

А что ещё?)) xml?

protobuf?

только не XML ))

bson

тогда уж сразу протобаф )

тогда уж сразу протобаф )

они не взаимозаменяемы же

Ну не проблема сделать самому разбор/упаковку в какой-то свой бинарный протокол

Суть в поддержке этого протокола с другой стороны (если это какая-то коммуникация)

Поддержка json есть практически везде

Пусть он и не очень быстрый, но он распространенный

а на счет протобафа - это крутая штука, но есть один нюанс. Ты им не упакуешь свою структуру, а только его

Ну не проблема сделать самому разбор/упаковку в какой-то свой бинарный протокол

велосипединг

А при таком раскладе ты попадаешь на мапинг своей структуры на их

велосипединг

И что?

Поддержка json есть практически везде

что ты поднимаешь под "везде"?

в процессорах интел поддержки json нет

И что?

ой всё

велосипединг

Если тебе нужна скорость и задача звучит как: сохранения состояния

Если тебе нужна скорость и задача звучит как: сохранения состояния

значит ты пишешь велосипед

что ты поднимаешь под "везде"?

Другие языки

значит ты пишешь велосипед

Конечно! Но он быстрый

Другие языки

в языках поддержки протоколов тоже обычно нет, исключение - бейсик, наверно

Конечно! Но он быстрый

но глючный

в языках поддержки протоколов тоже обычно нет, исключение - бейсик, наверно

Я имею ввиду есть либы поддерживающие json практически на всех языках

но глючный

Ну если ты пишешь глючно - то да

Я имею ввиду есть либы поддерживающие json практически на всех языках

это и к bson относится libbson-1.0-0 - Library to parse and generate BSON documents - runtime files libbson-dev - Library to parse and generate BSON documents - dev files

поднял тему холивара ))

это и к bson относится libbson-1.0-0 - Library to parse and generate BSON documents - runtime files libbson-dev - Library to parse and generate BSON documents - dev files

Возможно

Возможно

100% точно

поднял тему холивара ))

asdf проверишь?) интересно

да. Быстро его воткнуть ))

в тесты

Если вам нужна скорость просто не юзайте json

std.json это не сериализатор

так что сравнивали тёплое с мягким немношк

https://stackoverflow.com/questions/8186912/convert-a-struct-to-a-byte-or-void-in-d/8187047

ERROR: S client not available

Думаю это будет быстрее всего)))

Ну, если оно работает

Я не проверял

Ну, если оно работает

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

так что сравнивали тёплое с мягким немношк

есть такое )) JSON всё равно можно использовать наподобие сериализации данных. Была интересна его скорость работы

Если нужно сохранить состояние, а потом его развернуть - норм

добавил тесты на LDC для ASDF и ProtoBuf https://github.com/DarkRiDDeR/test-d-speed-serialization ProtoBuf по скорости при десериализации всех рвёт, однако по скорости сериализации даже уступает некоторым решениям. Не очень гибок ASDF по скорости лучше стандартных решений Json. Однако сериализатор для структуры Long сломался и в тесты с ней не попал (сильно не разбирался) CEREALED пока что наиболее быстрый и гибкий пока по моим тестам

есть такое )) JSON всё равно можно использовать наподобие сериализации данных. Была интересна его скорость работы

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

добавил тесты на LDC для ASDF и ProtoBuf https://github.com/DarkRiDDeR/test-d-speed-serialization ProtoBuf по скорости при десериализации всех рвёт, однако по скорости сериализации даже уступает некоторым решениям. Не очень гибок ASDF по скорости лучше стандартных решений Json. Однако сериализатор для структуры Long сломался и в тесты с ней не попал (сильно не разбирался) CEREALED пока что наиболее быстрый и гибкий пока по моим тестам

Чем не гибок в твоем понимании?

В cerealed даже объекты классов можно сериализовать и десериализовать. У ASDF допустим такого нет

А вообще - делаешь сериализатор через DI и не паришься)

Не взлетело - заменил

Так cerealed это же бинарная сериализация

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

даже просто JSON попал

цель была оценить скорость работы, размер сериализованных данных, ну и гибкость ))

Чего ребята, экономите на спичках?)

Вечером $100 налево, $100 направо, в утром: "где мои $200!!?"

Не, неудачное сравнение

Вечером $100 налево, $100 направо, в утром: "где мои $200!!?"

херасе спички у вас

Чего ребята, экономите на спичках?)

А вы перестаньте дома из спичек строить.

Вечером $100 налево, $100 направо, в утром: "где мои $200!!?"

Скорее, вечером $99 налево, $99 направо, а утром: "зато $2 сэкономил!"

Чего ребята, экономите на спичках?)

Удваиваю

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

а тут куда ни плюнь в текст попадёшь

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

?

Скорее, вечером $99 налево, $99 направо, а утром: "зато $2 сэкономил!"

Куришь небось?

? таким темпом реально скоро будет уходить столько на сигареты

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

Дык для локальных данных JSON не лучшее решение. А вот общаться им с другим софтом - лучше и не придумаешь, особенно если надо иногда руками редачить

Куришь небось?

Мануалы считаются?

Кубинские мануалы куришь?

Помнится мне, в Dшной группе ВК, человек спрашивал, как ему сделать копию объекта. Кто-то посоветовал сериализовать в JSON и сразу десериализовать.