int_t template alias and Standardese

1,132 views
Skip to first unread message

Myriachan

unread,
Feb 26, 2019, 7:09:20 PM2/26/19
to ISO C++ Standard - Future Proposals
I'd like to make a proposal for these things:

1. Allowing implementations to define intN_t for values of N other than 8, 16, 32, 64; reasonable examples could be 24 or 128.  This would make C++ <cstdint> match C <stdint.h> in that respect.  Likewise for certain matching definitions in <atomic>.
2. Template aliases int_t<N> and uint_t<N> that are aliases for intN_t and uintN_t respectively, when they exist for that N.
3. Template aliases int_least_t<N>, uint_least_t<N>, int_fast_t<N>, uint_fast_t<T> that are similar, except that they will automatically select the next size up, if one exists.

But I have some questions about this.


For (1), I was considering changing the wording of the synopsis in [cstdint.syn] to something like this:

// For the following, N is a positive integer written with no leading zeros.
using intN_t = signed integer type;  // potentially optional
using int_leastN_t = signed integer type;  // optional for N ∉ { 8, 16, 32, 64 }
using int_fastN_t = unsigned integer type;  // optional for N ∉ { 8, 16, 32, 64 }

With intN_t and uintN_t, for 8, 16, 32, 64, these are mandatory if there exists a type in the implementation that would meet the definition.  This rule, however, is defined by C and not by C++.  Other values of N are allowed but are optional.  Would I need to express that detail, or is it implied by referencing C?

For [u]int_leastN_t and [u]int_fastN_t, the comment should be clear enough.  I don't know whether the "not element of" symbol is appropriate in the C++ Standard, though.


For (2), the template definition is clear:

template <int N>
using int_t = signed integer type;

How should this be worded, though?  The template should be mandatory, but int_t<N> should only have a specialization if intN_t exists.  Otherwise, it should be the same as an undefined declared template without a specialization so that it's SFINAE-compatible.

This brings up another question: what should happen if the implementation defines none of the intN_t types?  Ideally, it would mean that int_t's underlying template has no specializations, and any attempt to use it would fail.  Does this run afoul of [temp.res]/8, though, because it's a then a template for which no valid specialization exists?


For (3):

template <int N>
using int_least_t = signed integer type;
template <int N>
using int_fast_t = signed integer type;

These templates are mandatory.  I don't know the right wording, though.  If N <= 0 or N > M where M is the largest integer such that int_leastN_t is defined, it should act like the specialization doesn't exist.  For positive integers less than M, it should be alias of int_leastL_t, where L is the least integer such that int_leastL_t exists; likewise for int_fast_t<>.


As final questions: How well would these proposals likely be received?  Should the templates be presented as a separate proposal from allowing N values not in 8, 16, 32, 64 to match C?

Thanks,

Melissa

John McFarlane

unread,
Mar 1, 2019, 2:33:48 PM3/1/19
to std-pr...@isocpp.org
There is definitely a desire for such things. P0102 is one example of a similar proposal.

In addition, I'd like to see a more general purpose solution which the user can customise (P0675).

John

Thanks,

Melissa

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f1eada83-f684-4cd1-969a-d20f79e84d72%40isocpp.org.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages