On Thu, Sep 24, 2020 at 8:43 AM Peter Dimov via Boost wrote:

I would like to submit a C++14 reflection library, Describe, to Boost and I'm looking for endorsements and a review manager.

Looks pretty solid and useful, although the C++14 requirement is a bummer but I understand it can't be helped. This counts as my endorsement. Regards

Gesendet: Donnerstag, 24. September 2020 um 17:43 Uhr Von: "Peter Dimov via Boost"

I would like to submit a C++14 reflection library, Describe, to Boost and I'm looking for endorsements and a review manager. The library is at

I'd also like to endorse this library and am looking forward to replace some of our home grown solutions with this. In order to become the de-facto standard way to annotate custom types, it would be great, if the dependency on mp11 could be removed, but it would certainly be useful to us with that dependency too. Best Mike

On 9/24/20 11:43 pm, Peter Dimov via Boost wrote:

I would like to submit a C++14 reflection library, Describe, to Boost and I'm looking for endorsements and a review manager. The library is at https://github.com/pdimov/describe and the documentation is at https://pdimov.github.io/describe/doc/html/describe.html. Some examples of what the library enables are given at https://pdimov.github.io/describe/doc/html/describe.html#examples.

The purpose of Describe is to establish a standard way of annotating (describing) user-defined types (enums, structs and classes), so that types can be described once, and then their descriptions can be used from other libraries. At the moment, the practice is for each library to invent its own ad-hoc annotation/description mechanism.

+1. I love this. I think this will be a great addition to the Boost libraries. Regards, -- Joel

Em qui., 24 de set. de 2020 às 12:43, Peter Dimov via Boost escreveu:

The purpose of Describe is to establish a standard way of annotating (describing) user-defined types (enums, structs and classes), so that types can be described once, and then their descriptions can be used from other libraries. At the moment, the practice is for each library to invent its own ad-hoc annotation/description mechanism.

Hi Peter, could you consider using "compile-time strings" such as Hana's? I don't have much use for a const char* in TMP algorithms. I coded a gperf-like algorithm earlier this year and the only thing that enabled me to do so were Hana strings: https://pastebin.com/5gbWPeSk Another use I've found for Hana-like strings was avoiding allocation on object keys for json::partial::scanf(). Both algorithms can be adapted to JSON serialization code that integrates with serialization/reflection libraries, but only if I have something more than char*. You don't need to replace the current `name` member. You could maybe just add an additional member? Maybe controlled through macros so you don't force unwanted dependencies on everybody? OTOH, if you're going to enable Hana integration behind a preprocessor macro, maybe you could as well just forward on doing a complete boost::hana::accessors integration. Not sure what is the right approach here. Hana is such a great TMP library that you risk turning it into your default go-to for any complex TMP problem once you get your head around it. Honestly, if I can't implement the algorithms described above, I wouldn't use this library at all (I can already do them on Boost.Hana and they work today). One usually annotate/describe structs in Hana using code such as: ```cpp namespace ns { struct Person { explicit Person(std::string const& name, int age) : name_(name), age_(age) { } std::string const& get_name() const { return name_; } int get_age() const { return age_; } private: std::string name_; int age_; }; } BOOST_HANA_ADAPT_ADT(ns::Person, (name, [](ns::Person const& p) { return p.get_name(); }), (age, [](ns::Person const& p) { return p.get_age(); }) ); ``` You can see full examples at https://www.boost.org/doc/libs/1_72_0/libs/hana/doc/html/group__group-Struct.... -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/