On 3/18/22 14:54, WhatMeWorry wrote:

> size_t is an alias to one of the unsigned integral basic types, and
> represents a type that is large enough to represent an offset into all
> addressable memory.

In practice, that general description means "size_t is either ulong or uint" depending on your platform (or build e.g. -m32 as Adam said).

> size_t huge = uint.max;  // compiles

That means size_t is uint on that build.

Ali

P.S. On a related note, I used to make the mistake of using size_t for file offsets as well. That is a mistake because even on a 32-bit system (or build), file sizes can be larger than uint.max. So, the correct type is long for seek() so that we can seek() to an earlier place and ulong for tell().

On Friday, 18 March 2022 at 23:01:05 UTC, Ali Çehreli wrote:
> P.S. On a related note, I used to make the mistake of using size_t for file offsets as well. That is a mistake because even on a 32-bit system (or build), file sizes can be larger than uint.max. So, the correct type is long for seek() so that we can seek() to an earlier place and ulong for tell().

 Perhaps we should back up and ask a different question. I've been working on adaptation of Reed Solomon Codes, and i keep getting thrown with casting errors, to the point where i just want to make everything size_t to make the errors go away.

 So when should you use size_t? Is it better to use int, long, size_t? 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?

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. As soon as you use it in an expression, the whole expression becomes unsigned as well. (Related: Usual Arithmetic Conversions at the link below.)

For that reason, at least during an "ask us anything" session at a C++ conference, where Andrei was among the panel, Herb Sutter and others agreed that it was a mistake to choose unsigned for size_t.

So far, I didn't have much trouble from that decision. I am always careful when subtracting two size_ts.

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

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

  https://dlang.org/spec/type.html#integer-promotions

(Every D programmer should know the whole section 6.4 there.)

But yeah, if your function works on a byte, sure, it should take a byte.

Expect wild disagreements on this whole topic. :)

Ali

On Tue, Mar 22, 2022 at 09:11:00PM +0000, Era Scarecrow via Digitalmars-d-learn wrote: [...]
> 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.
[...]

We already have this:

	import std.conv : to;
	int x;
	long y;
	y = x.to!long;	// equivalent to straight assignment / cast
	x = y.to!int;	// throws if out of range for int


T

-- 
Gone Chopin. Bach in a minuet.
I see that you JS got Bach.