Date: Fri, 18 Jul 2025 13:13:04 +0200
On 18/07/2025 11:58, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Fri, Jul 18, 2025 at 10:22 AM Frederick Virchanza Gotham wrote:
>>
>> I forgot to add that _Max_t would also work properly with types
>> smaller than int.
>
>
> I'm just realising now that this is possible without core language
> support. I'm going to put the following code in a header file and use
> it in my programs.
>
> Just the other day I nearly introduced a bug into a program . . . I
> had a TCP port number stored in a uint16_t, and I wanted to check if
> it was valid, so I compared it to 0 and also to -1 (in the hope that
> -1 would be 65535). Thankfully the compiler gave me a warning that "-1
> == n" would always be false because of integer promotion, and I fixed
> it.
>
I recommend you do a few things there. First, stop jumping from "I
personally want to write this code, and would like to save a couple of
characters" to "this is a great idea for the C++ standard". Secondly,
think before you post ideas for standards proposals - when this can be
written in existing C++ in a few lines of code, it is not a candidate
for a core language change.
Finally, I suggest you stop writing nonsense in your code. A TCP/IP
port is a number between 1 and 65535 (UDP allows port 0 in some
circumstances to mean "no port"). If you have a number and you want to
check its validity as a port number, check it against these two values -
1 and 65535 (or 0xffff if you prefer hex, or define an identifier for it
if you think it makes the code clearer). Using "-1" as a maximum value
for an unsigned type is nonsense. It often works, because of the way
the language is designed, but it is nonetheless nonsense. Aim for
simplicity and clarity in your coding, not smart-arse tricks.
Of course that last suggestion is entirely up to you - you can write
code in whatever way you like, even if it is not the way I would
recommend or like anyone to write code. I also recommend you learn a
similar humility - the C++ standard should not change to suit your
personal coding preferences.
> On Fri, Jul 18, 2025 at 10:22 AM Frederick Virchanza Gotham wrote:
>>
>> I forgot to add that _Max_t would also work properly with types
>> smaller than int.
>
>
> I'm just realising now that this is possible without core language
> support. I'm going to put the following code in a header file and use
> it in my programs.
>
> Just the other day I nearly introduced a bug into a program . . . I
> had a TCP port number stored in a uint16_t, and I wanted to check if
> it was valid, so I compared it to 0 and also to -1 (in the hope that
> -1 would be 65535). Thankfully the compiler gave me a warning that "-1
> == n" would always be false because of integer promotion, and I fixed
> it.
>
I recommend you do a few things there. First, stop jumping from "I
personally want to write this code, and would like to save a couple of
characters" to "this is a great idea for the C++ standard". Secondly,
think before you post ideas for standards proposals - when this can be
written in existing C++ in a few lines of code, it is not a candidate
for a core language change.
Finally, I suggest you stop writing nonsense in your code. A TCP/IP
port is a number between 1 and 65535 (UDP allows port 0 in some
circumstances to mean "no port"). If you have a number and you want to
check its validity as a port number, check it against these two values -
1 and 65535 (or 0xffff if you prefer hex, or define an identifier for it
if you think it makes the code clearer). Using "-1" as a maximum value
for an unsigned type is nonsense. It often works, because of the way
the language is designed, but it is nonetheless nonsense. Aim for
simplicity and clarity in your coding, not smart-arse tricks.
Of course that last suggestion is entirely up to you - you can write
code in whatever way you like, even if it is not the way I would
recommend or like anyone to write code. I also recommend you learn a
similar humility - the C++ standard should not change to suit your
personal coding preferences.
Received on 2025-07-18 11:13:16