On Thu, 1 Aug 2024 at 22:47, Pynix Wnag via Liaison
<liaison_at_[hidden]> wrote:
>
> any non 8-bit system after 2000, maybe we can drop the bag now.

Well, TI was shipping non-8-bit systems well into the 2010s, and those
weren't any 9-bit systems
or something like that, but 24-bit DSP systems.

>
> Joshua Cranmer via Liaison <liaison_at_[hidden]>于2024年7月31日 周三00:00写道：
>>
>> On 7/30/2024 5:30, Pynix Wnag via Liaison wrote:
>> > I know, but these all are typedef, Can we build these into language as
>> > keyword, make it default. and deprecate short long to typedef
>> > for compatibility
>>
>> As a practical matter, not really.
>>
>> In C++, it is possible to overload functions based on types, so you can
>> have distinct overloads void f(long) and void f(long long), even when
>> both types map to the same underlying 64-bit type. (The distinction also
>> matters in C, but there's much fewer places where you can practically
>> distinguish the types so it doesn't matter as much in reality).
>>
>> The fundamental issue you run into if you want to rebuild the core
>> integer type system on top of intN_t types is that C/C++ have 5 types to
>> cover 4 sizes, and trying to make those 5 types instead into typedefs of
>> 4 real types will cause a lot of existing code to break. Also, as Jens
>> points out, there are non-8-bit systems in existence, although if there
>> were real benefits to changing the core language in this way, you might
>> cobble together a majority on the committee to declare those systems
>> incompatible with modern C/C++, as was done recently for
>> one's-complement systems.
>>
>> It's possible to work around this limitation by making intN_t types
>> fundamental types in addition to the existing type system, without
>> trying to make existing types typedefs of those types, but that means
>> you get even more aliases for the same type, which creates a lot of
>> extra burden on the language for both the specification to worry about,
>> implementers to have to implement, and users to figure out how to use.
>> With already incomplete evidence of how this is being handled with the
>> recent addition of _FloatN/std::floatN_t types creating subtle
>> incompatibilities between C and C++, I am confident that this is not a
>> good idea in the slightest.
>>
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Link to this post: http://lists.isocpp.org/liaison/2024/07/1467.php
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Searchable archives: http://lists.isocpp.org/liaison/2024/08/index.php