Boost logo

Boost Users :

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-11-07 03:03:13


On 11/6/2019 6:03 PM, pavel b via Boost-users wrote:
> > I am not sure what you are saying above. Did you extend the number of
> > maximum variadic elements, the number of maximum tuple elements, or
> both ?
>
> Here I changed only the number of maximum variadic elements
>
> > As far as Microsoft C++ only supporting a maximum of 127 macro
> > arguments, do you have something which shows that ?
>
> https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2019
>
> > It should only affect variadic data and not tuples
>
> I am afraid that some tuples-specific files like  tuple/to_list.hpp or
> tuple/lo_seq.hpp need to be changed as well

As I said if you would like to create a PR with your work to increase
the number of elements for tuples and variadic data I will look at it.
Ideally if I decided to increase the maximum number number of tuple
elements and variadic data I would probably go for 256 so as to match
the maximum number of seq elements. The main reason for not doing so in
the past, aside from the fact that it has almost never been requested,
is that I did not want to slow down the preprocessor for all those
programmers using Boost PP tuples and variadic data functionality who do
not need to consider more than 64 elements. So a large part of any
decision to increase the number of tuple and variadic data elements for
all Boost PP end-users is to measure if there really is a significant
slowdown by the preprocessor in doing so.

>
> On Tue, Oct 29, 2019 at 3:44 AM Edward Diener via Boost-users
> <boost-users_at_[hidden] <mailto:boost-users_at_[hidden]>> wrote:
>
> On 10/28/2019 8:35 PM, pavel b via Boost-users wrote:
> >
> > Hi,
> >
> >     No, you should not be changing the limits and doing so will not
> >     actually
> >     change anything. If you want more than 64 tuple elements you
> could have
> >     a tuple whose elements themselves are tuples. For instance if you
> >     wanted
> >     256 tuple elements you could program this as a tuple with 64
> elements
> >     and each of those elements is a tuple with 4 elements. Or if
> you like a
> >     tuple with 16 elements and each of those elements a tuple of 16
> >     elements. You get the idea.
> >
> >
> > Thank you, good Idea! But in my case it was about the support of
> an old
> > project, therefore a redesign was not my first choice.
> >
> > Unfortunately, there is only little room for improvement.
> Microsoft C++
> > compiler, for example, supports only 127 macro arguments. >
> > After extending BOOST_PP_VARIADIC_SIZE and
> BOOST_PP_VARIADIC_SIZE_I in
> > boost/preprocessor/variadic/size.hpp and defining additional
> > BOOST_PP_VARIADIC_ELEM_[64..125] as in preprocessor/tuple/elem.hpp
> > BOOST_PP_TUPLE_SIZE() and BOOST_PP_TUPLE_ELEM() work with up to 126
> > elemnets.
>
> I am not sure what you are saying above. Did you extend the number of
> maximum variadic elements, the number of maximum tuple elements, or
> both ?
>
> >
> > BOOST_PP_TUPLE_TO_SEQ() uses internal some additional macro
> parameters,
> > it supports tuples with up to 124 elemrnts after adding
> > BOOST_PP_TUPLE_TO_SEQ_[65..124] similar to
> preprocessor/tuple/to_seq.hpp
>
> OK.
>
> >
> > No other boost preprocessor macros were changed/tested.
> >
> > So after a few simple changes, I have succeeded to extend tuple size
> > from 64 to 124 elements. It seems to work under current MSVC,
> clang and
> > gcc versions.
>
> You really need to enhance the current tests dealing with variadic data
> and tuples so that you can show that variadic data and tuples with 126
> elements will work properly, in order to verify that your changes work
> in all cases.
>
> Also if you would like to create a PR for your changes I will be
> glad to
> look at it.
>
> As far as Microsoft C++ only supporting a maximum of 127 macro
> arguments, do you have something which shows that ? It should only
> affect variadic data and not tuples.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net