C++ Logo


Advanced search

Re: [std-proposals] Slow bulky integer types (128-bit)

From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Date: Thu, 30 Mar 2023 08:59:48 +0100
Just to move this discussion on a bit... there's been talk of making
'uintmax_t' deprecated, because the problem with having a 'max' type
of any kind, is that if the 'max' increases in the future, then the
ABI is broken.

So when would we ever have a proper use for 'uintmax_t'?

I'd have to 'grep' through all my old code, and I will later today,
but if memory serves me right, I've only ever used intmax_t and
uintmax_t when I've wanted to write a one-size-fits-all function that
can process or print a number. For example if I was writing a GUI
desktop application, and if I wanted to allow a worker thread to print
a number on the GUI, I'd probably do something like:

void GUI_Dialog_Main::PrintNumber(uintmax_t const arg)
        this->m_text_Number->SetValue( std::to_string(arg) );

Or if I'm using something like 'sprintf' and just amn't bothered
getting all the %'s right:

    printf( "The %" PRIuMAX " goats ran over %" PRIuMAX " fields to
reach %" PRIuMAX " trees.",

This isn't just laziness on my part -- it's also future proof just in
case the return type of FuncA changes.

So if we're going to talk about making uintmax_t deprecated, then how
about discussing when and why we ever use it? And if we were to
introduce a new type such as "uintmax_overall_t", would that just set
our children up to be having this same discussion thirty years from

A note about ABI breakage: If uintmax_t is never used as the type of a
global variable, or as a function return type or parameter type, then
ABI won't be broken.

Received on 2023-03-30 07:59:59