137 views

Skip to first unread message

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

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

Search

Clear search

Close search

Google apps

Main menu