betterC mir-cv

[9il]

betterC mir-cv

[wilzbach]

Even better: it would be awesome if we could automatically enforce that the low-level part is betterC with Travis or CircleCi!

[ljubobratovicrelja]

https://github.com/libmir/mir-algorithm/wiki/BetterC-for-Mir

Thanks!

[ljubobratovicrelja]

Good idea! Regarding that, can I ask of you this one thing - could you lay out (in readme of this new repo, or anywhere convenient) rules that have to be obeyed in order to library stays betterC compliant? So we have, sort of like the guide to follow, when porting existing functions from present dcv to the new one.

Another thing - I suppose in order to be linkable from other languages, the whole library has to be built with these rules, right? In case we'd like to have high level (D) layer that has less restrictions, and for e.g. uses the GC, I suppose we'd have to separate this layer as another library, which would be a wrapper to low-level (betterC) library, correct? It would be awesome If you could explain those architectural requirements also.

[9il]

https://github.com/libmir/mir-algorithm/wiki/BetterC-for-Mir
https://github.com/libmir/mir-cv

[9il]

Another thing - I suppose in order to be linkable from other languages, the whole library has to be built with these rules, right? In case we'd like to have high level (D) layer that has less restrictions, and for e.g. uses the GC, I suppose we'd have to separate this layer as another library, which would be a wrapper to low-level (betterC) library, correct? It would be awesome If you could explain those architectural requirements also.

A generic betterC library can contain GC code, but it should be restricted small API subset. For example, only slice uses GC in mir-algorithm.

[9il]

Even better: it would be awesome if we could automatically enforce that the low-level part is betterC with Travis or CircleCi!

This can be done for precompiled library.