On Sunday, 28 April 2019 at 23:10:24 UTC, Ferhat Kurtulmuş wrote:
You are right. I am rewriting the things using mallocs, and
will use core.stdc.stdlib.free on d side. I am not sure if I
can use core.stdc.stdlib.free to destroy arrays allocated with
new op.
core.stdc.stdlib.free is (as the
On Sunday, 28 April 2019 at 03:54:17 UTC, Paul Backus wrote:
On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş
wrote:
Hi,
I am wrapping some C++ code for my personal project (opencvd),
and I am creating so many array pointers at cpp side and
containing them in structs. I want to
On Sunday, 28 April 2019 at 22:02:45 UTC, Alex wrote:
Any utility exists to do this?
I don't know if there's a utility, but the way I'd do it is to
simply replace a module with an empty one, recompile, and see if
it still builds. Repeat for each module. Should be reasonably
easily
I need to determine the actual modules that are used in the
project, not just imported but ones that actually are referenced.
Any utility exists to do this?
On Sunday, 28 April 2019 at 18:48:55 UTC, Adam D. Ruppe wrote:
Sounds like you have a stack corruption bug somewhere else...
memory being overwritten by something else.
Can you post any more of the context code?
I fixed it, there was a bug, but not related to stack. Not
related to memory
On Sunday, 28 April 2019 at 18:16:24 UTC, Stefanos Baziotis wrote:
In the debugger, before calling 'foo', 't' had a value (an
address) let's say 10. Stepping
into 'foo', the 't' that 'foo' got, which is supposed to have
the same value that the 't' in 'bar' had, actually had a
completely
Hello everyone,
I have a function:
void foo(T *t) { ... }
void bar(...) {
T *t = ...;
foo(t);
}
In the debugger, before calling 'foo', 't' had a value (an
address) let's say 10. Stepping
into 'foo', the 't' that 'foo' got, which is supposed to have the
same value that the 't' in
On 2019-04-28 16:18:59 +, kdevel said:
This compiles with dmd v2.085.1:
$ cat A/a.d
module A.a;
import A.b;
$ cat A/b.d
module A.b;
struct myStruct {
int i;
}
$ cat A/c.d
module A.c;
import A.a;
import A.b;
struct myOtherStruct {
myStruct ms;
}
void main ()
{
import
On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote:
On 2019-04-28 11:44:03 +, Mike Parker said:
They're different symbols because they're in different
modules. The module and package name is part of the symbol
name.
Ok, that's what I assumed too.
Just import A.b in A.a.
On 2019-04-28 11:44:03 +, Mike Parker said:
They're different symbols because they're in different modules. The
module and package name is part of the symbol name.
Ok, that's what I assumed too.
Just import A.b in A.a.
Won't help. I just commented the lines DStep generated for
On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote:
One more problem now showing up, when I do this:
A/a.d
module A.a;
struct myStruct;
A/b.d
module A.b;
struct myStruct {...}
A/c.d
module A.c;
import A;
struct
On 2019-04-27 16:30:48 +, Adam D. Ruppe said:
This will never work in D. The module needs to work by itself. It can
see public imports from another module it itself imports:
module A.c;
import A; // thanks to this, it can see a `public import A.a;` from the
A package..
But without
On 2019-04-27 16:30:48 +, Adam D. Ruppe said:
There is no "same level" really (except for the `package` protection
level); it is just inside the module or outside the module for imports.
Hi Adamn, ok, got it. The docs are indicating that the "public import"
is only working along the
13 matches
Mail list logo
