I think I am stuck in the easiest of the issues and yet it seems
I cannot get around this.
I have a C++ file:
```
class MyClass {
public:
int field;
MyClass(int a) : field(a) {}
int add(int asd) {
return asd + 1;
}
};
MyClass* instantiate(int asd) {
return new MyClas
On Wednesday, 28 September 2022 at 20:41:13 UTC, Ali Çehreli
wrote:
[...]
Ali
Thank you, that is perfect!
However that begs the following observation: it would be rather
hard to link to a C++ library only by means of 'extern (C++)' if
one should slightly rearrange C++ code as well. This sou
On Thursday, 29 September 2022 at 11:13:15 UTC, Ogi wrote:
Ali is correct. However, you don’t have to change anything on
the C++ side, just map C++ class to D struct:
[...]
Thanks, this works perfectly.
Now i see that I can even instantiate directly from D, calling
the default ctor, calling t
On Friday, 30 September 2022 at 22:56:06 UTC, Ogi wrote:
On Thursday, 29 September 2022 at 12:49:06 UTC, Riccardo M
wrote:
When interfacing to C++, disregard the keyword and look at the
implementation instead. If all its member functions are
non-virtual, map it to struct. Otherwise map it to cl
On Tuesday, 4 October 2022 at 15:42:21 UTC, Steven Schveighoffer
wrote:
Yes, you use `assumeSafeAppend`:
```d
arr.length--;
arr.assumeSafeAppend;
assert(arr.capacity != 0);
```
Now, I want to clarify that you should only use this if you are
sure you are done with the data you removed at the en
On Tuesday, 4 October 2022 at 18:18:41 UTC, Ali Çehreli wrote:
On 10/4/22 10:59, Riccardo M wrote:
> The inherent reason for `remove` to cancel previous capacity
and
> requiring new allocations is exactly to prevent overwriting
data that
> could be owned by something else?
Yes.
A related topic
