www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Applying Placement New to druntime and phobos

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
Now that https://github.com/dlang/dmd/pull/17057 has been merged 
are there any obvious applications of it to druntime and phobos?
Mar 03
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 3 March 2025 at 12:40:06 UTC, Per Nordlöw wrote:

 Now that https://github.com/dlang/dmd/pull/17057 has been 
 merged are there any obvious applications of it to druntime and 
 phobos?


Should all instances of `core.lifetime.emplace()` be replaced 
with a call to placement new?
Mar 03
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 3 March 2025 at 13:23:57 UTC, Per Nordlöw wrote:

 On Monday, 3 March 2025 at 12:40:06 UTC, Per Nordlöw wrote:

 Now that https://github.com/dlang/dmd/pull/17057 has been 
 merged are there any obvious applications of it to druntime 
 and phobos?


 Should all instances of `core.lifetime.emplace()` be replaced 
 with a call to placement new?


I think a good first step would be to try replacing the current 
implementation(s) of `emplace` with calls to placement new.
Mar 03
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 3 March 2025 at 15:12:20 UTC, Paul Backus wrote:

 I think a good first step would be to try replacing the current 
 implementation(s) of `emplace` with calls to placement new.


Do you mean doing this before replacing the top-level calls top 
`emplace`?
Mar 03
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 3 March 2025 at 18:57:05 UTC, Per Nordlöw wrote:

 On Monday, 3 March 2025 at 15:12:20 UTC, Paul Backus wrote:

 I think a good first step would be to try replacing the 
 current implementation(s) of `emplace` with calls to placement 
 new.


 Do you mean doing this before replacing the top-level calls top 
 `emplace`?


Yes.
Mar 03
parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Mar 2025 at 11:21, Paul Backus via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Monday, 3 March 2025 at 18:57:05 UTC, Per Nordl=C3=B6w wrote:

 On Monday, 3 March 2025 at 15:12:20 UTC, Paul Backus wrote:

 I think a good first step would be to try replacing the
 current implementation(s) of `emplace` with calls to placement
 new.


 Do you mean doing this before replacing the top-level calls top
 `emplace`?


 Yes.


Yes, this.
I've tried this already, and it reveals several implementation edge cases,
which will need to be bugged and resolved.
My plan was to try and replace the function internals with placement new
for as many cases as are working properly, and the code itself will act as
a document detailing which cases are outstanding and need resolution.
Please do contribute to this effort if you're enthusiastic! I have very
little free time rn.
Mar 03
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
Add features first, think of use cases later!
Mar 04
parent Manu <turkeyman gmail.com> writes:
On Tue, 4 Mar 2025 at 20:56, ryuukk_ via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 Add features first, think of use cases later!



Huh?
Mar 04
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 4 March 2025 at 01:27:29 UTC, Manu wrote:

 Please do contribute to this effort if you're enthusiastic! I 
 have very
 little free time rn.


Tried converting a couple of usages of `emplace` and 
`moveEmplace` in a repo of mine and discovered that I'm missing a 
way to express

`moveEmplace(x, y)`

as

`new(y) typeof(y)(__rvalue(x))`

. This doesn't always work eventough `y` being assignable from 
`x`.
Mar 04
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Mar 2025 at 21:25, Per Nordl=C3=B6w via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Tuesday, 4 March 2025 at 01:27:29 UTC, Manu wrote:

 Please do contribute to this effort if you're enthusiastic! I
 have very
 little free time rn.


 Tried converting a couple of usages of `emplace` and
 `moveEmplace` in a repo of mine and discovered that I'm missing a
 way to express

 `moveEmplace(x, y)`

 as

 `new(y) typeof(y)(__rvalue(x))`

 . This doesn't always work eventough `y` being assignable from
 `x`.


Is it this issue: https://github.com/dlang/dmd/issues/20950 ??
If not, please post repro so I can investigate.
Mar 04
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 4 March 2025 at 12:22:36 UTC, Manu wrote:

 Tried converting a couple of usages of `emplace` and 
 `moveEmplace` in a repo of mine and discovered that I'm 
 missing a way to express

 `moveEmplace(x, y)`

 as

 `new(y) typeof(y)(__rvalue(x))`

 . This doesn't always work eventough `y` being assignable from 
 `x`.


 Is it this issue: https://github.com/dlang/dmd/issues/20950 ??


Yes, it is. Thanks.
Mar 04
parent reply Manu <turkeyman gmail.com> writes:
On Wed, 5 Mar 2025 at 17:31, Per Nordl=C3=B6w via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Tuesday, 4 March 2025 at 12:22:36 UTC, Manu wrote:

 Tried converting a couple of usages of `emplace` and
 `moveEmplace` in a repo of mine and discovered that I'm
 missing a way to express

 `moveEmplace(x, y)`

 as

 `new(y) typeof(y)(__rvalue(x))`

 . This doesn't always work eventough `y` being assignable from
 `x`.


 Is it this issue: https://github.com/dlang/dmd/issues/20950 ??


 Yes, it is. Thanks.


Walter seems preoccupied at the moment, and I've been working on the move
semantics stuff. If you want to have a go at this bug, that'd be really
cool. I imagine it's probably a trivial fix; finding it is always the hard
part :P
I don't know DMD well enough to have any intuition for the codebase, so
everything takes me forever to isolate...
Mar 06
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 6 March 2025 at 08:16:28 UTC, Manu wrote:

 Walter seems preoccupied at the moment, and I've been working 
 on the move
 semantics stuff. If you want to have a go at this bug, that'd 
 be really
 cool. I imagine it's probably a trivial fix; finding it is 
 always the hard
 part :P
 I don't know DMD well enough to have any intuition for the 
 codebase, so
 everything takes me forever to isolate...


I'll try waiting for Walter on this for now.

Thanks.
Mar 06
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 4 March 2025 at 11:24:43 UTC, Per Nordlöw wrote:

 On Tuesday, 4 March 2025 at 01:27:29 UTC, Manu wrote:

 Please do contribute to this effort if you're enthusiastic! I 
 have very
 little free time rn.


 Tried converting a couple of usages of `emplace` and 
 `moveEmplace` in a repo of mine and discovered that I'm missing 
 a way to express

 `moveEmplace(x, y)`

 as

 `new(y) typeof(y)(__rvalue(x))`

 . This doesn't always work eventough `y` being assignable from 
 `x`.


For the sake of simplicity, it would be better to start with the 
overloads of `emplace` that create a brand-new object, without 
moving an existing one. That way, you will not have to deal with 
the added complication of `__rvalue` (which itself is still a 
work-in-progress).
Mar 04
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 5 March 2025 at 01:53:02 UTC, Paul Backus wrote:

 For the sake of simplicity, it would be better to start with 
 the overloads of `emplace` that create a brand-new object, 
 without moving an existing one. That way, you will not have to 
 deal with the added complication of `__rvalue` (which itself is 
 still a work-in-progress).


Alternatively, if you need to move something, you can just use 
`core.lifetime.move` for now. Replacing `move` with `__rvalue` 
can be done as a separate step.
Mar 04