On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote:

Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming.

There is more to this project than just getting a software rasterizer in D. Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming. D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C.

So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code.

So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal.


Reply via email to