Jump to page: 1 25  
Page
Thread overview
length's type.
Jan 18
zjh
Jan 18
zjh
Jan 18
zjh
Jan 28
zjh
Jan 28
monkyyy
Jan 28
mw
Feb 08
mw
Feb 08
thinkunix
Feb 08
Arafel
Feb 08
kdevel
Feb 08
kdevel
Feb 09
Danilo
Feb 09
Sergey
Feb 09
Danilo
Feb 09
thinkunix
Feb 09
bachmeier
Feb 12
bachmeier
Feb 16
Kagamin
Feb 12
bachmeier
Feb 16
Kagamin
Jan 29
Kagamin
Jan 28
monkyyy
January 18

Can you change the type of 'length' from 'ulong' to 'int', so I haven't to convert it every time!

January 17
On Wednesday, January 17, 2024 7:55:37 PM MST zjh via Digitalmars-d-learn wrote:
> Can you change the type of 'length' from 'ulong' to 'int', so I haven't to convert it every time!

If you mean for arrays, length and array indices are specifically size_t so that their size will match the pointer size for the architecture. On 64-bit systems, that means that it's ulong (whereas on 32-bit systems, it would be uint). If it were int, then you couldn't access all of the elements of larger arrays (and arrays will get that large in some cases - e.g. when dealing with larger files). C/C++ does the same thing.

If you want your code to be portable and to be able to handle larger arrays, then it should be using size_t for array indices and length and not int, in which case, you're not typically going to need to convert from ulong to int, because you'd just be using size_t, which would then be ulong on 64-bit systems. Obviously, when you do need to convert to int, then that can be annoying, but for a lot of code, using auto and size_t makes it so that you don't need to use int, and it would be a big problem in general if the language made length int.

- Jonathan M Davis



January 18

On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis wrote:
but for a lot of code, using auto and size_t makes it

>

so that you don't need to use int, and it would be a big problem in general if the language made length int.

It's hard to imagine that an 'int' needs to be replaced with 'auto'.

January 18
On Wednesday, January 17, 2024 11:33:48 PM MST zjh via Digitalmars-d-learn wrote:
> On Thursday, 18 January 2024 at 04:30:33 UTC, Jonathan M Davis
> wrote:
> but for a lot of code, using auto and size_t makes it
>
> > so that you don't need to use int, and it would be a big problem in general if the language made length int.
>
> It's hard to imagine that an `'int'` needs to be replaced with `'auto'`.

It's very common in D code to do stuff like

auto a = foo();

or

auto len = arr.length;

That way, you automatically get the correct type. Obviously, there are cases where you need to force a particular type, and that can require casting, but inferring types often simplifies code. It's _very_ common in idiomatic D code to use auto when you don't need to force a specific type. And when dealing with arrays, it's very typical to use either auto or size_t, because then you get the correct integer type regardless of the platform, and then you only need to worry about casting to int in cases where you actually need int for whatever reason.

But regardless of whether you want to use auto, there are very good reasons for why length is size_t, and C/C++ made exactly the same choice for the same reasons. You can certainly disagree with that choice, but it's not the kind of thing that stands much chance of ever being changed.

- Jonathan M Davis



January 18

On Thursday, 18 January 2024 at 07:44:00 UTC, Jonathan M Davis wrote:

> auto a = foo();
>
> or
>
> auto len = arr.length;
>


Thank you for your reply, just to use `auto`.
January 28

On Thursday, 18 January 2024 at 02:55:37 UTC, zjh wrote:

>

Can you change the type of 'length' from 'ulong' to 'int', so I haven't to convert it every time!

The explicit conversion .length.to!int has an extra benefit of doing a runtime check to ensure that the length value actually fits in an int variable. Just in case if somebody tries to use your code to process a 3GB array of bytes.

It's more correct to rewrite the code to expect size_t. But one needs to be very careful about implementing it correctly, because silent casts between signed and unsigned data types may ruin your day. It's a major source of bugs, similar to the one discussed in https://forum.dlang.org/thread/vyvbrtmyelududcvukfb@forum.dlang.org

January 28

On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka wrote:

>

The explicit conversion .length.to!int has an extra benefit

I rarely use numbers over one million.

But do I have to consider numbers over 4 billion every day?

January 28

On Sunday, 28 January 2024 at 08:55:54 UTC, zjh wrote:

>

On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka wrote:

>

The explicit conversion .length.to!int has an extra benefit

I rarely use numbers over one million.

But do I have to consider numbers over 4 billion every day?

If .length were to be an int, D could not handle array of more than 2G bytes. The whole language would be useless on 64 bit systems.

January 28

On Sunday, 28 January 2024 at 16:16:34 UTC, Olivier Pisano wrote:

>

On Sunday, 28 January 2024 at 08:55:54 UTC, zjh wrote:

>

On Sunday, 28 January 2024 at 06:34:13 UTC, Siarhei Siamashka wrote:

>

The explicit conversion .length.to!int has an extra benefit

I rarely use numbers over one million.

But do I have to consider numbers over 4 billion every day?

If .length were to be an int, D could not handle array of more than 2G bytes. The whole language would be useless on 64 bit systems.

Of bytes and if your messing with the type and still think that's an important concern you could make it a long for 63 bits and no silly 0-1 behavior

a signed index of a datatype that is 2 words will still compete with the mythical computer ram of a max ram 64 bit machine; if you have 64^2 ubytes maybe you should rotate your prospective and store 256 counts of each.

January 28

On Thursday, 18 January 2024 at 02:55:37 UTC, zjh wrote:

>

Can you change the type of 'length' from 'ulong' to 'int', so I haven't to convert it every time!

The devs are obviously very very wrong here I underflow indexs all the time

But this is a pretty dead fight, I'd aim for a smart index type thats a "checkedint" with underflow protection and can alias to int; cause maybe that could someday happen.

« First   ‹ Prev
1 2 3 4 5