On 24/02/2021 12:55, Vinícius dos Santos Oliveira via Boost wrote:

The research might be daunting, but it always pays off. Research is what separates a "cool hack" from "serious solutions". I'm actually looking forward to using this library myself.

I'm very sure Peter did his prior art research. For me personally, I'd like a C++ 23 Reflection emulation library which emulates as much of future Reflection as is possible today, and would if on C++ 23 switch to using proper Reflection. No idea if such a thing is possible however. Niall

Vinícius dos Santos Oliveira wrote:

Em ter., 23 de fev. de 2021 às 15:56, Peter Dimov via Boost escreveu:

...

Other JSON (and serialization) libraries already offer a similar mechanism, e.g. https://github.com/nlohmann/json#arbitrary-types-conversions. But since each library has its own private way to annotate types, a programmer needs to repeat the type annotations for every library he wants his type to be known to. This is unnecessary and undesirable, and a standard mechanism to describe types avoids it.

I agree with the diagnosis, but I'm not so keen on the solution. I insist you broaden your view and take a look at other libraries that need manual annotation. If your solution only covers the JSON case, it could very well be just an abstraction inside the JSON library and isn't a vocabulary at all.

Well, there's nothing JSON-specific in the library. It provides basic reflection metadata: base classes, data members, member functions. I use JSON, hashing, and serialization as examples of libraries already in Boost that can take advantage of this information.

The documentation lacks a section comparing your solution with what's available on the market today. I'll give you a starter pack on what's to look for, but you shouldn't limit yourself to these links:

* https://doc.qt.io/qt-5/properties.html * https://doc.qt.io/qt-5/animation-overview.html * https://gi.readthedocs.io/en/latest/ * https://archive.fosdem.org/2015/schedule/event/reinventing_the_enlighten ment_object_system/

Thanks, I'll look at these.

On 2/24/21 8:10 AM, Richard Hodges via Boost wrote:

On Tue, 23 Feb 2021 at 19:56, Peter Dimov via Boost

I can identify a number of cases where this library would be useful for me.

The easy implementation of serialisation being a major one.

I understand the appeal of this idea. But, save trivial cases, I'm doubtful that reflection will make serialization easier than it already is.

On Thu, Feb 25, 2021 at 4:16 AM Peter Dimov via Boost wrote:

There's also a scenario where the format is predetermined, and you create your C++ structs to conform to it, rather than vice versa.

Hi Peter. That's exactly my case (just not with Boost.Serialization). The real question is then, since those C++ struct sources are code-generated, is it worth to invest in Boost.Describe once in the code generator, and then use the techniques of your examples (i.e. "compile-time" code-gen), or update the source generator instead (i.e. "ahead-of-time" source-gen). In my case, the (de)serialization code is already generated, but those struct lack op== for round-trip unit-testing for example. So is it worth to invest once in describe? And use it for both binary serialization and op==, and perhaps later for JSON serialization, mock generation (no example of that?), etc... Or simply update the source generator? Depends on complexity of use, compile-time speed, runtime overhead (if any) compared to "hand-written code" (well, source-generated), these kind of things. Boost.Describe caught my eye during the BoostJSON review, and I looked at it then. But I haven't taken the time to investigate further. My structs notably use optionals and variants, of the non-standard very ad-hoc kind, so I wasn't sure how those would fair. But overall, I'm very interested in what Boost.Describe promises. --DD

On 2/24/21 7:16 PM, Peter Dimov via Boost wrote:

There's also a scenario where the format is predetermined, and you create your C++ structs to conform to it, rather than vice versa. (This of course assumes that you have an archive supporting the format.)

I've considered this from time to time. Basically this is the approach that google uses. boost serialization C++ data structures => serialization lay out features of this system no format specification required no extra code mapping the the C++ data structures to the externally defined format very easy maintenance. archives not easily read/written by other languages google protocol buffers format specified externally. This can be significant work and maintenance. code required to map to format. archives designed to be read/written by other languages Both offer pretty good performance to the point that I suspect that few will find either a performance bottle neck. Soooo - how about writing an archive format that either uses or generates an external specification and perhaps even code to make the achives read/write able by other languages (javascript anyone). It would be quite a pain and no one has asked for it. So I'm content to just suggest that those who need an external format just use google protocol buffers which is quite popular in any case. Lately, I've been interested in upgrading the boost serialization documentation to be more like the safe numerics one. It's already pretty good, but would benefit by a little more formality, lots more case studies and examples. It's amazing to me that the serialization library has lasted 17 years. I have no idea how many people (if any still use it). The codebase is more healthy than ever having incorporated a huge number of small improvements over the years. It doesn't take much of my time to keep it up to date. Most of that time is due to weird extensions to C++ which add confusion and break previously undefined stuff. Here is some information comparing serialization with google protocol buffers. https://stackoverflow.com/questions/1061169/boost-serialization-vs-google-pr... To the main point, I can see Describe working with serialization in a reasonable manner. I not yet convinced that the benefit will be worth the cost. But since it's entirely optional and doesn't require the serialization code to be altered, I don't see any problem with it. Robert Ramey