schveiguy at gmail.com
Tue Nov 26 18:55:07 UTC 2019
On 11/26/19 1:35 PM, Stefan Koch wrote:
> On Tuesday, 26 November 2019 at 17:03:04 UTC, Steven Schveighoffer wrote:
>> Every time you instantiate a template, it consumes memory in the
>> compiler for the duration of compilation.
> I've been working on this particular problem a few years ago.
> In _general_ it's not possible to categorize a template as being
> temporary or not.
> For language semantic reasons it is a requirement for every
> re-instantiated template to forward to exactly the same symbol as was
> generated during the first instantiation.
If the template ends up being an alias or an enum, then I don't know why
we need the templates used to get there to stay in memory. In my
example, the "SumAllHelper" template is an implementation detail. Nobody
ever actually uses it, just SumAll does. I can understand why SumAll
instantiations must refer to the exact same thing, but once SumAll is
done evaluating, why do we need the SumAllHelpers it used?
Can you give me an example where this breaks down if we throw it away?
> The solution that I came up with is to enhance CTFE to be able to take
> types as regular function arguments, and relax the semantic constraints
> on those type-functions.
If CTFE can take over the job of things like NoDuplicates, it might be
an alternative solution. In fact, exactly what I want is for CTFE-like
behavior -- once the function is over, everything used to make the
return value can be garbage.
In fact, using CTFE, I get:
size_t SumAllHelper(size_t val)
size_t result = 0;
while(val > 0)
result += val--;
enum SumAll(size_t x) = SumAllHelper(x);
Memory usage: 51MB. Way way better (and runs faster BTW, not
unexpectedly). But of course CTFE cannot manipulate types like this,
which is what I gather is your solution. NoDuplicates would be trivial
(just call sort and filter adjacent duplicates!) if we could use CTFE.
The benefit of instrumenting existing templates, however, may be that we
don't have to change much code. This in itself is not so much a huge
deal, because something like NoDuplicates could potentially be just
reimplemented and the usage doesn't change.
> If there is sufficient interested I can build a proof-of-conecpt.
I'm always interested in something that reduces compiler memory
footprint! I'm pushing the upper limits of my RAM, and having to
redesign my projects to fit the compiler's needs is painful.
More information about the Digitalmars-d