On Friday, 27 April 2018 at 00:21:51 UTC, sarn wrote:
I think you've got the technical answer already (just don't
link in phobos2) but I'll add my 2c that Phobosless programming
isn't just possible but realistically doable. It's a shame to
go without Phobos because it's got so much higher-level
functionality, but if you're okay with writing things from the
ground up in C-like code, it works. Most third-party D
libraries depend on Phobos, though, so it's mostly DIY and
using bindings to other languages.
Right, that’s the plan for the program itself. Even without D we
would be talking to services as directly as possible, and third
party libraries would come in as C code and be tweaked to work
in-house. Performance is paramount with this, which is why I was
so pleased to find out about the ‘-betterC’ switch in
development, even though we may have gotten by with a minimal D
runtime. The ecosystem at work here is really something else :)
On Friday, 27 April 2018 at 00:21:51 UTC, sarn wrote:
Have a look at the standard library here:
https://dlang.org/phobos/index.html
Basically, all the std.* is Phobos, and most of the core.*
stuff needs linking with the D runtime library. However,
there's a bunch of bindings to standard C stuff in core.stdc.*
that only need the C runtime and standard library, and these
come in really handy when you're not using Phobos. (There are
more platform-specific C bindings in core.sys.* that aren't
listed on that page.) Also, there are some other things in
core.bitop and core.atomic (probably more) that don't need
linking to druntime.
Right. So there isn’t anything in core.* that would be in
libphobos, only D runtime? And std.* depends on both, that is
correct? Just want to be sure there aren’t edge cases or
exceptions, it would be a handy rule of thumb.