size_t vs uintptr_t

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 15 09:31:22 PDT 2016


On 6/14/16 10:04 PM, deadalnix wrote:
> On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote:
>> On 6/14/2016 3:38 PM, Guillaume Boucher wrote:
>>> Isn't it guaranteed that x.sizeof >= x.alignof?  (At least it is in C
>>> and C++.)
>>> So the alignment should be of type size_t and not of type uintptr_t.
>>>
>>> Also in general cast(uint)ptr%alignment is wrong since alignment does
>>> not need
>>> to be 32 bit.  However, cast(size_t)ptr%alignment is be correct in
>>> any case.
>>
>> There is no conceivable case where alignment will be > 32 bits, nor
>> not being a power of 2.
>
> There are many cases in which alignment in 64bits.
>
> There is nothing that says that x.sizeof >= x.alignof must be respected,
> but really, if you don't respect that, you are simply wasting space and
> cache without getting any benefit (the purpose of alignment is to avoid
> store/load across cache lines).

I think you guys are missing the point.

I can check for 64-bit alignment by casting to ubyte:

((cast(ubyte)ptr) & 0x07) == 0

Walter: I don't see why the optimizer doesn't figure out the fastest way 
to do this, even with size_t. You are logic-anding a constant.

-Steve



More information about the Digitalmars-d mailing list