Basic question about size_t and ulong
rtcvb32 at yahoo.com
Tue Mar 22 21:11:00 UTC 2022
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
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
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
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
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...
More information about the Digitalmars-d-learn