On Wednesday, 23 August 2017 at 09:12:19 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner
wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is don
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is done by constructor:
class Test
{
static ubyte[1000] s;
On Tue, Aug 22, 2017 at 04:28:43PM +, Moritz Maxeiner via Digitalmars-d
wrote:
[...]
> I'd argue that - as new in this case doesn't allocate on the heap, but
> in the resulting application's appropriate segments) - it should work
> like this (from a language semantics standpoint):
>
> ---
>
On Tuesday, 22 August 2017 at 15:52:48 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner
wrote:
There is a bug [1] - as others have pointed out - that the
static array isn't stored in TLS, but in global storage,
however, but that doesn't apply in this single thread
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner wrote:
There is a bug [1] - as others have pointed out - that the
static array isn't stored in TLS, but in global storage,
however, but that doesn't apply in this single threaded case.
The initializer is copied from typeinfo, that can
On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote:
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner
wrote:
I agree that it can be confusing if you try to read it with
C++ semantics [1]; the solution, however, imho is not to
change D semantics or throw warnings [2]
On Tuesday, 22 August 2017 at 13:53:05 UTC, Daniel Kozak wrote:
s/buf/bug/
On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak
wrote:
On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnb
https://issues.dlang.org/show_bug.cgi?id=2947
s/buf/bug/
On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak wrote:
> On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>>
>>> ...
>>
>>
>> I agree that it can be confusin
On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>
>> ...
>
>
> I agree that it can be confusing if you try to read it with C++ semantics
> [1]; the solution, however, imho
On 8/22/17 7:50 AM, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner wrote:
I agree that it can be confusing if you try to read it with C++
semantics [1]; the solution, however, imho is not to change D
semantics or throw warnings [2], but to refer to the D spec
[3], which states that static initializ
On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This i
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is not how C++ works
* It introduces silent shari
14 matches
Mail list logo