float.sizeof should be 4 (page 2)

On Tuesday, 24 September 2024 at 10:49:45 UTC, Dom DiSc wrote: > On Tuesday, 24 September 2024 at 03:23:31 UTC, Jonathan M Davis wrote: >> So, the issue really isn't the value itself. That will convert to other sizes just fine, particularly since it's known at compile time. Rather, what matters is what you get when you do math on it > > Doing math most of the time involves at least two values, in this case sizeof (of type size_t) and 4 (a nibble). You might want to make sure you understand the problem before commenting, that would save everybody some time. sizeof is a property here, not a value, and that property has for value 4, and type size_t.

enum iColor : short { R, G, B } //* enum sColor : string { R = "red", G = "green", B = "blue" }//*/ template ByteSize(E) if (is(E == enum)) { alias T = imported!"std.traits".OriginalType!E; enum ByteSize = T.sizeof * 8; } import std.stdio; void main() { ByteSize!iColor.writeln(" == ", iColor.sizeof * 8); ByteSize!sColor.writeln(" == ", sColor.sizeof * 8); String.sizeof.writeln; // 48 } struct String { immutable(char)[] str; size_t a, b, c, length; }

September 24

Re: float.sizeof should be 4

Posted by Jonathan M Davis
in reply to Dom DiSc

Permalink

Jonathan M Davis

Posted in reply to Dom DiSc

Permalink

On Tuesday, September 24, 2024 4:49:45 AM MDT Dom DiSc via Digitalmars-d wrote:
> On Tuesday, 24 September 2024 at 03:23:31 UTC, Jonathan M Davis
>
> wrote:
> > So, the issue really isn't the value itself. That will convert to other sizes just fine, particularly since it's known at compile time. Rather, what matters is what you get when you do math on it
>
> Doing math most of the time involves at least two values, in this
> case sizeof (of type size_t) and 4 (a nibble).
> It should be clearly defined in what type such an operation
> should result.

As long as sizeof is size_t, then math will give you ulong on 64-bit systems and uint on 32-bit systems. The main problem with it not being a size_t is if you're on a 64-bit system and you do math with a 32-bit value. For instance, it's quite common for folks to just use int by default with many numbers, but the result of multiplying such a value against a sizeof really needs to be size_t if you don't want potential overflow issues. If sizeof defaulted to ubyte just because it's a value that can fit in a ubyte, then multiplying it against an int would give you an int when what you really need if you want to avoid bugs is a ulong / size_t, because that's what's needed to represent larger memory sizes. There would quite easily be problems with large arrays if the type being used weren't size_t.

And yes, having sizeof be treated as size_t does sometimes get annoying when you don't actually need the larger values, and you want to do something other than get a value to use for something other than memory manipulation, but it means that you get the correct result by default, because you're guaranteed to be dealing with the correct type for memory sizes. If you then actually need a smaller type, you can cast to a smaller type. And since sizeof typically gives a value that fits in a ubyte (and definitely does with float), and the value is known at compile-time, you can always do something like

ubyte v = float.sizeof;

if you want to be dealing with a ubyte. D defaults to the size that is the least likely to result in silent bugs and then allows you to convert to smaller types if you want to for your particular application.

The entire reason that Steven is running into issues here is because he's deciding for whatever reason when dealing with raylib to use int for memory sizes when it's usually the case that the correct thing to do is to use size_t in order to ensure that you can correctly handle large arrays (and that can easily come up with stuff like manipulating files given how large they can get these days).

- Jonathan M Davis

Forums