Re: Call an external program from CTFE

2024-06-25 Thread anyaburke via Digitalmars-d-learn
On Monday, 24 June 2024 at 09:52:48 UTC, realhet wrote: On Sunday, 23 June 2024 at 16:46:05 UTC, monkyyy wrote: [...] Good idea, thx! The two directions of this communication path could be: 1. LDC2 -> External process: pragma(msg, x) produces specially formatted message to the stdErr, my b

Re: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? `shared_AA.saa` should still be instance variable, not class variable, right?

2024-06-25 Thread mw via Digitalmars-d-learn
On Wednesday, 26 June 2024 at 01:17:01 UTC, mw wrote: On Tuesday, 25 June 2024 at 21:13:44 UTC, Nick Treleaven wrote: I think in the next edition of D we can forbid tail mutable initializers. It is still (or maybe only) useful for fields of a singleton class. But a compiler warning messa

Re: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? `shared_AA.saa` should still be instance variable, not class variable, right?

2024-06-25 Thread mw via Digitalmars-d-learn
On Tuesday, 25 June 2024 at 21:13:44 UTC, Nick Treleaven wrote: I think in the next edition of D we can forbid tail mutable initializers. It is still (or maybe only) useful for fields of a singleton class.

Re: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? `shared_AA.saa` should still be instance variable, not class variable, right?

2024-06-25 Thread mw via Digitalmars-d-learn
On Tuesday, 25 June 2024 at 21:13:44 UTC, Nick Treleaven wrote: On Tuesday, 25 June 2024 at 02:16:25 UTC, mw wrote: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? (and of course print out the same contents). `shared_AA.saa` should still be instance variable, not class variable, right? `

Re: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? `shared_AA.saa` should still be instance variable, not class variable, right?

2024-06-25 Thread Nick Treleaven via Digitalmars-d-learn
On Tuesday, 25 June 2024 at 02:16:25 UTC, mw wrote: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? (and of course print out the same contents). `shared_AA.saa` should still be instance variable, not class variable, right? `saa` is an instance variable, but both `foo.x.saa` and `foo.y.sa

Re: __asm LDC2: Attribute 'elementtype' type does not match parameter!

2024-06-25 Thread realhet via Digitalmars-d-learn
Update: I downloaded the latest LDC. (I waited with this version catch up long ago.) The above __asm inlining works fine on version LDC2 1.38.

__asm LDC2: Attribute 'elementtype' type does not match parameter!

2024-06-25 Thread realhet via Digitalmars-d-learn
Hi, I'm switching from LDC2 1.28 to 1.35, and trying to solve some problems on the way. Target: 64bit Windows. The problematic code: ``` const tmp = __asm!size_t( "pcmpestri $5,$3,$1" // 01 2 3 45 , "={RCX},x,{RAX},*p,{RDX},i,~{flags}", charSetVec

Re: Why `foo.x.saa.aa` and `foo.y.saa.aa` is the same? `shared_AA.saa` should still be instance variable, not class variable, right?

2024-06-25 Thread Richard (Rikki) Andrew Cattermole via Digitalmars-d-learn
On 25/06/2024 3:38 PM, mw wrote: Why D choose to be different here? i.e. |shared_AA_class saa = new shared_AA_class()| only evaluate only once, and even force it must be evaluate-able at compile time? That has nothing to do with it. Every type in D has an initialized value, that everything st