I saw all proposals about reflection, auto [...args] etc, but some of them
will not be accepted to standard, others, like reflection, is too big and
complex to support them.
Im not fun of doubling c++ standard just for writing java like interfaces
in 10 rows of code, but that's is all reflection can offer me
And I see no reason to forbid recursive macro, when it is easy to implement
and it's in fact can simplify huge amount of code, code which is already
here.
You can create a huge and complex reflection, but it will never be possible
to do what simple recursive macro can without loss expressiveness. All
examples of reflection I saw were serialization, bitflags enum and useless
java interfaces.
So, I just decide to improve existing tool and do not create new, because
language already too complex

сб, 11 нояб. 2023 г., 14:34 Marcin Jaczewski <marcinjaczewski86_at_[hidden]>:

> sob., 11 lis 2023 o 13:06 Nikl Kelbon <kelbonage_at_[hidden]> napisał(a):
> >
> > > There was even
> >
> > 'was' =(
> > > real life examples/problems
> >
> > There are example from nlohmann json, magic enum, i use it for my
> de/serialization in personal project
> >
> > > the good old X Macro
> >
> > As you see no one uses this 'good old' technique, no nlohmann json, no
> boost preprocessor. Because this do not solve those problems
> >
>
> And maybe this is a problem? You did not analyze how each solution
> works and what drawbacks have.
> You should make "Tony tables" of each possible solution that show that
> your proposal is superior to old ones.
> And use some concrete examples from real life code to prove your point.
>
> Besides, some problems you presented could be solved by static
> reflection, and you need to consider this in your paper too.
>
>
> > сб, 11 нояб. 2023 г. в 01:00, Marcin Jaczewski <
> marcinjaczewski86_at_[hidden]>:
> >>
> >> pt., 10 lis 2023 o 13:42 Nikl Kelbon via Std-Proposals
> >> <std-proposals_at_[hidden]> napisał(a):
> >> >
> >> > Here is examples, recursion stops when `__VA_OPT__` will not expands
> (`__VA_ARGS__` empty), In case on infitine recursion there are impl-defined
> limit
> >> >
> >> > implementation and discurssion here:
> >> > https://github.com/llvm/llvm-project/pull/65851
> >> >
> >> >
> >>
> >> Could you provide more real life examples/problems where this could be
> useful?
> >> In your pdf the only example of this was `tie_aggregate` but
> >> this was more of a problem in C++ than
> >> something that should be fixed by macros.
> >> There was even a proposal that had a proper solution for this:
> >>
> >> ```
> >> auto [...pack] = aggregate;
> >> ```
> >>
> >> Another thing is how your proposal is better than the good old X Macro
> >> technique?
> >>
> >>
> >>
> >> > пт, 10 нояб. 2023 г. в 16:37, Andrey Semashev via Std-Proposals <
> std-proposals_at_[hidden]>:
> >> >>
> >> >> On 11/10/23 15:22, Nikl Kelbon via Std-Proposals wrote:
> >> >> > Hi all, I would like to propose a minor addition to the
> preprocessor,
> >> >> > that has the potencial to significantly simplify writing and
> reading
> >> >> > macros, give new features that were not there.
> >> >> >
> >> >> > I propose a special token '__THIS_MACRO__'(similar to
> '__VA_ARGS__' and
> >> >> > '__VA_OPT__' ), which will add the possibility to write recursive
> macros.
> >> >> >
> >> >> > Simple example:
> >> >> >
> >> >> > #define fold_right( op , head , ...) \
> >> >> > ( head __VA_OPT__ ( op __THIS_MACRO__(op, __VA_ARGS__ )))
> >> >> > /* expands to (1 + (2 + (3))) */
> >> >> > int i = fold_right(+ , 1 , 2 , 3 );
> >> >> >
> >> >> >
> >> >> > This can be used in many different scenarios,
> >> >> > * declaring enums with enum info(like names, count, etc)
> >> >> > * boost describe struct
> >> >> > * ... more examples in 'pdf' ...
> >> >>
> >> >> When does the recursion stop? IOW, what one is supposed to write in
> the
> >> >> macro definition to stop the recursion at a certain point?
> >> >>
> >> >> --
> >> >> Std-Proposals mailing list
> >> >> Std-Proposals_at_[hidden]
> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >> >
> >> > --
> >> > Std-Proposals mailing list
> >> > Std-Proposals_at_[hidden]
> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>