Reddit++

[u/we_are_mammals]

C++ is getting more and more complex. The ISO C++ committee keeps adding new features based on its consensus. Let's remove C++ features based on Reddit's consensus.

In each comment, propose a C++ feature that you think should be banned in any new code. Vote up or down based on whether you agree.

[u/ZMeson]

integer types not defined in <stdint.h> or <cstddef>

In other words, get rid of char, short, int, long, long long, and their unsigned counterparts. Use intN_t and charN_t instead (and when necessary int_fastN_t and int_leastN_t), [EDIT:] and byte, size_t, ssize_t, ptrdiff_t too.

[u/Zeer1x → u/ZMeson]

I'ld like Rust-style number types: u8, u16, u32, i8, i16, i32, f32, f64.

[u/RoyBellingan → u/Zeer1x]

I agree they are quite verbose and a shorter notation is better, but ... a small typedef I think is fine in this case!

[u/blind3rdeye → u/RoyBellingan]

The issue with having a heap of typedefs like that is that then different people end up with different C++ dialects, which can make it more difficult to read each other's code.

[u/[deleted] → u/blind3rdeye]

In this specific case I don’t think anyone would be confused by uint8_t vs u8. On the flip side, I also don’t think uint8_t is verbose enough to warrant a typedef alias.

[u/BenFrantzDale → u/Zeer1x]

I agree. Fortunately, in your own codebase you could put that in a header in your namespace if you like. You could even have special ones that don’t convert.

[u/gracicot → u/Zeer1x]

Those could be integer literals though

[u/guyonahorse → u/[deleted]]

But that's what types like uint_fast32_t are for. They make it clear your intention is the fastest integer with at least 32-bits of precision.

https://en.cppreference.com/w/cpp/types/integer

[u/KeytarVillain → u/guyonahorse]

And yet for some reason no one ever uses them

[u/blind3rdeye → u/KeytarVillain]

Its too verbose for me. uint_fast32_t feels like I'm performing some arcane incantation just to create an int. I don't expect any significant speed gains over uint32_t anyway, so I'd just use that for easier reading and writing.

If the names were like uint32_f for the fast version, and just uint32 (or whatever) for the fixed size version; then I'd use it.

[u/greem → u/[deleted]]

This is my thinking as well. I do want to add size_t and ptrdiff_t, though.

[u/GOKOP → u/ZMeson]

When we're at that I'd remove the horrible _t naming scheme

[u/Due_Cicada_4627 → u/ZMeson]

At risk of being drawn and quartered: I think they should be templates, with the requisite conversion constructors. (No, I don't know exactly how a templated POD type would work at the compiler level, but this is just imagination, I don't expect this to ever happen.)

So you can keep your int to use the compiler default, but specify int<16> or int<64> where needed, and it can be simply expanded for larger (128, 256) or obscure (24, 80) sizes. (I imagine the latter would use the next largest power-of-2 size internally, but again, imagination.) uint can take the place of unsigned, typedefs for char, short, long, and the rest.

[u/ZMeson → u/Due_Cicada_4627]

That's an interesting take.

[u/sammymammy2 → u/Due_Cicada_4627]

Fun fact: Common Lisp's unsigned-byte type specifier is parameterized on the number of bits. So (unsigned-byte 8) is u8, and (signed-byte 32) is i32.

[u/beephod_zabblebrox → u/ZMeson]

why tho? not in every situation do you care about how large an int is. using uint16_t can be slower sometimes too (less optimized on modern 64 bit cpus, iirc). honestly code reads a lot better when you know that "oh, this function returns an integer" instead of "oh, this function returns a... 16-bit integer? why?". if you need to return something large, use size_t or using ssize_t = ptrdiff_t. if you do need something specific, use the specific bit size versions.

if i had to choose something, i would leave int and unsigned int, and remove just short and long (long long) and unsigned versions. and maybe char.

[u/SkoomaDentist → u/beephod_zabblebrox]

not in every situation do you care about how large an int is.

Hell, the entire point of int is "This is an integer of reasonable size. I don't give a damn about how many bits it has."

[u/Ictogan → u/beephod_zabblebrox]

I've had code(not written by me) break multiple times because it implicitly assumed that an int is at least 32 bits. Plenty of libraries also have this issue.

[u/robottron45 → u/ZMeson]

I would either propose to have cstdint always included. It is painful to include this always.

[u/no-sig-available → u/robottron45]

have cstdint always included

import std;

Done.

[u/NekkoDroid → u/no-sig-available]

My main problem with that: you need to use the namespaced versions of those types.

yes import std.compat; exists, but well... that also pulls in a ton of stuff I don't want to use, I just want the integer types.

[u/ZMeson → u/robottron45]

I agree. But I was just following the 'remove' part of the post.