On Saturday, 5 December 2015 at 04:34:03 UTC, Steven
Schveighoffer wrote:
I think what Vladimir is referring to is an align(1) struct:
struct Foo
{
align(1):
ubyte a;
int b;
}
Foo foo;
int *ptr = &foo.b; // not pointing at aligned integer
I think we should identify that tagged* does n
On 12/4/15 10:57 PM, deadalnix wrote:
On Saturday, 5 December 2015 at 00:33:15 UTC, Vladimir Panteleev wrote:
On Friday, 4 December 2015 at 23:38:08 UTC, deadalnix wrote:
On Friday, 4 December 2015 at 10:31:19 UTC, Vladimir Panteleev wrote:
I realized this was off after posting but I don't und
On Saturday, 5 December 2015 at 00:33:15 UTC, Vladimir Panteleev
wrote:
On Friday, 4 December 2015 at 23:38:08 UTC, deadalnix wrote:
On Friday, 4 December 2015 at 10:31:19 UTC, Vladimir Panteleev
wrote:
I realized this was off after posting but I don't understand
your reasoning either. The size
On Friday, 4 December 2015 at 23:38:08 UTC, deadalnix wrote:
On Friday, 4 December 2015 at 10:31:19 UTC, Vladimir Panteleev
wrote:
I realized this was off after posting but I don't understand
your reasoning either. The size and alignment just put a bound
on the number of bits, but without verif
On Friday, 4 December 2015 at 10:31:19 UTC, Vladimir Panteleev
wrote:
I realized this was off after posting but I don't understand
your reasoning either. The size and alignment just put a bound
on the number of bits, but without verification in the setter
you can't be sure, right?
If one of t
On Friday, 4 December 2015 at 01:35:45 UTC, deadalnix wrote:
First it check for alignement. Considering this :
On Thursday, 3 December 2015 at 09:11:12 UTC, Vladimir
Panteleev wrote:
True, assuming that:
1. The pointers are still aligned at machine word boundaries
No. The pointer needs to b
On Thursday, 3 December 2015 at 12:45:10 UTC, Steven
Schveighoffer wrote:
Do you have any rationale to prefer arbitrary bitfield pointers
over GC safe ones?
There are various valid use of this in HHVM for instance. One of
the nasty trick that is used is to allocate the memory to JIT
code in
First it check for alignement. Considering this :
On Thursday, 3 December 2015 at 09:11:12 UTC, Vladimir Panteleev
wrote:
True, assuming that:
1. The pointers are still aligned at machine word boundaries
No. The pointer needs to be aligned as per underlying data type
expectation. If it isn'
On 12/3/15 8:02 AM, Steven Schveighoffer wrote:
An interior pointer is a pointer that is *properly aligned* but does not
point at the first byte of a piece of memory. taggedPointer and
taggedClassRef create *interior pointers*, not *misaligned pointers*.
Andrei's proposal will create *misaligned
On 12/3/15 9:28 AM, Andrei Alexandrescu wrote:
On 12/03/2015 07:45 AM, Steven Schveighoffer wrote:
taggedPointer and taggedClassRef are GC safe (despite the incorrect
warning listed in the docs). Your proposed mechanism is not.
It can be restricted to support what tagged* do.
This is a poss
On Thursday, 3 December 2015 at 14:24:52 UTC, Andrei Alexandrescu
wrote:
On 12/03/2015 06:13 AM, Vladimir Panteleev wrote:
You said that "at the end of the day there's documentation". I
would
argue that at least in this case, it may not be enough.
Consider, for
example, a hypothetical user type
On Thursday, 3 December 2015 at 13:02:24 UTC, Steven
Schveighoffer wrote:
First I will say, there is confusion on what is valid and what
is not. Misaligned pointers are pointers that are stored
misaligned. In other words, they are stored not on a 4-byte or
8-byte boundary for 32 bits or 64 bits
On 12/03/2015 07:45 AM, Steven Schveighoffer wrote:
On 12/2/15 6:51 PM, Andrei Alexandrescu wrote:
On 12/02/2015 06:04 PM, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei Alexandrescu
wrote:
Once done, this is a fantastic example of (a) the power of generative
programmi
On 12/03/2015 06:13 AM, Vladimir Panteleev wrote:
You said that "at the end of the day there's documentation". I would
argue that at least in this case, it may not be enough. Consider, for
example, a hypothetical user type "Pack", which takes a tuple/struct and
automatically arranges the fields i
On 12/3/15 7:20 AM, Marc Schütz wrote:
On Wednesday, 2 December 2015 at 23:38:33 UTC, deadalnix wrote:
On Wednesday, 2 December 2015 at 23:04:16 UTC, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei Alexandrescu
wrote:
Once done, this is a fantastic example of (a) the po
On 12/2/15 6:51 PM, Andrei Alexandrescu wrote:
On 12/02/2015 06:04 PM, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of generative
programming, and (b) the advantages of using library facilitie
On Wednesday, 2 December 2015 at 23:38:33 UTC, deadalnix wrote:
On Wednesday, 2 December 2015 at 23:04:16 UTC, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b) t
On Thursday, 3 December 2015 at 00:31:46 UTC, Andrei Alexandrescu
wrote:
Nice. What I'd say is that at the end of the day there's
documentation. -- Andrei
Just to provide a bit of perspective...
Although memory corruption may not seem so scary in short-lived
programs where it can be trivially
On Thursday, 3 December 2015 at 01:31:05 UTC, rsw0x wrote:
On Wednesday, 2 December 2015 at 19:54:26 UTC, Vladimir
Panteleev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b
On Wednesday, 2 December 2015 at 19:54:26 UTC, Vladimir Panteleev
wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b) the advantages of using
library facilities instead of bui
On 12/2/15 7:22 PM, Vladimir Panteleev wrote:
On Thursday, 3 December 2015 at 00:08:17 UTC, Vladimir Panteleev wrote:
On Wednesday, 2 December 2015 at 19:59:14 UTC, Andrei Alexandrescu wrote:
On 12/02/2015 02:54 PM, Vladimir Panteleev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andre
On Thursday, 3 December 2015 at 00:08:17 UTC, Vladimir Panteleev
wrote:
On Wednesday, 2 December 2015 at 19:59:14 UTC, Andrei
Alexandrescu wrote:
On 12/02/2015 02:54 PM, Vladimir Panteleev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
[...]
Warning, this is
On Wednesday, 2 December 2015 at 19:59:14 UTC, Andrei
Alexandrescu wrote:
On 12/02/2015 02:54 PM, Vladimir Panteleev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative
programming, and (b) the ad
On Wednesday, 2 December 2015 at 23:51:40 UTC, Andrei
Alexandrescu wrote:
On 12/02/2015 06:38 PM, deadalnix wrote:
Yeah, that'd be great if we could remove these scary warning
about the
GC on these, this is only FUD. It works just fine with the GC.
LSBs may work, MSBs most likely not. -- Andr
On 12/02/2015 06:38 PM, deadalnix wrote:
Yeah, that'd be great if we could remove these scary warning about the
GC on these, this is only FUD. It works just fine with the GC.
LSBs may work, MSBs most likely not. -- Andrei
On 12/02/2015 06:04 PM, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of generative
programming, and (b) the advantages of using library facilities
instead of built-in features.
https://issues.
On Wednesday, 2 December 2015 at 23:04:16 UTC, ZombineDev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b) the advantages of using
library facilities instead of built-in fe
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b) the advantages of using library
facilities instead of built-in features.
https://issues.dlang.org/show_bug.cgi?id=15397
Who woul
On 12/02/2015 02:54 PM, Vladimir Panteleev wrote:
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of generative
programming, and (b) the advantages of using library facilities
instead of built-in features.
https:/
On Wednesday, 2 December 2015 at 19:39:47 UTC, Andrei
Alexandrescu wrote:
Once done, this is a fantastic example of (a) the power of
generative programming, and (b) the advantages of using library
facilities instead of built-in features.
https://issues.dlang.org/show_bug.cgi?id=15397
Who woul
Once done, this is a fantastic example of (a) the power of generative
programming, and (b) the advantages of using library facilities instead
of built-in features.
https://issues.dlang.org/show_bug.cgi?id=15397
Who would want to take it?
Andrei
31 matches
Mail list logo
