Reading Dicom files in Dlang

[Rémy Mouëza]

On Monday, 3 June 2019 at 14:19:40 UTC, Rnd wrote:
> On Friday, 31 May 2019 at 16:43:28 UTC, rnd wrote:
>> On Friday, 31 May 2019 at 13:49:02 UTC, KnightMare wrote:
>>>>   struct Range {
>>>>     private __vector(ushort) _outer;
>>>>     private size_t _a, _b;
>>>>
>>>>     this(vector(ushort) data, size_t a, size_t b) {   // 
>>>> <<<<<<<< line 457
>>>>       _outer = data;
>>>>       _a = a;
>>>>       _b = b;
>>>>     }
>>>
>>> imo problem is in string
>>> private __vector(ushort)_outer;
>>> it looks like template(vector!ushort) or function or this is 
>>> vector from core.simd
>>> and replacing it to private long _outer; fix the problem
>>> paste code imebra.d and imebra_im.d to someplace
>>
>> Best to download it from https://imebra.com/get-it/ so that 
>> all files are available to you.
>
> I am still waiting for someone to help me with this.
>
> Can we directly call C functions from D without going through 
> swig?

We can call C functions directly from D. First, the functions 
must be declared in D, as D's syntax is different from C's.

There exists tools to help us with that :
- dstep, https://code.dlang.org/packages/dstep
- dpp, https://code.dlang.org/packages/dpp
The latter, dpp, acts like a preprocessor to allow inclusion with 
`#include` as would be done with C header files.

The swig D module is quite old and I would presume it is outdated 
- but I may be wrong.

Note that the standard C library is available in the `core.stdc` 
modules.

Sometimes, these tools manage to translate 95% of header files 
properly, but some manual tweaking is necessary to handle the 
remaining 5%. The following page in the D documentation explains 
how to interface with C: https://dlang.org/spec/interfaceToC.html 
.
Looking at the output generally gives a good inspiration of what 
code pattern to use to fix the issues.

C++ is a different matter. The binding tool ecosystem gives more 
mixed results than with C:
- dstep does not generate declarations for C++;
- dpp is still a work in progress; the last time I looked at its 
commits, I saw some unit tests checking the binding of simple 
classes - but I wouldn't expect it to work with much of the STL;
- There exist Binderoo: https://github.com/GooberMan/binderoo 
which is a mean to script C++ game using D, less active than the 
first two, but could be helpful, I haven't researched it much. 
The author gave a presentation during DConf 2017: 
https://www.youtube.com/watch?v=2B0-jukh4TU .

The following page of the D documentation explains how to 
interface with C++: https://dlang.org/spec/cpp_interface.html .

Interfacing with C is much easier than with C++. I was once in 
need of a C++ library without any C API; I wrote a wrapper for it:
- some C++ function within an `extern "C" {}` declaration,
     - with helper function to create and delete my C++ class 
instances,
     - the main C++ methods I wanted to expose,
- a D binding declaration, exposing the previous function to D,
- a higher level D mirroring the C++ classes,
- exception were caught in the C++ `extern "C" {}` function: I 
returned a special Result struct containing a boolean status, the 
result or null, and a possible error message. I would then throw 
a D exception to let the user code handle the error.

Nowadays, D's C++ support is better. If you can restrict to just 
a subset of the library, writing a wrapper might be feasible, but 
would include wrapping part of the STL not yet in the 
`core.stdcpp` modules (for libraries using the STL).