<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I'm probably missing what this proposal is about - but wouldn't this increase build time for everyone even if I don't use this instantiation? So if I'm not interested in YaspGrid then I pay the instatiation cost while building dune-grid?</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" data-keeper-edited="yes">
Why is this actually needed in the core modules? If someone wants speedup for yaspgrid for the executables in their own 'dune-foo' module. they can instantiate in a 'libdunefoo' and will also have it downstream from dune-foo? They could even have a `dune-yaspgrid`
module with only this library in it and have `dune-foo` depend on or suggest `dune-yaspgrid` with exactly the same effect but without changing anything in dune-grid and requiring opt-in/opt-out in the configuration.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Andreas<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Dune-devel <dune-devel-bounces@lists.dune-project.org> on behalf of Carsten Gräser <graeser@mi.fu-berlin.de><br>
<b>Sent:</b> 17 February 2021 12:04<br>
<b>To:</b> dune-devel@lists.dune-project.org <dune-devel@lists.dune-project.org><br>
<b>Subject:</b> Re: [Dune-devel] Explicit template instantiation</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Am 16.02.21 um 23:53 schrieb Simon Praetorius:<br>
>> Maybe this could be done in an opt-in fashion:<br>
>><br>
>> * Do not use `extern template` in the header.<br>
>> * Do some documented explicit instantiation in the library.<br>
>> * Users may (but don't have to) prohibit implicit instantiation<br>
>> by using `extern template ...` in their application after<br>
>> including the header. For sure this can only be done for<br>
>> those well-documented instantiations contained in the lib.<br>
>> * If the user does not use `extern template ...` she will<br>
>> get implicit instantiation as usual.<br>
> <br>
> I don't know what is the best way to go. But I'm afraid that not<br>
> writing the "extern termplate" in the headers would be more<br>
> irritating than helping. We would just gain longer compile times for<br>
> the libraries - not the opposite. And then the explicit instantiation<br>
I don't understand this argument:<br>
<br>
* If the template was implicitly instantiated in the library before,<br>
doing it explicitly now should not increase library build time.<br>
* If the template was not implicitly instantiated in the library before,<br>
you must instantiate it explicitly now, which increases library build<br>
time. Otherwise you can't use it downstream. At some place you have<br>
to do the instantiation. The whole purpose of the proposal seems to<br>
be, to move this cost upward in the build hierarchy in order to prevent<br>
paying it multiple times downstream.<br>
<br>
> (with prevented implicit instantiation) would mostly not be used. But<br>
> it is something very positive for the user. I think just "well<br>
> documentation" is not enough.<br>
If there is some performance penalty, introducing this silently<br>
is IMO a no-go. Hence I would prefer an opt-in approach.<br>
An alternative to the fully manual approach I proposed before,<br>
would be to provide a single header (per module) with all the<br>
`extern template...` declarations for the instances contained<br>
in the library. Then the user can opt-in by including this header.<br>
<br>
Best,<br>
Carsten<br>
<br>
_______________________________________________<br>
Dune-devel mailing list<br>
Dune-devel@lists.dune-project.org<br>
<a href="https://lists.dune-project.org/mailman/listinfo/dune-devel">https://lists.dune-project.org/mailman/listinfo/dune-devel</a></div>
</span></font></div>
</body>
</html>