If I use array:
```
extern(C++) {
void getInts(core.stdcpp.array.array!(int, 10) vec) {
foreach (int i; 0 .. 10) {
vec.at(i) = i;
}
}
}
```
```
#include
using namespace std;
void getInts(array* vector);
```
Both DMD and LDC has link error:
base.cpp:42: undefined reference to
On 19/06/2023 5:54 PM, mw wrote:
Ha, I saw vector.d there, So I can use this vector.d as the D side of
C++'s std::vector?
Probably, I just don't know how well tested it is.
But worth a go!
On Monday, 19 June 2023 at 05:56:54 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 19/06/2023 5:54 PM, mw wrote:
Ha, I saw vector.d there, So I can use this vector.d as the D
side of C++'s std::vector?
Probably, I just don't know how well tested it is.
But worth a go!
```
import
On Sunday, 18 June 2023 at 20:24:10 UTC, Cecil Ward wrote:
I wasn’t intending to use DMD, rather ldc if possible or GDC
because of their excellent optimisation, in which DMD seems
lacking, is that fair? (Have only briefly looked at dmd+x86 and
haven’t given DMD’s back end a fair trial.)
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
target.obj: target.c include1.h include2.h cc.exe
cc target.c
and you either have to pray that you have kept the list of .h
files that are mentioned inside target.c and other .h files
referenced recursively from within these .h
On Monday, 19 June 2023 at 08:46:31 UTC, rempas wrote:
On Sunday, 18 June 2023 at 20:17:50 UTC, Cecil Ward wrote:
target.obj: target.c include1.h include2.h cc.exe
cc target.c
and you either have to pray that you have kept the list of .h
files that are mentioned inside target.c and other
On Sunday, 18 June 2023 at 05:01:16 UTC, Cecil Ward wrote:
On Sunday, 18 June 2023 at 04:54:08 UTC, Cecil Ward wrote:
Is it true that this doesn’t always work (in either branch)?
float4 a,b;
static if (__traits(compiles, a/b))
c = a / b;
else
c[] = a[] / b[];
It's because SIMD stuff
On Monday, 19 June 2023 at 12:48:26 UTC, Cecil Ward wrote:
If I have sources to all the library routines, not libraries or
.obj files. I am simply completely ignorant about the D tools
including DUB, so off to do some reading. I’ve just been seeing
how good LDC and GDC are, and the answer is
I'm doing some experiments with ldc2 GC, by instrumenting it and
printing basic information (what is allocated and freed)
My first tests are made on this sample :
```
cat test2.d
import core.memory;
class Bar { int bar; }
class Foo {
this()
{
this.bar = new Bar;
}
Bar bar;
}
On 6/19/23 12:13 PM, axricard wrote:
I'm doing some experiments with ldc2 GC, by instrumenting it and
printing basic information (what is allocated and freed)
My first tests are made on this sample :
```
cat test2.d
import core.memory;
class Bar { int bar; }
class Foo {
this()
{
On 6/19/23 12:51 PM, Anonymouse wrote:
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer wrote:
In this specific case, most likely it's a stale register or stack
reference. One way I usually use to ensure such things is to call a
function that destroys the existing stack:
```d
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In general, the language does not guarantee when the GC will
collect your item.
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a function
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a function that destroys the existing stack:
```d
void clobber()
{
int[2048] x;
}
```
On Monday, 19 June 2023 at 16:43:30 UTC, Steven Schveighoffer
wrote:
In general, the language does not guarantee when the GC will
collect your item.
In this specific case, most likely it's a stale register or
stack reference. One way I usually use to ensure such things is
to call a
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66:ref inout(T) opIndex(size_t index) inout pure nothrow
@safe @nogc { return as_array[index]; }
```
I'm wondering if the `ref` and `inout` redundant here? They
On 6/19/23 2:01 PM, axricard wrote:
Does it mean that if my function _func()_ is as following (say I don't
use clobber), I could keep a lot of memory for a very long time (until
the stack is fully erased by other function calls) ?
```
void func()
{
Foo[2048] x;
foreach(i; 0 ..
On 6/19/23 2:19 PM, mw wrote:
Hi, I just saw this line:
https://github.com/dlang/dmd/blob/master/druntime/src/core/stdcpp/vector.d#LL66C5-L66C39
```
66: ref inout(T) opIndex(size_t index) inout pure nothrow @safe
@nogc { return as_array[index]; }
```
I'm wondering if the `ref` and
17 matches
Mail list logo
