Hi, Thiago, did you decide on something regarding QCborValue in Qt5.12? For structured traces, we have to deal with any user-defined data types so, we can do with QCborValue, QJsonValue or QFoo too. Now, the value of exposing the common backend of QJson and QCbor as a QFoo binary format is not clear to me, and the "lowest common denominator" approach is inherently limited.
In my latest QBind prototype, we can write any user-defined type in various formats, and we can even take a copy of the user-defined type to serialize it later. So, QFoo is not required as an intermediate storage and would probably be slower. The latest benchmark shows the QBind approach can be *very* efficient: (usecs) |QDebug|Json|Cbor|Writable|Writable>Cbor MSVC 17 <<atoms__| 8| 6| 4| 0| 3 <<doubles| 15| 19| 4| 0| 5 GCC 5.3 <<atoms__| 4| 3| 2| 0| 4 <<doubles| 29| 28| 4| 0| 4 You can test for yourself, it is 2 source files and a .pro https://gricad-gitlab.univ-grenoble-alpes.fr/modmed/modmedLog/tree/master/tests/QBind If you are afraid of template code bloat in the QBind approach, I think a disciplined use can mitigate that, i.e. use QBind to just write to a single format. Actually, I think the compiler has more opportunities to factor out similar code in our QBind approach than with hand-written serialization code. It removes so much boiler plate code with anecdotal differences... Please let me know what you think. Arnaud -----Original Message----- From: Thiago Macieira <thiago.macie...@intel.com> Sent: jeudi 14 juin 2018 02:08 > This email is to start that discussion and answer these questions: > a) should we have this API? > b) if so, what would this API look like? > c) if not, should we unify at least JSON and CBOR? > c) either way, should remove QCborValue until we have it? ... > This API would also be the replacement of the JSON and CBOR parsers, > for which we'd have a unified API, something like: > QFoo json = QJson::fromJson(jcontent); > QFoo cbor = QCbor::fromCbor(ccontent); > qDebug() << QCbor::toDiagnosticFormat(json); // yes, json _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
