--94eb2c1cf3bc9f559d054f2eb0ab
Content-Type: text/plain; charset="UTF-8"

On Wed, May 10, 2017 at 7:14 PM Mingxin Wang <wmx16835vv@163.com> wrote:

> A type satisfies "concept template Iterator" if and only if all the
> concepts above are satisfied! Shall we turn these stuff into a runtime
> wrapper? I suppose not, because that will introduce much runtime overhead,
> and I prefer to define a proxy instead. After all, only 3 member functions
> is required to be abstract at runtime.
>

Why would a compiler generate code for a runtime wrapper for a concept that
isn't used as a runtime wrapper at any point in the program?

If you say it'd need to do that to do runtime wrapper inheritance for all
the base concepts, then this is a particularly flawed approach. (As are
many OOP hierarchies.)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTaT%3D4Km%3DpCDwknhFTKW%3DmXphMR%2Ba3mc12x3eKzfD3U8g%40mail.gmail.com.

--94eb2c1cf3bc9f559d054f2eb0ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, May 10=
, 2017 at 7:14 PM Mingxin Wang &lt;<a href=3D"mailto:wmx16835vv@163.com">wm=
x16835vv@163.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><font face=3D"georgia, serif">A type satisfies &quot;concept=
 template Iterator&quot; if and only if all the concepts above are satisfie=
d! Shall we turn these stuff into a runtime wrapper? I suppose not, because=
 that will introduce much runtime overhead, and I prefer to define a proxy =
instead. After all, only 3 member functions is required to be abstract at r=
untime.</font></div></div></blockquote><div><br></div><div>Why would a comp=
iler generate code for a runtime wrapper for a concept that isn&#39;t used =
as a runtime wrapper at any point in the program?</div><div><br></div><div>=
If you say it&#39;d need to do that to do runtime wrapper inheritance for a=
ll the base concepts, then this is a particularly flawed approach. (As are =
many OOP hierarchies.)</div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTaT%3D4Km%3DpCDwknhFTKW%3DmXph=
MR%2Ba3mc12x3eKzfD3U8g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdTa=
T%3D4Km%3DpCDwknhFTKW%3DmXphMR%2Ba3mc12x3eKzfD3U8g%40mail.gmail.com</a>.<br=
 />

--94eb2c1cf3bc9f559d054f2eb0ab--

.

------=_Part_5432_198983327.1494491532278
Content-Type: multipart/alternative;
 boundary="----=_Part_5433_413441310.1494491532279"

------=_Part_5433_413441310.1494491532279
Content-Type: text/plain; charset="UTF-8"


>
> Why would a compiler generate code for a runtime wrapper for a concept
> that isn't used as a runtime wrapper at any point in the program?
> If you say it'd need to do that to do runtime wrapper inheritance for all
> the base concepts, then this is a particularly flawed approach. (As are
> many OOP hierarchies.)
>

Unlike concepts which can be treated as boolean constants at runtime,
proxies are real types. The same as other types, any proxy object has a
compile-time-defined data structure which requires a certain scale of
memory to be constructed at runtime.

It is possible that some expressions defined in a concept can be ignored
when building a runtime wrapper according to the concept at compile-time,
but this is only what we expect from the compiler, and no one can promise
that. Besides, since a proxy is a type, the value of a proxy may be passed
through compile units (definitions and functions maybe defined in different
source files), and the compiler may know nothing about how the value is
used in other compile units. So there are limitations for compiler
optimizations.

By the way, there is a "bug" in the possible implementation I posted, which
is a semantic error, but will not affect the correctness of the program.
Anyway, it is fixed, as is shown below:

class Runnable {
 public:
  template <class Data>
  Runnable(Data& data) requires requires(Data& data) { { data() }; } {
    Implementation<Data> a(data);
    memcpy(*data_*, &a, sizeof(Abstraction));
  }
  Runnable() = default;
  Runnable(Runnable&&) = default;
  Runnable(const Runnable&) = default;
  Runnable& operator=(Runnable&&) = default;
  Runnable& operator=(const Runnable&) = default;

  void operator()() { reinterpret_cast<Abstraction*>(*data_*)->op_0(); }

 private:
  class Abstraction {
   public:
    Abstraction(void* data) : data_(data) {}
    virtual void op_0() = 0;
    template <class T>
    T* get() { return static_cast<T*>(data_); }

   private:
    void* data_;
  };

  template <class Data>
  class Implementation final : public Abstraction {
   public:
    Implementation(Data& data) : Abstraction(&data) {}
    void op_0() override { (*get<Data>())(); }
  };

  char data_[sizeof(Abstraction)];
};

*P.S. How do you think of this implementation that provides
runtime polymorphism support without dynamic memory allocation?*

Thank you!

Mingxin Wang

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f%40isocpp.org.

------=_Part_5433_413441310.1494491532279
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Why woul=
d a compiler generate code for a runtime wrapper for a concept that isn&#39=
;t used as a runtime wrapper at any point in the program?</div><div>If you =
say it&#39;d need to do that to do runtime wrapper inheritance for all the =
base concepts, then this is a particularly flawed approach. (As are many OO=
P hierarchies.)</div></blockquote><div><br></div><div><font face=3D"georgia=
, serif">Unlike concepts which can be treated as boolean constants at runti=
me, proxies are real types. The same as other types, any proxy object has a=
 compile-time-defined data structure which requires a certain scale of memo=
ry to be constructed at runtime.</font></div><div><font face=3D"georgia, se=
rif"><br></font></div><div><font face=3D"georgia, serif">It is possible tha=
t some expressions defined in a concept can be ignored when building a runt=
ime wrapper according to the concept at compile-time, but this is only what=
 we expect from the compiler, and no one can promise that. Besides, since a=
 proxy is a type, the value of a proxy may be passed through compile units =
(definitions and functions maybe defined in different source files), and th=
e compiler may know nothing about how the value is used in other compile un=
its. So there are limitations for compiler optimizations.</font></div><div>=
<font face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, =
serif">By the way, there is a &quot;bug&quot; in the=C2=A0possible implemen=
tation I posted, which is a semantic error, but will not affect the correct=
ness of the program. Anyway, it is fixed, as is shown below:</font></div><d=
iv><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250=
);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><font color=
=3D"#660066"><div class=3D"subprettyprint">class Runnable {</div><div class=
=3D"subprettyprint">=C2=A0public:</div><div class=3D"subprettyprint">=C2=A0=
 template &lt;class Data&gt;</div><div class=3D"subprettyprint">=C2=A0 Runn=
able(Data&amp; data) requires requires(Data&amp; data) { { data() }; } {</d=
iv><div class=3D"subprettyprint">=C2=A0 =C2=A0 Implementation&lt;Data&gt; a=
(data);</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 memcpy(<b>data_</b=
>, &amp;a, sizeof(Abstraction));</div><div class=3D"subprettyprint">=C2=A0 =
}</div><div class=3D"subprettyprint">=C2=A0 Runnable() =3D default;</div><d=
iv class=3D"subprettyprint">=C2=A0 Runnable(Runnable&amp;&amp;) =3D default=
;</div><div class=3D"subprettyprint">=C2=A0 Runnable(const Runnable&amp;) =
=3D default;</div><div class=3D"subprettyprint">=C2=A0 Runnable&amp; operat=
or=3D(Runnable&amp;&amp;) =3D default;</div><div class=3D"subprettyprint">=
=C2=A0 Runnable&amp; operator=3D(const Runnable&amp;) =3D default;</div><di=
v class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">=C2=A0 v=
oid operator()() { reinterpret_cast&lt;Abstraction*&gt;(<b>data_</b>)-&gt;o=
p_0(); }</div><div class=3D"subprettyprint"><br></div><div class=3D"subpret=
typrint">=C2=A0private:</div><div class=3D"subprettyprint">=C2=A0 class Abs=
traction {</div><div class=3D"subprettyprint">=C2=A0 =C2=A0public:</div><di=
v class=3D"subprettyprint">=C2=A0 =C2=A0 Abstraction(void* data) : data_(da=
ta) {}</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 virtual void op_0()=
 =3D 0;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 template &lt;class=
 T&gt;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 T* get() { return s=
tatic_cast&lt;T*&gt;(data_); }</div><div class=3D"subprettyprint"><br></div=
><div class=3D"subprettyprint">=C2=A0 =C2=A0private:</div><div class=3D"sub=
prettyprint">=C2=A0 =C2=A0 void* data_;</div><div class=3D"subprettyprint">=
=C2=A0 };</div><div class=3D"subprettyprint"><br></div><div class=3D"subpre=
ttyprint">=C2=A0 template &lt;class Data&gt;</div><div class=3D"subprettypr=
int">=C2=A0 class Implementation final : public Abstraction {</div><div cla=
ss=3D"subprettyprint">=C2=A0 =C2=A0public:</div><div class=3D"subprettyprin=
t">=C2=A0 =C2=A0 Implementation(Data&amp; data) : Abstraction(&amp;data) {}=
</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 void op_0() override { (*=
get&lt;Data&gt;())(); }</div><div class=3D"subprettyprint">=C2=A0 };</div><=
div class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">=C2=A0=
 char data_[sizeof(Abstraction)];</div><div class=3D"subprettyprint">};</di=
v></font></div></code></div><font face=3D"georgia, serif"><br><b>P.S. How d=
o you think of this implementation that provides runtime=C2=A0polymorphism =
support without=C2=A0dynamic memory allocation?</b></font></div><div><font =
face=3D"georgia, serif"><b><br></b></font></div><div><div><font face=3D"geo=
rgia, serif">Thank you!</font></div><div><font face=3D"georgia, serif"><br>=
</font></div><div><font face=3D"georgia, serif">Mingxin Wang</font></div></=
div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f=
%40isocpp.org</a>.<br />

------=_Part_5433_413441310.1494491532279--

------=_Part_5432_198983327.1494491532278--

.

--001a114027ca25352f054f3b9208
Content-Type: text/plain; charset="UTF-8"

On Thu, May 11, 2017 at 10:32 AM Mingxin Wang <wmx16835vv@163.com> wrote:

> Why would a compiler generate code for a runtime wrapper for a concept
>> that isn't used as a runtime wrapper at any point in the program?
>> If you say it'd need to do that to do runtime wrapper inheritance for all
>> the base concepts, then this is a particularly flawed approach. (As are
>> many OOP hierarchies.)
>>
>
> Unlike concepts which can be treated as boolean constants at runtime,
> proxies are real types. The same as other types, any proxy object has a
> compile-time-defined data structure which requires a certain scale of
> memory to be constructed at runtime.
>
> It is possible that some expressions defined in a concept can be ignored
> when building a runtime wrapper according to the concept at compile-time,
> but this is only what we expect from the compiler, and no one can promise
> that. Besides, since a proxy is a type, the value of a proxy may be passed
> through compile units (definitions and functions maybe defined in different
> source files), and the compiler may know nothing about how the value is
> used in other compile units. So there are limitations for compiler
> optimizations.
>

The person writing the wording for the feature can promise that.


>
> By the way, there is a "bug" in the possible implementation I posted,
> which is a semantic error, but will not affect the correctness of the
> program. Anyway, it is fixed, as is shown below:
>
> class Runnable {
>  public:
>   template <class Data>
>   Runnable(Data& data) requires requires(Data& data) { { data() }; } {
>     Implementation<Data> a(data);
>     memcpy(*data_*, &a, sizeof(Abstraction));
>   }
>   Runnable() = default;
>   Runnable(Runnable&&) = default;
>   Runnable(const Runnable&) = default;
>   Runnable& operator=(Runnable&&) = default;
>   Runnable& operator=(const Runnable&) = default;
>
>   void operator()() { reinterpret_cast<Abstraction*>(*data_*)->op_0(); }
>
>  private:
>   class Abstraction {
>    public:
>     Abstraction(void* data) : data_(data) {}
>     virtual void op_0() = 0;
>     template <class T>
>     T* get() { return static_cast<T*>(data_); }
>
>    private:
>     void* data_;
>   };
>
>   template <class Data>
>   class Implementation final : public Abstraction {
>    public:
>     Implementation(Data& data) : Abstraction(&data) {}
>     void op_0() override { (*get<Data>())(); }
>   };
>
>   char data_[sizeof(Abstraction)];
> };
>
> *P.S. How do you think of this implementation that provides
> runtime polymorphism support without dynamic memory allocation?*
>
> Thank you!
>
> Mingxin Wang
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRZvT5MZsfvo4QhVWYVM_hmUgJuaiUK-MDUv5Y4ZhHgyg%40mail.gmail.com.

--001a114027ca25352f054f3b9208
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu=
, May 11, 2017 at 10:32 AM Mingxin Wang &lt;<a href=3D"mailto:wmx16835vv@16=
3.com">wmx16835vv@163.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Why wou=
ld a compiler generate code for a runtime wrapper for a concept that isn&#3=
9;t used as a runtime wrapper at any point in the program?</div><div>If you=
 say it&#39;d need to do that to do runtime wrapper inheritance for all the=
 base concepts, then this is a particularly flawed approach. (As are many O=
OP hierarchies.)</div></blockquote><div><br></div></div><div dir=3D"ltr"><d=
iv><font face=3D"georgia, serif">Unlike concepts which can be treated as bo=
olean constants at runtime, proxies are real types. The same as other types=
, any proxy object has a compile-time-defined data structure which requires=
 a certain scale of memory to be constructed at runtime.</font></div><div><=
font face=3D"georgia, serif"><br></font></div><div><font face=3D"georgia, s=
erif">It is possible that some expressions defined in a concept can be igno=
red when building a runtime wrapper according to the concept at compile-tim=
e, but this is only what we expect from the compiler, and no one can promis=
e that. Besides, since a proxy is a type, the value of a proxy may be passe=
d through compile units (definitions and functions maybe defined in differe=
nt source files), and the compiler may know nothing about how the value is =
used in other compile units. So there are limitations for compiler optimiza=
tions.</font></div></div></blockquote><div><br></div><div>The person writin=
g the wording for the feature can promise that.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"georgia, seri=
f"><br></font></div><div><font face=3D"georgia, serif">By the way, there is=
 a &quot;bug&quot; in the=C2=A0possible implementation I posted, which is a=
 semantic error, but will not affect the correctness of the program. Anyway=
, it is fixed, as is shown below:</font></div><div><br></div><div><div clas=
s=3D"m_-8122321985422052407prettyprint" style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code class=
=3D"m_-8122321985422052407prettyprint"><div class=3D"m_-8122321985422052407=
subprettyprint"><font color=3D"#660066"></font></div></code></div></div></d=
iv><div dir=3D"ltr"><div><div class=3D"m_-8122321985422052407prettyprint" s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code class=3D"m_-8122321985422052407prettyprint"><d=
iv class=3D"m_-8122321985422052407subprettyprint"><font color=3D"#660066"><=
div class=3D"m_-8122321985422052407subprettyprint">class Runnable {</div><d=
iv class=3D"m_-8122321985422052407subprettyprint">=C2=A0public:</div><div c=
lass=3D"m_-8122321985422052407subprettyprint">=C2=A0 template &lt;class Dat=
a&gt;</div><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 Runna=
ble(Data&amp; data) requires requires(Data&amp; data) { { data() }; } {</di=
v><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 Impleme=
ntation&lt;Data&gt; a(data);</div></font></div></code></div></div></div><di=
v dir=3D"ltr"><div><div class=3D"m_-8122321985422052407prettyprint" style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code class=3D"m_-8122321985422052407prettyprint"><div c=
lass=3D"m_-8122321985422052407subprettyprint"><font color=3D"#660066"><div =
class=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 memcpy(<b>data=
_</b>, &amp;a, sizeof(Abstraction));</div></font></div></code></div></div><=
/div><div dir=3D"ltr"><div><div class=3D"m_-8122321985422052407prettyprint"=
 style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background=
-color:rgb(250,250,250)"><code class=3D"m_-8122321985422052407prettyprint">=
<div class=3D"m_-8122321985422052407subprettyprint"><font color=3D"#660066"=
><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 }</div><div cla=
ss=3D"m_-8122321985422052407subprettyprint">=C2=A0 Runnable() =3D default;<=
/div><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 Runnable(Ru=
nnable&amp;&amp;) =3D default;</div><div class=3D"m_-8122321985422052407sub=
prettyprint">=C2=A0 Runnable(const Runnable&amp;) =3D default;</div><div cl=
ass=3D"m_-8122321985422052407subprettyprint">=C2=A0 Runnable&amp; operator=
=3D(Runnable&amp;&amp;) =3D default;</div><div class=3D"m_-8122321985422052=
407subprettyprint">=C2=A0 Runnable&amp; operator=3D(const Runnable&amp;) =
=3D default;</div><div class=3D"m_-8122321985422052407subprettyprint"><br><=
/div></font></div></code></div></div></div><div dir=3D"ltr"><div><div class=
=3D"m_-8122321985422052407prettyprint" style=3D"border:1px solid rgb(187,18=
7,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code class=
=3D"m_-8122321985422052407prettyprint"><div class=3D"m_-8122321985422052407=
subprettyprint"><font color=3D"#660066"><div class=3D"m_-812232198542205240=
7subprettyprint">=C2=A0 void operator()() { reinterpret_cast&lt;Abstraction=
*&gt;(<b>data_</b>)-&gt;op_0(); }</div></font></div></code></div></div></di=
v><div dir=3D"ltr"><div><div class=3D"m_-8122321985422052407prettyprint" st=
yle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-co=
lor:rgb(250,250,250)"><code class=3D"m_-8122321985422052407prettyprint"><di=
v class=3D"m_-8122321985422052407subprettyprint"><font color=3D"#660066"><d=
iv class=3D"m_-8122321985422052407subprettyprint"><br></div><div class=3D"m=
_-8122321985422052407subprettyprint">=C2=A0private:</div><div class=3D"m_-8=
122321985422052407subprettyprint">=C2=A0 class Abstraction {</div><div clas=
s=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0public:</div><div c=
lass=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 Abstraction(voi=
d* data) : data_(data) {}</div><div class=3D"m_-8122321985422052407subprett=
yprint">=C2=A0 =C2=A0 virtual void op_0() =3D 0;</div><div class=3D"m_-8122=
321985422052407subprettyprint">=C2=A0 =C2=A0 template &lt;class T&gt;</div>=
<div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 T* get() =
{ return static_cast&lt;T*&gt;(data_); }</div><div class=3D"m_-812232198542=
2052407subprettyprint"><br></div><div class=3D"m_-8122321985422052407subpre=
ttyprint">=C2=A0 =C2=A0private:</div><div class=3D"m_-8122321985422052407su=
bprettyprint">=C2=A0 =C2=A0 void* data_;</div><div class=3D"m_-812232198542=
2052407subprettyprint">=C2=A0 };</div><div class=3D"m_-8122321985422052407s=
ubprettyprint"><br></div><div class=3D"m_-8122321985422052407subprettyprint=
">=C2=A0 template &lt;class Data&gt;</div><div class=3D"m_-8122321985422052=
407subprettyprint">=C2=A0 class Implementation final : public Abstraction {=
</div><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0publ=
ic:</div><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 =
Implementation(Data&amp; data) : Abstraction(&amp;data) {}</div><div class=
=3D"m_-8122321985422052407subprettyprint">=C2=A0 =C2=A0 void op_0() overrid=
e { (*get&lt;Data&gt;())(); }</div><div class=3D"m_-8122321985422052407subp=
rettyprint">=C2=A0 };</div><div class=3D"m_-8122321985422052407subprettypri=
nt"><br></div><div class=3D"m_-8122321985422052407subprettyprint">=C2=A0 ch=
ar data_[sizeof(Abstraction)];</div><div class=3D"m_-8122321985422052407sub=
prettyprint">};</div></font></div></code></div></div></div><div dir=3D"ltr"=
><div><div class=3D"m_-8122321985422052407prettyprint" style=3D"border:1px =
solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,25=
0)"><code class=3D"m_-8122321985422052407prettyprint"><div class=3D"m_-8122=
321985422052407subprettyprint"><font color=3D"#660066"></font></div></code>=
</div><font face=3D"georgia, serif"><br><b>P.S. How do you think of this im=
plementation that provides runtime=C2=A0polymorphism support without=C2=A0d=
ynamic memory allocation?</b></font></div><div><font face=3D"georgia, serif=
"><b><br></b></font></div><div><div><font face=3D"georgia, serif">Thank you=
!</font></div><div><font face=3D"georgia, serif"><br></font></div><div><fon=
t face=3D"georgia, serif">Mingxin Wang</font></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-4f85-8e20-6e89a30d708f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2251d51a-005e-=
4f85-8e20-6e89a30d708f%40isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRZvT5MZsfvo4QhVWYVM_hmUgJuaiUK=
-MDUv5Y4ZhHgyg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRZvT5MZsfv=
o4QhVWYVM_hmUgJuaiUK-MDUv5Y4ZhHgyg%40mail.gmail.com</a>.<br />

--001a114027ca25352f054f3b9208--

.

------=_Part_7657_1576210530.1494583193162
Content-Type: multipart/alternative;
 boundary="----=_Part_7658_1068948436.1494583193163"

------=_Part_7658_1068948436.1494583193163
Content-Type: text/plain; charset="UTF-8"

I'll write here in the behalf of hopefully most people.

Apparently, runtime polymorphism is considered to have benefits for the
language, given it can be implemented and specified properly.
By that I mean, that a potential Proposal needs to adress the following
concerns:

   1. Overhead w.r.t code size
   2. Overhead w.r.t compile time
   3. In what way can and should predefined Concepts be reused to generate
   abstract classes that forward functionality to concrete types? (possibly
   not at all?)
   4. Ensure Type safety across all compilation units
   5. Ensure proper ownership management
   6. Should "Static" concepts behave like "dynamic" ones only in that they
   operate at compile time? Why is a different approach preferable?

If anyone wants to write a proposal, they are invited to do so.
In case I missed something really important, feel free to add stuff.
Remember: This list is not about personal design preferences, but about
criteria to be discussed.

Have a nice Weekend,
Jakob

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/03f03fa0-aa65-4abf-832e-abbeba5466a8%40isocpp.org.

------=_Part_7658_1068948436.1494583193163
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll write here in the behalf of hopefully most people=
..<div><br></div><div>Apparently, runtime polymorphism is considered to have=
 benefits for the language, given it can be implemented and specified prope=
rly.</div><div>By that I mean, that a potential Proposal needs to adress th=
e following concerns:</div><div><ol><li>Overhead w.r.t code size</li><li>Ov=
erhead w.r.t compile time</li><li>In what way can and should predefined Con=
cepts be reused to generate abstract classes that forward functionality to =
concrete types? (possibly not at all?)</li><li>Ensure Type safety across al=
l compilation units</li><li>Ensure proper ownership management</li><li>Shou=
ld &quot;Static&quot; concepts behave like &quot;dynamic&quot; ones only in=
 that they operate at compile time? Why is a different approach preferable?=
</li></ol>If anyone wants to write a proposal, they are invited to do so.</=
div><div>In case I missed something really important, feel free to add stuf=
f.</div><div>Remember: This list is not about personal design preferences, =
but about criteria to be discussed.</div><div><br></div><div>Have a nice We=
ekend,</div><div>Jakob</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/03f03fa0-aa65-4abf-832e-abbeba5466a8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/03f03fa0-aa65-4abf-832e-abbeba5466a8=
%40isocpp.org</a>.<br />

------=_Part_7658_1068948436.1494583193163--

------=_Part_7657_1576210530.1494583193162--

.

------=_Part_6468_1101125992.1494600588560
Content-Type: multipart/alternative;
 boundary="----=_Part_6469_140614462.1494600588560"

------=_Part_6469_140614462.1494600588560
Content-Type: text/plain; charset="UTF-8"



On Friday, May 12, 2017 at 5:59:53 AM UTC-4, Jakob Riedle wrote:
>
> I'll write here in the behalf of hopefully most people.
>
> Apparently, runtime polymorphism is considered to have benefits for the
> language, given it can be implemented and specified properly.
> By that I mean, that a potential Proposal needs to adress the following
> concerns:
>
>    1. Overhead w.r.t code size
>    2. Overhead w.r.t compile time
>    3. In what way can and should predefined Concepts be reused to
>    generate abstract classes that forward functionality to concrete types?
>    (possibly not at all?)
>    4. Ensure Type safety across all compilation units
>    5. Ensure proper ownership management
>    6. Should "Static" concepts behave like "dynamic" ones only in that
>    they operate at compile time? Why is a different approach preferable?
>
> *1:* Code size should be about what you would expect from any form of
type erasing system like `any` or `function`. The code size increase will
be based on two factors:

A) The number of operations that the "abstract class" exposes.
B) The number of types that get erased.

*2:* As we move closer to getting modules, I think this becomes less
relevant. In a modularized codebase, whatever the code generation will be,
it will generally only happen once (or perhaps a few times). So even if it
is somewhat expensive (and I don't think it will be), modules can make it
cheap.

*3:* The expressiveness of concepts (particularly through arbitrary code
execution) means that it is impossible to guarantee that a type-erased
class can exactly match the functionality of a concept.

But at the same time, the ability to convert a concept into a type-erased
type would be exceedingly useful. But as previously stated, it's not
possible to do this in general due to the complexities of concept
definitions. So if we're going to use concepts as the basis for this, we
need a way for users to know which concept constructs will be converted and
which will not.

For example, can we convert a requires statement like this:

{adl_func(val) + int()} -> int;

Into some kind of type-erased forwarding code? Because that's two separate
operations that need to be wrapped: the call to `adl_func` and the
`operator+` between the return value of that and `int()`. The problem here
is that the return type of `adl_func` is not known, since it depends on
`type`. But the wrapper functions have to be static; they can't be
generated at the time we apply the type to the type-erased function. So
it's not clear how that could work.

It may be that the complexity of such conversions is too great, and the
only effective solution would be to provide an alternative system for
specifying which operations are converted and how those conversions work.

*4:* I don't see how that's a problem. What we're talking about is having
the compiler generate a type with certain properties and functions. It
should have a well-defined typename, and it should follow the
one-definition-rule. So if we generate this type from a concept, then the
ODR would apply: if you use a different concept with the same typename in
different translation units, you violate the ODR.

*5:* Yes, that's important. We need to be able to specify at least the
following kinds of behavior with respect to the type-erased object:
reference semantics, value semantics but with only move support, and value
semantics but with copy support.

*6:* Even if we go with a concepts-based approach to the code generation,
you should not use a concept *directly* when you actually mean to use the
type-erased type. They ought to have different names, so it is immediately
clear to everyone when you're using a concept and when you're using a
type-erased type.

After all, there's no way to achieve #5 if you make it some kind of
contextual thing, where a concept can refer to a typename in some cases and
a concept in others. In order for the user to specify ownership behavior,
there has to be some form of explicit declaration of that intent. And two
separate users of the same concept ought to be able to specify different
ownership behavior. And that requires each user to use a distinct name for
the combination of concept+behavior.

And that doesn't cover the ambiguities created by trying to make a concept
name also be a typename. The use as a function argument, for example: how
do you tell if the user wants it to be a template function or a regular
function? Or the use as a placeholder type:

ConceptName var = expr;

Should `decltype(var)` be `ConceptName`, or should it be `decltype(expr)`?

This ambiguity doesn't exist if we give the type-erased version a specific
name that is distinct from the concept name.

Oh sure, you could probably come up with a keyword or operator that, when
coupled with a concept name will resolve the ambiguity. But using an actual
typename for the type-erased type makes things so much simpler.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a1f06dc9-6455-4c05-8673-5812d141f0e3%40isocpp.org.

------=_Part_6469_140614462.1494600588560
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, May 12, 2017 at 5:59:53 AM UTC-4, Jakob=
 Riedle wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>I&#39;ll write here in the behalf of hopefully most people.<div><br></div>=
<div>Apparently, runtime polymorphism is considered to have benefits for th=
e language, given it can be implemented and specified properly.</div><div>B=
y that I mean, that a potential Proposal needs to adress the following conc=
erns:</div><div><ol><li>Overhead w.r.t code size</li><li>Overhead w.r.t com=
pile time</li><li>In what way can and should predefined Concepts be reused =
to generate abstract classes that forward functionality to concrete types? =
(possibly not at all?)</li><li>Ensure Type safety across all compilation un=
its</li><li>Ensure proper ownership management</li><li>Should &quot;Static&=
quot; concepts behave like &quot;dynamic&quot; ones only in that they opera=
te at compile time? Why is a different approach preferable?</li></ol></div>=
</div></blockquote><div><b>1:</b> Code size should be about what you would =
expect from any form of type erasing system like `any` or `function`. The c=
ode size increase will be based on two factors:<br><br>A) The number of ope=
rations that the &quot;abstract class&quot; exposes.<br>B) The number of ty=
pes that get erased.<br><br><b>2:</b> As we move closer to getting modules,=
 I think this becomes less relevant. In a modularized codebase, whatever th=
e code generation will be, it will generally only happen once (or perhaps a=
 few times). So even if it is somewhat expensive (and I don&#39;t think it =
will be), modules can make it cheap.<br><br><b>3:</b> The expressiveness of=
 concepts (particularly through arbitrary code execution) means that it is =
impossible to guarantee that a type-erased class can exactly match the func=
tionality of a concept.<br><br>But at the same time, the ability to convert=
 a concept into a type-erased type would be exceedingly useful. But as prev=
iously stated, it&#39;s not possible to do this in general due to the compl=
exities of concept definitions. So if we&#39;re going to use concepts as th=
e basis for this, we need a way for users to know which concept constructs =
will be converted and which will not.<br><br>For example, can we convert a =
requires statement like this:<br><br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">adl_func</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">val</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">()}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div><br>Into some kind of type-erased forwarding code? Becau=
se that&#39;s two separate operations that need to be wrapped: the call to =
`adl_func` and the `operator+` between the return value of that and `int()`=
.. The problem here is that the return type of `adl_func` is not known, sinc=
e it depends on `type`. But the wrapper functions have to be static; they c=
an&#39;t be generated at the time we apply the type to the type-erased func=
tion. So it&#39;s not clear how that could work.<br><br>It may be that the =
complexity of such conversions is too great, and the only effective solutio=
n would be to provide an alternative system for specifying which operations=
 are converted and how those conversions work.<br><br><b>4:</b> I don&#39;t=
 see how that&#39;s a problem. What we&#39;re talking about is having the c=
ompiler generate a type with certain properties and functions. It should ha=
ve a well-defined typename, and it should follow the one-definition-rule. S=
o if we generate this type from a concept, then the ODR would apply: if you=
 use a different concept with the same typename in different translation un=
its, you violate the ODR.<br><br><b>5:</b> Yes, that&#39;s important. We ne=
ed to be able to specify at least the following kinds of behavior with resp=
ect to the type-erased object: reference semantics, value semantics but wit=
h only move support, and value semantics but with copy support.<br><br><b>6=
:</b> Even if we go with a concepts-based approach to the code generation, =
you should not use a concept <i>directly</i> when you actually mean to use =
the type-erased type. They ought to have different names, so it is immediat=
ely clear to everyone when you&#39;re using a concept and when you&#39;re u=
sing a type-erased type.<br><br>After all, there&#39;s no way to achieve #5=
 if you make it some kind of contextual thing, where a concept can refer to=
 a typename in some cases and a concept in others. In order for the user to=
 specify ownership behavior, there has to be some form of explicit declarat=
ion of that intent. And two separate users of the same concept ought to be =
able to specify different ownership behavior. And that requires each user t=
o use a distinct name for the combination of concept+behavior.<br><br>And t=
hat doesn&#39;t cover the ambiguities created by trying to make a concept n=
ame also be a typename. The use as a function argument, for example: how do=
 you tell if the user wants it to be a template function or a regular funct=
ion? Or the use as a placeholder type:<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #606;" class=3D"styled-by-prettify">ConceptName</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">var</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> expr</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><br>Should `decltype(var)` be `ConceptName`, or sho=
uld it be `decltype(expr)`?<br><br>This ambiguity doesn&#39;t exist if we g=
ive the type-erased version a specific name that is distinct from the conce=
pt name.<br><br>Oh sure, you could probably come up with a keyword or opera=
tor that, when coupled with a concept name will resolve the ambiguity. But =
using an actual typename for the type-erased type makes things so much simp=
ler.<br></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1f06dc9-6455-4c05-8673-5812d141f0e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1f06dc9-6455-4c05-8673-5812d141f0e3=
%40isocpp.org</a>.<br />

------=_Part_6469_140614462.1494600588560--

------=_Part_6468_1101125992.1494600588560--

.

--001a1143c4c8fe2578054f551425
Content-Type: text/plain; charset="UTF-8"

On Fri, May 12, 2017 at 10:49 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> In a modularized codebase, whatever the code generation will be, it will
> generally only happen once (or perhaps a few times).
>

Really?  Why?  Modules control visibility of names, AFAIK.  How do they
affect code generation?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYasjNipjjRZwLe%3DV-djuPpaK4wCx4kO6aXO_iigfNPPg%40mail.gmail.com.

--001a1143c4c8fe2578054f551425
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 12, 2017 at 10:49 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In a modul=
arized codebase, whatever the code generation will be, it will generally on=
ly happen once (or perhaps a few times).</div></div></blockquote><div><br>R=
eally?=C2=A0 Why?=C2=A0 Modules control visibility of names, AFAIK.=C2=A0 H=
ow do they affect code generation?</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYasjNipjjRZwLe%3DV-djuPpaK4wCx=
4kO6aXO_iigfNPPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdYasjNipj=
jRZwLe%3DV-djuPpaK4wCx4kO6aXO_iigfNPPg%40mail.gmail.com</a>.<br />

--001a1143c4c8fe2578054f551425--

.

------=_Part_5380_999111281.1494602186942
Content-Type: multipart/alternative;
 boundary="----=_Part_5381_1881004683.1494602186942"

------=_Part_5381_1881004683.1494602186942
Content-Type: text/plain; charset="UTF-8"

On Friday, May 12, 2017 at 11:08:48 AM UTC-4, Hyman Rosen wrote:
>
> On Fri, May 12, 2017 at 10:49 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>>
>> In a modularized codebase, whatever the code generation will be, it will
>> generally only happen once (or perhaps a few times).
>>
>
> Really?  Why?  Modules control visibility of names, AFAIK.  How do they
> affect code generation?
>

A module functionally represents an AST. If a module exports a type-erased
type, then it is effectively exporting the AST for that type-erased type.
Which means that it must export the code generated by the system that
generated that type-erased type. And therefore, any code generation needed
for that AST must have been performed. Therefore, users that include that
module don't need to perform code generation for it.

It's no different from exporting a virtual base class in that regard. The
module will export whatever is needed to make that type function: the
definitions of any virtual functions, the vtable arrangement, and so forth.
If you import a module containing a virtual base class, you shouldn't
expect the compiler to re-compile those virtual function definitions or
build a vtable for the type or other such things.

This kind of thing is *the whole point* of modules.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4189326d-92bf-4cbc-8518-a9209a889dda%40isocpp.org.

------=_Part_5381_1881004683.1494602186942
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 12, 2017 at 11:08:48 AM UTC-4, Hyman Rosen =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Fri, May 12, 2017 at 10:49 AM, Nicol Bolas <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"X7MUNkGvCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">jmck...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>In a modularized codebase, whatever the code =
generation will be, it will generally only happen once (or perhaps a few ti=
mes).</div></div></blockquote><div><br>Really?=C2=A0 Why?=C2=A0 Modules con=
trol visibility of names, AFAIK.=C2=A0 How do they affect code generation?<=
/div></div></div></div></blockquote><div><br>A module functionally represen=
ts an AST. If a module exports a type-erased type, then it is effectively e=
xporting the AST for that type-erased type. Which means that it must export=
 the code generated by the system that generated that type-erased type. And=
 therefore, any code generation needed for that AST must have been performe=
d. Therefore, users that include that module don&#39;t need to perform code=
 generation for it.<br><br>It&#39;s no different from exporting a virtual b=
ase class in that regard. The module will export whatever is needed to make=
 that type function: the definitions of any virtual functions, the vtable a=
rrangement, and so forth. If you import a module containing a virtual base =
class, you shouldn&#39;t expect the compiler to re-compile those virtual fu=
nction definitions or build a vtable for the type or other such things.<br>=
<br>This kind of thing is <i>the whole point</i> of modules.<br></div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4189326d-92bf-4cbc-8518-a9209a889dda%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4189326d-92bf-4cbc-8518-a9209a889dda=
%40isocpp.org</a>.<br />

------=_Part_5381_1881004683.1494602186942--

------=_Part_5380_999111281.1494602186942--

.

--001a113e71ec48ffa6054f55e13a
Content-Type: text/plain; charset="UTF-8"

On Fri, May 12, 2017 at 11:16 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> A module functionally represents an AST. If a module exports a type-erased
> type, then it is effectively exporting the AST for that type-erased type.
> Which means that it must export the code generated by the system that
> generated that type-erased type. And therefore, any code generation needed
> for that AST must have been performed. Therefore, users that include that
> module don't need to perform code generation for it.
>

But modules can export templates, can't they?  The *Runnable* class above
has them.  Users that include the module containing that class will still
need to generate code for the specializations they instantiate.  Am I
missing something?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbbP%3DqVkfeXiYXqOhAqQxqKtHmv80G%3Dsrk-gre0RTHTEQ%40mail.gmail.com.

--001a113e71ec48ffa6054f55e13a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 12, 2017 at 11:16 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A modu=
le functionally represents an AST. If a module exports a type-erased type, =
then it is effectively exporting the AST for that type-erased type. Which m=
eans that it must export the code generated by the system that generated th=
at type-erased type. And therefore, any code generation needed for that AST=
 must have been performed. Therefore, users that include that module don&#3=
9;t need to perform code generation for it.</div></div></blockquote><div><b=
r>But modules can export templates, can&#39;t they?=C2=A0 The <font face=3D=
"monospace, monospace"><b>Runnable</b></font> class above has them.=C2=A0 U=
sers that include the module containing that class will still need to gener=
ate code for the specializations they instantiate.=C2=A0 Am I missing somet=
hing?</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbbP%3DqVkfeXiYXqOhAqQxqKtHmv80=
G%3Dsrk-gre0RTHTEQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbbP%3D=
qVkfeXiYXqOhAqQxqKtHmv80G%3Dsrk-gre0RTHTEQ%40mail.gmail.com</a>.<br />

--001a113e71ec48ffa6054f55e13a--

.

------=_Part_16_869669820.1494613256286
Content-Type: multipart/alternative;
 boundary="----=_Part_17_1476286277.1494613256286"

------=_Part_17_1476286277.1494613256286
Content-Type: text/plain; charset="UTF-8"



On Friday, May 12, 2017 at 6:05:56 PM UTC+2, Hyman Rosen wrote:
>
> On Fri, May 12, 2017 at 11:16 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> A module functionally represents an AST. If a module exports a
>> type-erased type, then it is effectively exporting the AST for that
>> type-erased type. Which means that it must export the code generated by the
>> system that generated that type-erased type. And therefore, any code
>> generation needed for that AST must have been performed. Therefore, users
>> that include that module don't need to perform code generation for it.
>>
>
> But modules can export templates, can't they?  The *Runnable* class above
> has them.  Users that include the module containing that class will still
> need to generate code for the specializations they instantiate.  Am I
> missing something?
>

Yes, but this will happen only once for each unique module that use that
template not for all translation units like today. More modular code will
be then less repetition work will be done.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/65947dca-3a28-4190-b6c0-e44d529a0807%40isocpp.org.

------=_Part_17_1476286277.1494613256286
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, May 12, 2017 at 6:05:56 PM UTC+2, Hyman=
 Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Fri, May 12, 2017 at 11:16 AM, Nicol Bol=
as <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"rAdJLl-yCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div>A module functionally represents a=
n AST. If a module exports a type-erased type, then it is effectively expor=
ting the AST for that type-erased type. Which means that it must export the=
 code generated by the system that generated that type-erased type. And the=
refore, any code generation needed for that AST must have been performed. T=
herefore, users that include that module don&#39;t need to perform code gen=
eration for it.</div></div></blockquote><div><br>But modules can export tem=
plates, can&#39;t they?=C2=A0 The <font face=3D"monospace, monospace"><b>Ru=
nnable</b></font> class above has them.=C2=A0 Users that include the module=
 containing that class will still need to generate code for the specializat=
ions they instantiate.=C2=A0 Am I missing something?</div></div></div></div=
></blockquote><div><br>Yes, but this will happen only once for each unique =
module that use that template not for all translation units like today. Mor=
e modular code will be then less repetition work will be done.<br></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/65947dca-3a28-4190-b6c0-e44d529a0807%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/65947dca-3a28-4190-b6c0-e44d529a0807=
%40isocpp.org</a>.<br />

------=_Part_17_1476286277.1494613256286--

------=_Part_16_869669820.1494613256286--

.

--001a1149d30022383f054f57db3f
Content-Type: text/plain; charset="UTF-8"

On Fri, May 12, 2017 at 2:20 PM, <inkwizytoryankes@gmail.com> wrote:
>
> On Friday, May 12, 2017 at 6:05:56 PM UTC+2, Hyman Rosen wrote:
>>
>> But modules can export templates, can't they?  The *Runnable* class
>> above has them.  Users that include the module containing that class will
>> still need to generate code for the specializations they instantiate.  Am I
>> missing something?
>>
> Yes, but this will happen only once for each unique module that use that
> template not for all translation units like today. More modular code will
> be then less repetition work will be done.
>

This sounds like you're assuming that one module will consist of many
translation units, and that somehow compiling those many translation units
won't require that each one have the template code generated into it.  What
is the basis for believing that?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaaovNHmvucbW%3Dbd9Hd8UihjkCNdsPjZ4MLAH-CdoLEcw%40mail.gmail.com.

--001a1149d30022383f054f57db3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 12, 2017 at 2:20 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, Ma=
y 12, 2017 at 6:05:56 PM UTC+2, Hyman Rosen wrote:<span class=3D""><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><div>But modules can export templates, can&#39;t they?=C2=A0 The <fon=
t face=3D"monospace, monospace"><b>Runnable</b></font> class above has them=
..=C2=A0 Users that include the module containing that class will still need=
 to generate code for the specializations they instantiate.=C2=A0 Am I miss=
ing something?</div></div></div></div></blockquote></span><div>Yes, but thi=
s will happen only once for each unique module that use that template not f=
or all translation units like today. More modular code will be then less re=
petition work will be done.</div></div></blockquote><div><br>This sounds li=
ke you&#39;re assuming that one module will consist of many translation uni=
ts, and that somehow compiling those many translation units won&#39;t requi=
re that each one have the template code generated into it.=C2=A0 What is th=
e basis for believing that?<br>=C2=A0</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaaovNHmvucbW%3Dbd9Hd8UihjkCNds=
PjZ4MLAH-CdoLEcw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdaaovNHmv=
ucbW%3Dbd9Hd8UihjkCNdsPjZ4MLAH-CdoLEcw%40mail.gmail.com</a>.<br />

--001a1149d30022383f054f57db3f--

.

------=_Part_33_808175492.1494614515365
Content-Type: multipart/alternative;
 boundary="----=_Part_34_1673952459.1494614515365"

------=_Part_34_1673952459.1494614515365
Content-Type: text/plain; charset="UTF-8"



On Friday, May 12, 2017 at 8:27:22 PM UTC+2, Hyman Rosen wrote:
>
> On Fri, May 12, 2017 at 2:20 PM, <inkwizyt...@gmail.com <javascript:>>
> wrote:
>>
>> On Friday, May 12, 2017 at 6:05:56 PM UTC+2, Hyman Rosen wrote:
>>>
>>> But modules can export templates, can't they?  The *Runnable* class
>>> above has them.  Users that include the module containing that class will
>>> still need to generate code for the specializations they instantiate.  Am I
>>> missing something?
>>>
>> Yes, but this will happen only once for each unique module that use that
>> template not for all translation units like today. More modular code will
>> be then less repetition work will be done.
>>
>
> This sounds like you're assuming that one module will consist of many
> translation units, and that somehow compiling those many translation units
> won't require that each one have the template code generated into it.  What
> is the basis for believing that?
>
>

Look on current code bases, all code in .h file can be changed to modules.
This mean all instantiation of templates that currently was done in headers
will be done only once. Instantiation in .cpp will be repeated for each
separate file. Even if module need multiple translation units to compile
itself then we will only pay for them not for all translation units that
use that module. You could even crate small auxiliary modules that will
instantiation one class that will be used in other modules.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ef10cf93-0dd8-457c-b74e-e891647b031a%40isocpp.org.

------=_Part_34_1673952459.1494614515365
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, May 12, 2017 at 8:27:22 PM UTC+2, Hyman=
 Rosen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Fri, May 12, 2017 at 2:20 PM,  <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"Rp0OABe6CQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">inkwizyt...@gmail.com</a>&gt;</span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">On Friday, May 12, 2017 at 6:05:56 PM UTC+2, Hyman =
Rosen wrote:<span><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>But modules can export templates, can&=
#39;t they?=C2=A0 The <font face=3D"monospace, monospace"><b>Runnable</b></=
font> class above has them.=C2=A0 Users that include the module containing =
that class will still need to generate code for the specializations they in=
stantiate.=C2=A0 Am I missing something?</div></div></div></div></blockquot=
e></span><div>Yes, but this will happen only once for each unique module th=
at use that template not for all translation units like today. More modular=
 code will be then less repetition work will be done.</div></div></blockquo=
te><div><br>This sounds like you&#39;re assuming that one module will consi=
st of many translation units, and that somehow compiling those many transla=
tion units won&#39;t require that each one have the template code generated=
 into it.=C2=A0 What is the basis for believing that?<br>=C2=A0</div></div>=
</div></div></blockquote><div>=C2=A0<br>Look on current code bases, all cod=
e in .h file can be changed to modules. This mean all instantiation of temp=
lates that currently was done in headers will be done only once. Instantiat=
ion in .cpp will be repeated for each separate file. Even if module need mu=
ltiple translation units to compile itself then we will only pay for them n=
ot for all translation units that use that module. You could even crate sma=
ll auxiliary modules that will instantiation one class that will be used in=
 other modules.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ef10cf93-0dd8-457c-b74e-e891647b031a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef10cf93-0dd8-457c-b74e-e891647b031a=
%40isocpp.org</a>.<br />

------=_Part_34_1673952459.1494614515365--

------=_Part_33_808175492.1494614515365--

.

--001a113521460c86fb054f589a6c
Content-Type: text/plain; charset="UTF-8"

On Fri, May 12, 2017 at 2:41 PM, <inkwizytoryankes@gmail.com> wrote:
>
> Look on current code bases, all code in .h file can be changed to modules.
> This mean all instantiation of templates that currently was done in headers
> will be done only once. Instantiation in .cpp will be repeated for each
> separate file. Even if module need multiple translation units to compile
> itself then we will only pay for them not for all translation units that
> use that module. You could even crate small auxiliary modules that will
> instantiation one class that will be used in other modules.
>

Well, maybe.  Except that compiler customers also want aggressive inlining
to happen, so there may be less benefit than you expect.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbw%2ByiYMAh-HHs1Epat4kdkgy0Pwq0%2BvEe0%3D2yd_yB13Q%40mail.gmail.com.

--001a113521460c86fb054f589a6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 12, 2017 at 2:41 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:inkwi=
zytoryankes@gmail.com" target=3D"_blank">inkwizytoryankes@gmail.com</a>&gt;=
</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Look on =
current code bases, all code in .h file can be changed to modules. This mea=
n all instantiation of templates that currently was done in headers will be=
 done only once. Instantiation in .cpp will be repeated for each separate f=
ile. Even if module need multiple translation units to compile itself then =
we will only pay for them not for all translation units that use that modul=
e. You could even crate small auxiliary modules that will instantiation one=
 class that will be used in other modules.</div></div></blockquote><div><br=
>Well, maybe.=C2=A0 Except that compiler customers also want aggressive inl=
ining to happen, so there may be less benefit than you expect.<br></div></d=
iv></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbw%2ByiYMAh-HHs1Epat4kdkgy0Pwq=
0%2BvEe0%3D2yd_yB13Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdbw%2=
ByiYMAh-HHs1Epat4kdkgy0Pwq0%2BvEe0%3D2yd_yB13Q%40mail.gmail.com</a>.<br />

--001a113521460c86fb054f589a6c--

.

On 12 May 2017 at 22:20, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> On Fri, May 12, 2017 at 2:41 PM, <inkwizytoryankes@gmail.com> wrote:
>>
>> Look on current code bases, all code in .h file can be changed to modules.
>> This mean all instantiation of templates that currently was done in headers
>> will be done only once. Instantiation in .cpp will be repeated for each
>> separate file. Even if module need multiple translation units to compile
>> itself then we will only pay for them not for all translation units that use
>> that module. You could even crate small auxiliary modules that will
>> instantiation one class that will be used in other modules.
>
>
> Well, maybe.  Except that compiler customers also want aggressive inlining
> to happen, so there may be less benefit than you expect.


Still, all the parsing and first-phase lookup has already been done,
without preventing inlining
in any way. You are correct in the sense that there may be less
benefit than some expect, since
overload resolution etc. will still happen at the point of use.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb8%3Deab9pMcmOp6aT2B2O6RUn0qs4GzYSGG1-n0PfhK2Q%40mail.gmail.com.

.