Boost logo

Boost :

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2022-06-02 11:30:13


Le jeudi 02 juin 2022 à 11:00 +0200, Maximilian Riemensberger a écrit :
>
> On 6/2/22 07:57, Julien Blanc via Boost wrote:
> >
>
> > [...]
>
> The library looks very interesting.  I think I could be very useful
> for defining custom error codes (enums) and their mapping to custom
> error strings.  This is relatively simple with a std::array if the
> codes are contiguous and starting from 0.  Your library would make it
> as easy for arbitrary code values, like http codes. Very useful.

Thanks for your feedback. This is indeed a very good use case.

>
> Is there a particular reason to require c++17? I guess some
> std::array features that got added? I would assume that it should be
> possible to make it compile under C++14 (maybe using some boost
> array) since most constexpr things should already be available there.

The first reason it requires C++17 is because this is what i am
targetting at the moment. However, making it C++14-compliant would
require a few changes:

* the library use template auto syntax in several places, this allows
writing indexed_array<float, interval<1, 10>>. In C++14 one would need
to write indexed_array<float, interval<int, 1, 10>>, or resort to
macros.
* it makes use of std::is_invokable to correctly disable the default
aggregate constructor if given a safe_arg initializer list. This can be
worked around (iirc is_invokable can be emulated in C++14)
* it also makes use of std::apply for multi-dimensional indexing.
Likewise, this can be emulated in C++14.
* there are probably a few others that i'm missing. In short: it can be
done, but sticking to C++17 avoided reimplementing several now-standard
library features.

> >
> > If there is some interest, i'd like to propose it for inclusion in
> > boost. So i'm looking for people who would endorse it.
>
> I endorse it.
>
> Thanks for sharing.

Thanks for your feedback, and thanks for endorsing the library.

Regard,

Julien
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk