Re: Memory management by interfacing C/C++
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 name suggests) the standard C `free` function. As such, it can only be used to free memory allocated by the standard C functions `malloc`, `calloc`, and `realloc`. This is the same in D as it is in C and C++.
Re: Memory management by interfacing C/C++
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 learn if I am leaking memory like crazy, although I am not facing crashes so far. Is GC of D handling things for me? Here is an example: [...] The question is now: what will happen to "int *cintv" which is allocated with new operator in cpp code? I have many code similar in the project, but I have not encounter any problem so far even in looped video processings. Is GC of D doing deallocation automagically? https://github.com/aferust/opencvd D's GC only collects memory allocated with D's `new` operator. Memory allocated by C++'s `new` operator must be freed by C++'s `delete` operator. 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.
Re: Determime actual modules used
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 scriptable too.
Determime actual modules used
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?
Re: Passing a pointer to a function (by value) changes the pointer value
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 at all. As I was trying to fix the bug, the code changed unfortunately and now I try to reproduce the bug but I can't. I use visual D and one interesting point is that one file of the project was not added, but the compiler didn't yield an error although it tried to use its functions (but actually couldn't, I don't know how that can happen too. Using dmd from terminal, that never happens). I think that by adding the file, the changing of pointer value disappeared, but it could also be that in the process, I fixed a memory bug that I didn't notice (although that is quite unlikely). If I can reproduce it, I'll post it. Thanks anyway, - Stefanos
Re: Passing a pointer to a function (by value) changes the pointer value
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 different value. That caused a very bad bug... 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?
Passing a pointer to a function (by value) changes the pointer value
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 'bar' had, actually had a completely
different value. That caused a very bad bug...
I thought that D behaves in that kind of situations as C/C++, and
so I thought 'foo' should get the same value but that was not
true. Needless to say it took a lot of time to notice it
as I would never expect it and I still don't know how to fix it.
How does this happen? Is there are some specifics about pointers
and / or passing arguments that I should know?
What is also puzzling is that the project is about 4500 lines of
D code _full_ of pointers
and this happens in all calls I have checked and _somehow_ it was
working up until now.
Best regards,
Stefanos Baziotis
Re: Packages / imports & references between modules
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 std.stdio;
myOtherStruct mos;
mos.writeln;
}
Yes, as long as you are adding the imports all over, things can work.
But as said, if you creating bindings for a larger C library, this is
not practicable.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Packages / imports & references between modules
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.
Won't help. I just commented the lines DStep generated for
forward referenced structs.
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 std.stdio;
myOtherStruct mos;
mos.writeln;
}
Re: Packages / imports & references between modules
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 forward referenced structs. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Packages / imports & references between modules
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 myOtherStruct {
myStruct ms;
}
I now get an error in file A/c.d that a.a.myStruct conflicts
with a.b.myStruct. Looks like these symbols are different for
D. Is there a way to tell D that one is only a forward
reference and is the same when D sees the struct declaration
later?
They're different symbols because they're in different modules.
The module and package name is part of the symbol name. Just
import A.b in A.a.
Re: Packages / imports & references between modules
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 that explicit import, it cannot see anything outside
itself. You might be able to get away with listing the `public import`s
in package.d, and then just `import A;` in each individual module
though.
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 myOtherStruct {
myStruct ms;
}
I now get an error in file A/c.d that a.a.myStruct conflicts with
a.b.myStruct. Looks like these symbols are different for D. Is there a
way to tell D that one is only a forward reference and is the same when
D sees the struct declaration later?
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Re: Packages / imports & references between modules
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 nested import chain. Maybe it's possible to
make this much more clear? I don't know how to submit doc enhancements
or a comment what should be enhanced.
But I see what you are doing now...
A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}
This will never work in D. The module needs to work by itself. It can
see public imports from another module it itself imports:
Aha, that was the missing link for me.
module A.c;
import A; // thanks to this, it can see a `public import A.a;` from the
A package..
Ok, at least I can use such a simple full package import. Are there are
any disadvantages when I just import everything?
But without that explicit import, it cannot see anything outside itself.
Ok.
You might be able to get away with listing the `public import`s in
package.d, and then just `import A;` in each individual module though.
Yes, going to check that option.
But it won't just inherit stuff from other modules, like C's #include
does. A D module is parsed independently of other modules.
Got it.
maybe dstep could automatically add imports to generated files too.
Going to submit an issue for this. Thanks for your answer, helps a lot.
--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
