Inherent code performance advantages of D over C?

[Manu]

On 14 December 2013 03:07, Dicebot <public at dicebot.lv> wrote:

> On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
>
>> On 14 December 2013 02:50, Dicebot <public at dicebot.lv> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131214/5f21c9e0/attachment.html>