On 14 December 2013 03:07, Dicebot <[email protected]> wrote: > On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote: > >> On 14 December 2013 02:50, Dicebot <[email protected]> wrote: >> >> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote: >>> >>> I could still REALLY do with __forceinline though. D doesn't have an >>>> effective macro. >>>> Obviously, if by 'language X' you mean 'any non-compiled language with >>>> pointers', then I totally agree! People who make claims like you say, >>>> don't >>>> generally know what they're talking about, or what C is actually used >>>> for. >>>> >>>> >>> I believe (and have posted it over 100 times in NG already :P) D >>> absolutely needs either way to force internal linkage or good LTO symbol >>> elimination. Without preprocessor there is not much you can do to >>> eliminate >>> code duplication other than templates / CTFE - and it bloats resulting >>> executables damn lot, something that was very controllable in C. >>> >>> >> templates aren't guaranteed to inline, and they produce horrible symbol >> bloat. ctfe isn't inlining, it's pre-computation/runtime elimination. >> mixin is the closest, but it can't be used effectively in expressions, is >> horribly dangerous and generally horrible, and requires much keyword >> pollution. >> > > What I mean is that right now symbols always make their way to object > file, whenever they are inlined or not. So bloat is completely unaffected > by inlining here. And spec currently kind of prevents removing those. One > option could have been to fix `export` like > http://wiki.dlang.org/DIP45proposes and get some kind of LTO. Simpler > solution I personally would > favor is to make template symbols internally linked by default and > available only if explicitly aliased. But anything is really better than > the current state. >
Ah I see what you mean. Yes, you are correct. Any real embedded dev in the future will need to have these issues addressed as a matter of practicality.
