On Tuesday, 22 March 2022 at 18:47:19 UTC, Ali Çehreli wrote:
On 3/22/22 11:28, Era Scarecrow wrote:
> So when should you use size_t?
I use size_t for anything that is related to count, index, etc.
However, this is a contested topic because size_t is unsigned.
I don't see a problem with that. It's not like you can access
-300 address space or index (*although making your own index
function technically you could*). I'm actually surprised signed
is the default rather than unsigned. Were negative numbers really
that important in 16bit MS-DOS that C had to have signed as the
default?
This question is probably going off topic but still be
interesting to know if there's an answer.
> Is it better to use int, long, size_t?
D uses size_t for automatic indexes during foreach, and as I
said, it makes sense to me.
Otherwise, I think the go-to type should be int for small
values. long, if we know it won't fit in an int.
Mhmm. More or less this is what i would think. I'm just getting
sick of either numbers i return that i have to feed into indexes
and it complains it's too big, or putting what is going to be a
smaller number in an array because the array type is too small.
Casting or using masks may resolve the issue, but it may crop up
again when i make a change or try to compile on a different
architecture.
My usual writing at this time is doing my work on a 64bit
laptop, but sometimes i go and run the 32bit dmd version in
windows on a different computer and checking for differences
between ldc/gdc and dmd for if the code complains. I see more and
more why different versions of compilers/OSes is a pain in the
ass.
I'd almost wish D had a more lenient mode and would do automatic
down-casting, then complain if it *would* have failed to downcast
data at runtime.
> Or is it better to try to use the smallest type you need that
> will fulfill the function's needs and just add to handle
> issues due to downcasting?
That may be annoying, misleading, or error-prone because
smaller types are converted at least to int in expressions
anyway:
Yeah, and i remember reading about optimization in GCC where
doing smaller types can actually be slower, much like in some
architectures having offsets in memory address results in a speed
penalty for non-aligned data.
But yeah, if your function works on a byte, sure, it should
take a byte.
Expect wild disagreements on this whole topic. :)
Though internally it may be an int...
