Re: Memory management by interfacing C/C++
On Monday, 29 April 2019 at 14:38:54 UTC, 9il wrote: On Saturday, 27 April 2019 at 22:25:58 UTC, Ferhat Kurtulmuş wrote: [...] Hello Ferhat, You can use RCArray!T or Slice!(RCI!T) [1, 2] as common thread safe @nogc types for D and C++ code. See also integration C++ example [3] and C++ headers [4]. RCArray (fixed length) [1] http://mir-algorithm.libmir.org/mir_rc_array.html RCSlice (allows to get subslices) [2] http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#rcslice C++ integration example [3] https://github.com/libmir/mir-algorithm/tree/master/cpp_example C++ headers [4] https://github.com/libmir/mir-algorithm/tree/master/include/mir An opencv d binding using ndslice substituting cv::Mat would be useful like opencv-python using numpy. However, I started opencvd about a month ago, and I am very new to d. For now, I am the only contributor with zero mir.ndslice experience. When I gain more experience with ndslice, I would try it as substitution for cv::Mat. Thank you for links 9il. I will take a look at them.
Re: Logging best practices
On Sat, Apr 27, 2019 at 2:55 AM Andre Pany via Digitalmars-d-learn
wrote:
>
> On Thursday, 25 April 2019 at 10:33:00 UTC, Vladimirs Nordholm
> wrote:
> > Hello.
> >
> > Is there a current "Best Practices" for logging in D?
> >
> > For the actual logging, I know of `std.experimental.logger`.
> > However, the `experimental` has kept me away from it.
> >
> > Is it good, or are there any better alternatives?
>
> I also use it for all of my applications. But I really miss a
> RotatedTimeFileLogger. One big log file which will grow and grow
> is not that usuable in cloud environment.
>
std.experimenetal.logger is very limited with the feature set it
offers. You can't set custom log patterns, etc.
If you use AWS (docker), you could log to stdout and let the
cloudwatch do all the magic. Based on a config parameter, you can
enable/disable logging to a file.
module my.logger;
import std.experimental.logger;
__gshared MultiLogger log;
private __gshared FileLogger fileLog;
private __gshared FileLogger onScreen;
shared static this()
{
import std.file;
import std.stdio : stdout, File;
auto file = File("LMS.log", "a");
fileLog = new FileLogger(file);
onScreen = new FileLogger(stdout);
log = new MultiLogger();
if (cfg.logToFile)
log.insertLogger("file", fileLog);
log.insertLogger("stdout", onScreen);
}
> Also I haven't found out wheter it is safe / how to write from
> different threads to the same log file.
std.experimental.logger is perfectly thread safe. However printing the
logging thread ID is still pending with this PR
https://github.com/dlang/phobos/pull/6978
Re: srand time error uint/long
On Monday, 29 April 2019 at 14:39:29 UTC, rikki cattermole wrote: float f = uniform01(); Its already initialized on module load. If you do want to custom seed it, you'll probably want to cast the seed to uint instead and have your own instance of the random number generator. On Monday, 29 April 2019 at 15:24:41 UTC, Paul Backus wrote: https://dlang.org/phobos/std_random.html#unpredictableSeed Thanks!
Re: srand time error uint/long
On Monday, 29 April 2019 at 14:36:49 UTC, number wrote: And how to use the d libs instead? is this the way to go? ``` Random rnd = Random(Clock.currTime().second); uniform01(rnd); //(or whatever) ``` https://dlang.org/phobos/std_random.html#unpredictableSeed
srand time error uint/long
How to call srand() with time()?
```
void main()
{
import core.stdc.stdlib : rand, srand;
import core.stdc.time : time;
srand(time(null));
}
```
Error: function core.stdc.stdlib.srand(uint seed) is not callable
using argument types (long)
cannot pass argument time(null) of type long to parameter uint
seed
https://run.dlang.io/is/ner0Lx
And how to use the d libs instead? is this the way to go?
```
Random rnd = Random(Clock.currTime().second);
uniform01(rnd); //(or whatever)
```
Re: Memory management by interfacing C/C++
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:
```
//declaration in d
struct IntVector {
int* val;
int length;
}
// in cpp
typedef struct IntVector {
int* val;
int length;
} IntVector;
// cpp function returning a struct containing an array pointer
allocated with "new" op.
IntVector Subdiv2D_GetLeadingEdgeList(Subdiv2D sd){
std::vector iv;
sd->getLeadingEdgeList(iv);
int *cintv = new int[iv.size()]; // I don't call delete
anywhere?
for(size_t i=0; i < iv.size(); i++){
cintv[i] = iv[i];
}
IntVector ret = {cintv, (int)iv.size()};
return ret;
};
// call extern c function in d:
extern (C) IntVector Subdiv2D_GetLeadingEdgeList(Subdiv2d sd);
int[] getLeadingEdgeList(){
IntVector intv = Subdiv2D_GetLeadingEdgeList(this);
int[] ret = intv.val[0..intv.length]; // just D magic.
Still no delete anywhere!
return ret;
}
```
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
Hello Ferhat,
You can use RCArray!T or Slice!(RCI!T) [1, 2] as common thread
safe @nogc types for D and C++ code.
See also integration C++ example [3] and C++ headers [4].
RCArray (fixed length)
[1] http://mir-algorithm.libmir.org/mir_rc_array.html
RCSlice (allows to get subslices)
[2]
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#rcslice
C++ integration example
[3]
https://github.com/libmir/mir-algorithm/tree/master/cpp_example
C++ headers
[4]
https://github.com/libmir/mir-algorithm/tree/master/include/mir
Re: srand time error uint/long
float f = uniform01(); Its already initialized on module load. If you do want to custom seed it, you'll probably want to cast the seed to uint instead and have your own instance of the random number generator.
Re: Memory management by interfacing C/C++
On Monday, 29 April 2019 at 00:53:34 UTC, Paul Backus wrote:
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++.
Thank you. It is now like:
/* c/cpp side */
extern (C) void deleteArr(void* arr);
void deleteArr(void* arr){
delete[] arr;
}
struct IntVector Subdiv2D_GetLeadingEdgeList(Subdiv2D sd){
std::vector iv;
sd->getLeadingEdgeList(iv);
int *cintv = new int[iv.size()];
for(size_t i=0; i < iv.size(); i++){
cintv[i] = iv[i];
}
IntVector ret = {cintv, (int)iv.size()};
return ret;
};
/* c/cpp side */
...
int[] getLeadingEdgeList(){ // d function
IntVector intv = Subdiv2D_GetLeadingEdgeList(this);
int[] ret = intv.val[0..intv.length].dup;
deleteArr(intv.val);
return ret;
}
...
Re: DLL creation fails with undefined symbol error
fwrite, fputc - that's missing C library.
