Basic question about size_t and ulong

[Era Scarecrow]

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...