Hello.

i was never thinking about it, but recently i found parts of source code in my compiled D binary. they comes from code generation functions, which only used in compile time, yet still happily sits in resulting binary. are there any plans to somehow "fix" that?

i know that this is more a linker issue, but having unused code with unused parts of the source in resulting binary can be undesirable sometimes.

sure, we can "fix" this by using "functional templates" instead of CTFE functions, but this is not always handy. and i think that "functional template programming" consumes more memory than CTFE (yet i didn't check this).

for now just remember that strings from your CTFE-only functions can get into resulting binary, so don't write fun comments about your customers there. ;-)

On Wednesday, 24 December 2014 at 14:04:56 UTC, ketmar via Digitalmars-d wrote:
> Hello.
>
> i was never thinking about it, but recently i found parts of source
> code in my compiled D binary. they comes from code generation
> functions, which only used in compile time, yet still happily sits in
> resulting binary. are there any plans to somehow "fix" that?

LDC fixes that by using garbage collection of unused symbols by default.

On Wed, 24 Dec 2014 14:08:23 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Wednesday, 24 December 2014 at 14:04:56 UTC, ketmar via Digitalmars-d wrote:
> > Hello.
> >
> > i was never thinking about it, but recently i found parts of
> > source
> > code in my compiled D binary. they comes from code generation
> > functions, which only used in compile time, yet still happily
> > sits in
> > resulting binary. are there any plans to somehow "fix" that?
> 
> LDC fixes that by using garbage collection of unused symbols by default.

yet we have two other compilers too. i didn't checked what GDC does with "--gc-sections" cli switch, but i think that it doesn't matter. and DMD pollutes binaries.

and i think that DMD is most widely-used D compiler nowdays.

btw: i can't check it, but does LDC removing unused static methods too? i think it should do this, as they aren't very different from free functions internally.

On Wednesday, 24 December 2014 at 14:15:40 UTC, ketmar via Digitalmars-d wrote:
> yet we have two other compilers too. i didn't checked what GDC does
> with "--gc-sections" cli switch, but i think that it doesn't matter.

GDC is not there yet but I remember someone working on it. It needs tweaks to runtime symbol emitting.

> and DMD pollutes binaries.

DMD is not much suitable for anything but experiments and debugging anyway.

> and i think that DMD is most widely-used D compiler nowdays

Those who care about generated binaries don't use DMD, that simple

On Wed, 24 Dec 2014 14:20:24 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> DMD is not much suitable for anything but experiments and debugging anyway.
i was thinking the same, but i found that code produced by DMD is acceptable in most cases. there is no much need in thightly optimized code for most tasks, as tasks tend to be either bound by I/O or by user. i found that even some real-time graphics is ok with DMD.

so i can't agree with you on this matter.

> > and i think that DMD is most widely-used D compiler nowdays
> Those who care about generated binaries don't use DMD, that simple
besides, it's not always possible to use GDC or LDC, as they tend to be off by at least one frontend/phobos version, or have some unfixed bugs that prevents building binary.

On Wednesday, 24 December 2014 at 14:08:25 UTC, Dicebot wrote:
> On Wednesday, 24 December 2014 at 14:04:56 UTC, ketmar via Digitalmars-d wrote:
>> Hello.
>>
>> i was never thinking about it, but recently i found parts of source
>> code in my compiled D binary. they comes from code generation
>> functions, which only used in compile time, yet still happily sits in
>> resulting binary. are there any plans to somehow "fix" that?
>
> LDC fixes that by using garbage collection of unused symbols by default.

Does DMD/Optlink on Windows do this too? I've noticed that using DMD/Optlink on Windows, my executable is 4MB for unittests on a module that uses a lot of CTFE template methods, while with DMD/ld on Linux (and I believe GDC/ld as well), the same test executable is over 40MB.

On 12/24/2014 7:10 AM, Kapps wrote:
> Does DMD/Optlink on Windows do this too? I've noticed that using DMD/Optlink on
> Windows, my executable is 4MB for unittests on a module that uses a lot of CTFE
> template methods, while with DMD/ld on Linux (and I believe GDC/ld as well), the
> same test executable is over 40MB.

You can find out what is in an executable by linking with the /MAP option.

On Wed, 24 Dec 2014 15:10:17 +0000
Kapps via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Wednesday, 24 December 2014 at 14:08:25 UTC, Dicebot wrote:
> > On Wednesday, 24 December 2014 at 14:04:56 UTC, ketmar via Digitalmars-d wrote:
> >> Hello.
> >>
> >> i was never thinking about it, but recently i found parts of
> >> source
> >> code in my compiled D binary. they comes from code generation
> >> functions, which only used in compile time, yet still happily
> >> sits in
> >> resulting binary. are there any plans to somehow "fix" that?
> >
> > LDC fixes that by using garbage collection of unused symbols by default.
> 
> Does DMD/Optlink on Windows do this too? I've noticed that using DMD/Optlink on Windows, my executable is 4MB for unittests on a module that uses a lot of CTFE template methods, while with DMD/ld on Linux (and I believe GDC/ld as well), the same test executable is over 40MB.
do `strip -s` with the executable and you will find that most of that is various debug info.

On 24/12/14 15:35, ketmar via Digitalmars-d wrote:
> besides, it's not always possible to use GDC or LDC, as they tend to be
> off by at least one frontend/phobos version, or have some unfixed bugs
> that prevents building binary.

That's something that is better fixed by adjusting the design of the frontend such that a new version can be dropped plug-and-play style on top of an arbitrary backend.

On 25 December 2014 at 16:49, Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 24/12/14 15:35, ketmar via Digitalmars-d wrote:
>>
>> besides, it's not always possible to use GDC or LDC, as they tend to be off by at least one frontend/phobos version, or have some unfixed bugs that prevents building binary.
>
>
> That's something that is better fixed by adjusting the design of the frontend such that a new version can be dropped plug-and-play style on top of an arbitrary backend.
>


First, there needs to be better ownership of tasks done in the frontend vs. backend.  Who error's about what? Who rewrites codegen? There's currently far too many moving of functionality/heuristics between both to allow this sort of plug-and-play style.  For instance, see [1].

But even if it were more pluggable, you can't expect the interface to remain constant - but at least more manageable. :)

[1]: https://github.com/D-Programming-Language/dmd/pull/4062