question about call cpp class constructer without new , and define cpp delegate

[evilrat]

On Thursday, 27 June 2019 at 17:00:01 UTC, Rémy Mouëza wrote:
>
> I though support for C++ allocation had improved. In a recent 
> release, there was the addition of core.stdcpp.new, but I 
> didn't try it out:
> - http://dpldocs.info/experimental-docs/core.stdcpp.new_.html
> - https://en.cppreference.com/w/cpp/memory/new/operator_new

It seems at this moment these operators only supported on Windows.

> Are there still pitfalls to be wary of?

Not possible:

- new/delete (not entirely impossible, but requires to dig in 
compiler/library internals, generally fragile and not portable, 
not even mention that deciphering STL code is just meh...), 
though many libraries provides their own allocator/deallocator 
functions and some even provides pluggable hooks to use.
- Member functions pointers
- Multiple inheritance (tbh this is considered a bad practice 
anyway and chances to encounter it relatively small)
- lambdas?
- Exceptions? (except maybe on Windows, because of SEH)
- Template instantiations code gen(this basically requires to 
implement entire C++ compiler), what this means is that if the 
concrete template instance isn't used in a library you use you 
have to make dummy C++ function that forces compiler to emit the 
code for it.


Possible, but annoying:

- Functions with ref parameters

- Functions with const pointers to mutable data parameters
   ex: float calcStuff(float * const arr, size_t len);
It doesn't make sense in D, and I doubt there is much sense in 
C++ as well (except maybe to convey the meaning that this 
function won't try to free data).
So the workaround of course is to slap pragma mangle, which of 
course requires manually getting the mangled name for the 
function...

On Windows using MS compiler for the example above the mangled 
name will look like
   float calc(float * const arr); // ?calc@@YAMQEAM at Z
and for non const
   float calc(float * arr); // ?calc@@YAMPEAM at Z

so it is possible to do something like this
   pragma(mangle, calc.mangleof.replace("QEA","PEA"))
   float calc(float * arr);

- Some operator overloads also needs pragma mangle treatment.

- Incomplete/buggy mangling support, especially annoying with 
templates. Same treatment.


Maybe I've missed something else though, but anything not on the 
list usually works without surprises. And thanks to string 
namespaces it is now such a relief to use.