Jump to page: 1 2
Thread overview
First Draft: Placement New Expression
Oct 31, 2024
Walter Bright
Nov 01, 2024
Walter Bright
Nov 01, 2024
Walter Bright
Nov 01, 2024
Paul Backus
Nov 02, 2024
Walter Bright
Oct 31, 2024
ryuukk_
Oct 31, 2024
jmh530
Oct 31, 2024
Nick Treleaven
Oct 31, 2024
Paul Backus
Oct 31, 2024
Paul Backus
Nov 02, 2024
Sönke Ludwig
Nov 10, 2024
Walter Bright
Nov 10, 2024
Timon Gehr
October 30, 2024
Based on a suggestion by Manu Evans:

https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md
October 31, 2024
I recommend that this includes allocator support.

```d
struct Allocator {
    void[] allocate(size_t, TypeInfo ti=null);
    void deallocate(void[]);
}
```

We would need a way to tie into deallocate + destroy. Say perhaps ``delete(allocator) thing;`` statement?

This little bit of convenience would be a huge QoL improvement, as it'll calculate the size needed to be allocated for you (including for say arrays). This can be a bit of paid to do properly due to overflow.

> The size of the memory object of class Type can be retrieved with the expression __traits(initSymbol, Type).length.

```d
pragma(msg, __traits(initSymbol, Foo).length);

struct Foo {
	int x;
}
```

```
onlineapp.d(1): Error: cannot determine the address of the initializer symbol during CTFE
onlineapp.d(1):        while evaluating `pragma(msg, Foo.length)`
```

We need a CTFE'able solution to this, for that argument to hold.
October 31, 2024
On 31/10/2024 7:33 PM, Richard (Rikki) Andrew Cattermole wrote:
> This little bit of convenience would be a huge QoL improvement, as it'll calculate the size needed to be allocated for you (including for say arrays). This can be a bit of paid to do properly due to overflow.

Ugh s/paid/pain/

October 31, 2024
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:
> Based on a suggestion by Manu Evans:
>
> https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

> If one desires to use classes without the GC, such as in BetterC, it's just awkward to use emplace.

Walter, you made -betterC, you are supposed to know there is no such thing as "TypeInfo", therefore no such thing as "class", it ain't -betterJava++ is it?
October 31, 2024
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:
> Based on a suggestion by Manu Evans:
>
> https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

Can you add an example?
October 31, 2024

On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:

>

Based on a suggestion by Manu Evans:

https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

>

With the placement new expression, operator new can initialize an object into any location. It replaces the functionality of core.lifetime.emplace.

It would be good if any DIP that replaces emplace could avoid violation of immutable data in @system code, or at least in @safe:
https://issues.dlang.org/show_bug.cgi?id=24795

October 31, 2024
On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:
> Based on a suggestion by Manu Evans:
>
> https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

Sounds great. No notes. 👍
October 31, 2024

On Thursday, 31 October 2024 at 18:17:56 UTC, Nick Treleaven wrote:

>

On Thursday, 31 October 2024 at 06:23:24 UTC, Walter Bright wrote:

>

Based on a suggestion by Manu Evans:

https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md

>

With the placement new expression, operator new can initialize an object into any location. It replaces the functionality of core.lifetime.emplace.

It would be good if any DIP that replaces emplace could avoid violation of immutable data in @system code, or at least in @safe:
https://issues.dlang.org/show_bug.cgi?id=24795

Easiest way to do this is to allow using a void[] for all types, not just classes.

November 01, 2024
On 10/30/2024 11:33 PM, Richard (Rikki) Andrew Cattermole wrote:
> I recommend that this includes allocator support.

An allocator should be able to deliver a void[], I'm not seeing where specialized support for it is needed.
November 01, 2024
On 10/30/2024 11:33 PM, Richard (Rikki) Andrew Cattermole wrote:
> We need a CTFE'able solution to this, for that argument to hold.

Currently, there isn't a compile time solution for the allocated size of a class object.

For CTFE, just use plain ordinary new.
« First   ‹ Prev
1 2