Здравствуйте, PM, Вы писали:

PM>Значения типа `size_t` (который может быть `uint64_t`) обрезаются до `uint32_t`
я помню, что это было сделано осознано, так как у нас в проекте просто не может быть таких размеров строк/контейнеров.
и да, по-хорошему — нужно исправить.

PM>Если 8 байт для хранения нулевой дины кажется расточительным, надо смотреть на кодирование значения переменной длиной. Но есть шанс переместиться со 2-го места в середину списка в замерах скорости, к тем библиотекам, которые это уже делают.
сейчас сделаю и отпишусь о замерах...

PM>Вообще тема длины строк и количества элементов в сериализуемых контейнерах в YAS не раскрыта. Как реагировать на строку длиной, например, 2^63?
та понятно =)

PM>Сейчас, конечно, всё работает и так, потому что устройство строки во всех 3-х стандартных библиотеках более-менее одинаково. Но кто знает, как оно будет в будущем.
угу.

Здравствуйте, niXman, Вы писали:

VTT>>Студия 2015: 77 предупреждений
VTT>>mingw (g++ 5.1): 356 предупреждений
VTT>>clang 3.9: 345 предупреждений
X>приведите лог хоть какого-то из компиляторов. и команду сборки. спасибо.
лог студии (32bit, /W4)
лог mingw

g++ -s -o yas_test.exe -std=c++14 -O3 -g0 -fno-rtti -fomit-frame-pointer -fstrict-enums -fshort-wchar -fstrict-aliasing -fvisibility=hidden -fmessage-length=0 -Wall -Wextra -Wconversion -Wold-style-cast -Wpedantic -Wno-unknown-pragmas -I"../../include" -DRELEASE -DNDEBUG main.cpp -Wl,--subsystem,windows -shared-libstdc++ -shared-libgcc

лог clang

"C:\Program Files\LLVM\bin\clang.exe" -o yas.cl.exe -std=c++14 -O3 -g0 -fms-compatibility-version=19 -fcxx-exceptions -fomit-frame-pointer -fstrict-enums -fshort-wchar -fvisibility=hidden -fmessage-length=0 -Wall -Wextra -Wconversion -Wpedantic -Wold-style-cast -Wno-unknown-pragmas -DRELEASE -DNDEBUG -I"../../include" main.cpp

VTT>>1) большие (а в наше время не особо большие) данные молча криво обрабатываются?
X>не поняд...

ar.write((std::uint32_t)string.length());// допустим длина 4Гб 16 Б, верхние байты будут отброшены, длина будет записана 16 Б
ar.write(&string[0], string.length()); // а тут запишутся все 4Гб 16 Б, при чтении из них будет прочитано только 16 Б, а остальные интерпретированы как продолжение архива

VTT>>2) &string[0] — это реально стремно
X>иначе придется константность снимать с c_str(). какие еще варианты?
когда строчка сохраняется — можно спокойно использовать data() const

if(!string.empty())
{
  ar.write(string.data(), string.size());
}

когда извлекается — то при использовании современного компилятора по идее можно воспользоваться data() не const

string.resize(size);
if(!string.empty())
{
  ar.read(string.data(), size);
}

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

VTT>>ЗЫ не стоит прописывать в решениях полные пути типа D:\msys\home\niXman\
X>а где ты нашел это?
В студийных проектах инклюды.

Здравствуйте, PM, Вы писали:

PM>Для сериализации длины чего-либо часто используется простейшее кодирование значения называемое varint.
думаю, сделать выбор способа хранения целых путем условной компиляции. по умолчанию пусть используется uint64, а если нужна компактность — включаем.
варианты?

Здравствуйте, VTT, Вы писали:

VTT>лог студии (32bit, /W4)
VTT>лог mingw
VTT>лог clang аналогичные настройки
понял, исправлю.
спасибо!

VTT>когда строчка сохраняется — можно спокойно использовать data() const
VTT>

if(!string.empty())
VTT>{
VTT>  ar.write(string.data(), string.size());
VTT>}

VTT>когда извлекается — то при использовании современного компилятора по идее можно воспользоваться data() не const
VTT>

string.resize(size);
VTT>if(!string.empty())
VTT>{
VTT>  ar.read(string.data(), size);
VTT>}

VTT>ну а при использовании более старых — придется задействовать промежуточный буффер.
VTT>Конечно желание избежать такого бесполезного транжирства понятно, да и текущий код вроде как работает, но тем не менее...
VTT>Как минимум, не стоит дергать эти методы, когда строка пустая.
тогда, наверное, лучше использовать 'data()' и при необходимости 'const_cast()' %)

VTT>В студийных проектах инклюды.
аа, возможно... я эти проекты уже наверное несколько лет не трогал %)

Здравствуйте, VTT, Вы писали:
VTT>лог mingw
вот не понимаю, как мне победить этот ворнинг?:

../../include/yas/detail/io/information.hpp:69:13: warning: conversion to 'unsigned char:3' from 'uint8_t {aka unsigned char}' may alter its value [-Wconversion]

Здравствуйте, niXman, Вы писали:

PM>>Для сериализации длины чего-либо часто используется простейшее кодирование значения называемое varint.
X>думаю, сделать выбор способа хранения целых путем условной компиляции. по умолчанию пусть используется uint64, а если нужна компактность — включаем.
X>варианты?

Они всегда есть

Вариант 2: добавить параметр LengthType = size_t в шаблон binary_[i|o]archive. Добавить в библиотеку тип varint, которые можно было бы использовать в качестве LengthType.

Вариант 3: перенести это в рантайм. Емнип, у тебя же в заголовке бинарного архива есть archive_header, там можно хранить флаг компактности. И можно использовать uint32 если установлен флаг 32-битности в этом заголовке.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, VTT, Вы писали:
VTT>>лог mingw
X>вот не понимаю, как мне победить этот ворнинг?:
X>

X>../../include/yas/detail/io/information.hpp:69:13: warning: conversion to 'unsigned char:3' from 'uint8_t {aka unsigned char}' may alter its value [-Wconversion]

http://stackoverflow.com/questions/10191886/c-bit-fields-and-wconversion

Здравствуйте, PM, Вы писали:

PM>Вариант 2: добавить параметр LengthType = size_t в шаблон binary_[i|o]archive. Добавить в библиотеку тип varint, которые можно было бы использовать в качестве LengthType.
тоже вариант.

PM>Вариант 3: перенести это в рантайм. Емнип, у тебя же в заголовке бинарного архива есть archive_header, там можно хранить флаг компактности. И можно использовать uint32 если установлен флаг 32-битности в этом заголовке.
этот вариант мне не нравится

Здравствуйте, niXman, Вы писали:

PM>>Для сериализации длины чего-либо часто используется простейшее кодирование значения называемое varint.
X>думаю, сделать выбор способа хранения целых путем условной компиляции. по умолчанию пусть используется uint64, а если нужна компактность — включаем.
X>варианты?

Я бы всегда использовал кодирование переменной длины, во первых, это сделает архив компактнее, т.к. обычно стоки бывают короткими и длина строки поместится в первые два-три байта, во вторых, я бы в принципе не стал пользоваться сериализатором, который не умеет сжимать данные на лету. Логика тут такая, если ты пишешь систему массового обслуживания (игровой сервер например), то чтобы жать трафик на лету, например, через LZ4, нужно создать по отдельному контексту на каждое клиентское подключение. Контекст в LZ4 это 12КБ. Для многих серверных приложений это превышает объем данных, необходимых для обслуживания одного клиентского подключения в разы. В общем, в итоге, ты либо расточительно расходуешь сетевой трафик, либо память на сервере. Большинство сериализаторов (protobuf, thrift, cap'n proto) умеют немного сжимать данные именно по этой причине. В protobuf оно включено всегда, а в cap'n proto — выключается при желании, ну это так, в качетсве примера.

зы
Вообще, пользоваться библиотекой сериализации, автор которой впервые узнал про leb128 в этом топике, немного не ок. Этой кодировке 100 лет в обед, она в DWARF в линуксе используется, например. Я думал что все про нее знают.

Здравствуйте, VTT, Вы писали:

VTT>>>Студия 2015: 77 предупреждений

Вот эти вот 4456-4459 (declaration of 'X' hides previous declaration, class member, global declaration) ужасно неудобны, хотя я обычно за -Wall в проектах.
Есть ли где рациональное объяснение этих нововведений? Всю жизнь инициализация членов класса работала корректно, а теперь вдруг стало опасным:

class Type {
  int member;
  std::string string;

public:
  Type(int member, std::string const& string)
  : member(member) // declaration of 'X' hides class member declaration
  , string(string)
  {}
};

Здравствуйте, chaotic-kotik, Вы писали:

CK>... во вторых, я бы в принципе не стал пользоваться сериализатором, который не умеет сжимать данные на лету.
сериализатор этого делать не должен, для этого юзеру предоставлена возможность реализовать свой io-device, типа этого.

CK>Вообще, пользоваться библиотекой сериализации, автор которой впервые узнал про leb128 в этом топике, немного не ок. Этой кодировке 100 лет в обед, она в DWARF в линуксе используется, например. Я думал что все про нее знают.
я тоже думал, что все знают, что разможаться нынче нельзя потому что планета и так перенаселена, и что успешные женьщины не размножаются сразбегу не потому, что детей не хотят/не любят, а потому что они самореализовались, и их занятия доставляют им гораздо большее удовольствие, ежели роль матки с багажем(особено глядя на подруг, которые всю свою жизнь пустили "под откос" по зову природы и благодаря отсутствию родителей в формировании личности дитя)...
оказывается нет, одна часть ничего из этого не знает, а другая — брызжет слюной рассказывая, какие они матери героини, и какую они важную роль играют(ага, в выработке углекислого газа), и как все это сложно, и рожать, и мужа алкаша терпеть чтоб дите не осталось без "отца", и дите при таком "отце" воспитать, и деньги зарабатывать для того, что на это самое дите и потратить, и чтоб "муж" еще часть из этих денег пропил...

Здравствуйте, niXman, Вы писали:

X>сериализатор этого делать не должен, для этого юзеру предоставлена возможность реализовать свой io-device, типа этого.

Туда можно только snappy или lz4 впилить. То о чем я говорю делается на уровне энкодера.

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

тут должна быть картинка с летчиком и подписью "я ничего не понял"

Здравствуйте, chaotic-kotik, Вы писали:

CK>тут должна быть картинка с летчиком и подписью "я ничего не понял"
если сильно упростить, — то я тоже думал, что все умеют читать.

в общем, будет "компактная" версия бинарного и текстового протоколов.
включаться будет параметром шаблона, чтоб исключить рантайм оверхед:

yas::binary_oarchive<yas::mem_ostream, yas::endian_little|yas::compacted> oa;

но в "компактной" версии будет использоваться не varint, ибо слишком оверхедный...

Здравствуйте, flаt, Вы писали:

F>

F>class Type {
F>  int member;
F>  std::string string;

F>public:
F>  Type(int member, std::string const& string)
F>  : member(member) // declaration of 'X' hides class member declaration
F>  , string(string)
F>  {}
F>};
F>

А вот меня приводит в недоумение, отчего в языке разрешается использовать одно и то же имя для всего подряд.
По возможности, я использую строго непересекающиеся наименования для пространств имен, макросов, типов, методов, полей, статических полей и переменных.
Чтоб потом не приходилось гадать, string — это поле, переменная, тип или еще что.

Здравствуйте, niXman, Вы писали:

X>2. YAS был добавлен в сравнителный тест сериализаторов/десериализаторов.
X> (первый коммит добавляющий YAS к этому тесту приняли, а второй, где я переработал отчеты — пока в ожидании. уикенды, мля)

привет!

нужна ваша помощь.
как вы можете прочитать тут, коллега мне намекает, будто бы я исказил результаты тестов, и типа у него совсем другие результаты. я повторил тесты на двух машинах — мои результаты повторяются.

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

спасибо за помощь!


зы
1. клонируем этот проект: https://github.com/niXman/cpp-serializers
2. и этот тоже: https://github.com/STEllAR-GROUP/hpx (для сборки в убунте нужно установить libtcmalloc, hwloc и Mpich2-dev)

потом идем в каталог cpp-serializers и выполняем: mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release ..
далее: ./test 1000000

Здравствуйте, VTT, Вы писали:

VTT>2) &string[0] — это реально стремно

Я как-то тоже поставил коллеге ошибку в ревью из-за этого. Потом, когда читал Страуструпа, нашел примеры, где он это бессовестно делал.

Один пример из книги:

rev(&s1[0],&s1[0]+s1.size());

s1 это строка:

Второй пример:

in.read(&s[0],max);

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

спасибо PM за поддержку по моей просьбе. коммит приняли.
сравнительные результаты:

(https://github.com/STEllAR-GROUP/cpp-serializers/blob/master/images/time.png)

сейчас проделано следующее:
1. почищен код, пофикшены ворнинги, убраны олд-стайл-касты и всякая фигня вроде '&str[0]'.
2. выброшена изрядная часть кода.
3. добавлены лимиты.
4. повышена производительность.
5. добавлен компактный(без использования varint) тип бинарных архивов(зовется yas_compact). (гораздо более быстрый, чем при использовании varint, но экономия в размере ниже)
6. в процессе реализация компактных архивов с использованием varint. (гораздо более медленный чем yas_compact, но экономия в размере выше)
7. добавлен новый тип архивов — object. это почти как json, но намного производительнее, и с некоторыми отличиями от json.
пример создания сложного, вложенного объекта:

    int v0=33;
    bool v1=false;
    double v2=3.14;
    bool v3=true;
    int v4=44;
    int v5=55;
    auto o0 = YAS_OBJECT("object-0", v0, v1, v2);
    auto o1 = YAS_OBJECT("object-1", v3, v4, o0, v5);
    auto o2 = YAS_OBJECT("object-2", 5, 6, o1, true);
    auto o3 = YAS_OBJECT("object-3", 1, 2, o2, 3, 4, false);

    yas::mem_ostream os;
    yas::json_oarchive<yas::mem_ostream> oa(os);
    oa & o3;

будет сгенерен такой объект:

{"1":1,"2":2,"o2":{"5":5,"6":6,"o1":{"v3":true,"v4":44,"o0":{"v0":33,"v1":false,"v2":3.14000000},"v5":55},"true":true},"3":3,"4":4,"false":false}

в форматированом виде:

{
    "1": 1,
    "2": 2,
    "o2": {
        "5": 5,
        "6": 6,
        "o1": {
            "v3": true,
            "v4": 44,
            "o0": {
                "v0": 33,
                "v1": false,
                "v2": 3.14000000
            },
            "v5": 55
        },
        "true": true
    },
    "3": 3,
    "4": 4,
    "false": false
}

этот тип архива будет зваться yas_object.
от json отличается тем, что верхний уровень всегда объект, т.е. {}. верхний уровень не может быть массивом или значением.
скорость сериализации во много раз выше.
более подробно расскажу позже.

это подготовка к json архивам в составе YAS.

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

YAS_OBJECT() — макрос. первый аргумент не используется для yas_object архивов, но будет использоваться для json архивов.

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