www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.development - First Draft: Placement New Expression

reply Walter Bright <newshound2 digitalmars.com> writes:
Based on a suggestion by Manu Evans:

https://github.com/WalterBright/documents/blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md
Oct 30
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Oct 30
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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/
Oct 30
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 01
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 02/11/2024 8:53 AM, Walter Bright wrote:

 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.


The specialized support is that the compiler will call ``allocate`` with 
the appropriate size for you.

```d
T* t = new(allocator)T;
```

Is a whole lot better than:

```d
T* t = new(allocator.allocate(T.sizeof))T;
```

Especially with dynamic arrays, classes, structs all having different 
size calculations that you need to do.

Otherwise, I see no benefit when using allocators to use this syntax. 
Might as wrap it with the free-function ``make`` and ``makeArray`` that 
calls ``emplace``.

This will definitely come up again after implementation, it's too good 
of a QoL addition to not add.
Nov 01
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Nov 01
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 1 November 2024 at 19:56:04 UTC, Walter Bright wrote:

 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.


__traits(classInstanceSize, T) works at compile time.
Nov 01
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/1/2024 1:02 PM, Paul Backus wrote:

 __traits(classInstanceSize, T) works at compile time.


Ehhxcellent!!
Nov 01
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
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?
Oct 31
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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?
Oct 31
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
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
Oct 31
parent Paul Backus <snarwin gmail.com> writes:
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.
Oct 31
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
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. 👍
Oct 31
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
After thinking about this a bit, this expression is going to have to be 
`` system``.

Unfortunately this compiles:

```d
cast(void[])new int[1];
```

And so would this, without calling the destructor:

```d
T* t = new T(...);
new(t)T(...)
```
Nov 01
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 02/11/2024 6:47 PM, Richard (Rikki) Andrew Cattermole wrote:

 After thinking about this a bit, this expression is going to have to be 
 `` system``.
 
 Unfortunately this compiles:
 
 ```d
 cast(void[])new int[1];
 ```
 
 And so would this, without calling the destructor:
 
 ```d
 T* t = new T(...);
 new(t)T(...)
 ```


Given this, I have to ask the question, what is the purpose of adding 
this expression to the language if it cannot be `` safe``?

For `` system`` tasks like initialization it should be expected to have 
to import and call functions to do that action, as it should not occur 
in normal code.

Would it not be better to do a bit of design work on ``emplace`` instead 
to improve its usability so that it consistently has this form:

```d
size_t calculateSizeOf(T)();
size_t calculateSizeOf(T)(size_t count);
T emplace(T)(void[]);
```
Nov 01
prev sibling parent =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 31.10.2024 um 07:23 schrieb Walter Bright:

 Based on a suggestion by Manu Evans:
 
 https://github.com/WalterBright/documents/ 
 blob/5d65426a4e5c434d571e76ae800a267a610bf394/placementnew.md


Should probably mention the old "class allocators":

https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators
Nov 02