Topic: Simplifying simple CRTP usages
Author: Michael Price - Dev <michael.b.price.dev@gmail.com>
Date: Wed, 4 Sep 2013 10:15:23 -0700 (PDT)
Raw View
------=_Part_655_31285928.1378314923416
Content-Type: text/plain; charset=ISO-8859-1
As useful as the CRTP is, it can be awfully intimidating/confusing for
people not familiar with it. I'm looking for opinions on the following
idea.
Allow compile-time interface enforcement via a simpler, more "normal"
inheritance syntax (the simplest use cases of the CRTP).
Example:
// C++11 "simple" compile-time interface
template <typename T>
struct interface
{
void fn() { return static_cast<T*>(this)->fn_impl(); }
};
struct thing : interface<thing>
{
void fn_impl() { /* ... */ }
};
thing t;
t.fn();
// Proposed "simpler" compile-time interface
// Restrictions on a static interface
// 1) No data members
// 2) Public methods only
// 3) No type dependency on derived type
// 4) Declarations only, no method implementations
// 5) Any others???
//
// If any of those restrictions are not acceptable, resort to CRTP
struct interface
{
void fn();
};
struct thing : [keyword_goes_here] interface
{
void fn() { /* ... */ }
};
thing t;
t.fn();
Of course, the actual keyword to plug in there to indicate compile-time
interface inheritance could be anything. Candidates I could think of were:
static
const
constexpr
There would be no virtual table introduced, only compile-time checking that
the interface is met. I'm not sure if final/override would apply in these
cases. Thoughts?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_655_31285928.1378314923416
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As useful as the CRTP is, it can be awfully intimidating/c=
onfusing for people not familiar with it. I'm looking for opinions on=
the following idea.<div><br></div><div>Allow compile-time interface enforc=
ement via a simpler, more "normal" inheritance syntax (the simplest use cas=
es of the CRTP).</div><div><br></div><div>Example:</div><div><br></div><div=
><font face=3D"courier new, monospace">// C++11 "simple" compile-time inter=
face</font></div><div><font face=3D"courier new, monospace"><br></font></di=
v><div><font face=3D"courier new, monospace">template <typename T></f=
ont></div><div><font face=3D"courier new, monospace">struct interface</font=
></div><div><font face=3D"courier new, monospace">{</font></div><div><font =
face=3D"courier new, monospace"> void fn() { return static_cas=
t<T*>(this)->fn_impl(); }</font></div><div><font face=3D"courier n=
ew, monospace">};</font></div><div><font face=3D"courier new, monospace"><b=
r></font></div><div><font face=3D"courier new, monospace">struct thing : in=
terface<thing></font></div><div><font face=3D"courier new, monospace"=
>{</font></div><div><font face=3D"courier new, monospace"> voi=
d fn_impl() { /* ... */ }</font></div><div><font face=3D"courier new, monos=
pace">};</font></div><div><font face=3D"courier new, monospace"><br></font>=
</div><div><font face=3D"courier new, monospace">thing t;</font></div><div>=
<font face=3D"courier new, monospace">t.fn();</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace"><br></font></div><div><div><font face=3D"courier new, monospac=
e">// Proposed "simpler" compile-time interface</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">// Restrictions on a static interface</font></div><div><font f=
ace=3D"courier new, monospace">// 1) No data members</font></div><div=
><font face=3D"courier new, monospace">// 2) Public methods only</fon=
t></div><div><font face=3D"courier new, monospace">// 3) No type depe=
ndency on derived type</font></div><div><font face=3D"courier new, monospac=
e">// 4) Declarations only, no method implementations</font></div><di=
v><font face=3D"courier new, monospace">// 5) Any others???</font></d=
iv><div><font face=3D"courier new, monospace">//</font></div><div><font fac=
e=3D"courier new, monospace">// If any of those restrictions are not =
acceptable, resort to CRTP</font></div><div><font face=3D"courier new, mono=
space"><br></font></div><div><font face=3D"courier new, monospace">struct i=
nterface<br></font></div><div><font face=3D"courier new, monospace">{</font=
></div><div><font face=3D"courier new, monospace"> void fn();<=
/font></div><div><font face=3D"courier new, monospace">};</font></div><div>=
<font face=3D"courier new, monospace"><br></font></div><div><font face=3D"c=
ourier new, monospace">struct thing : [keyword_goes_here] interface</font><=
/div><div><font face=3D"courier new, monospace">{</font></div><div><font fa=
ce=3D"courier new, monospace"> void fn() { /* ... */ }</font><=
/div><div><font face=3D"courier new, monospace">};</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">thing t;</font></div><div><font face=3D"courier new, monosp=
ace">t.fn();</font></div></div><div><br></div><div><br></div><div>Of course=
, the actual keyword to plug in there to indicate compile-time interface in=
heritance could be anything. Candidates I could think of were:</div><=
div><font face=3D"courier new, monospace">static</font></div><div><font fac=
e=3D"courier new, monospace">const</font></div><div><font face=3D"courier n=
ew, monospace">constexpr</font></div><div><br></div><div>There would be no =
virtual table introduced, only compile-time checking that the interface is =
met. I'm not sure if final/override would apply in these cases. Thoug=
hts?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_655_31285928.1378314923416--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 11:09:53 -0700 (PDT)
Raw View
------=_Part_1753_4958257.1378318193242
Content-Type: text/plain; charset=ISO-8859-1
I'd vote for static.
Can you please give an example that truly exercises the construct? Yours
works all the same with
struct thing
{
void fn() { /* ... */ }
};
thing t;
t.fn();
On Wednesday, September 4, 2013 7:15:23 PM UTC+2, Michael Price - Dev wrote:
>
> As useful as the CRTP is, it can be awfully intimidating/confusing for
> people not familiar with it. I'm looking for opinions on the following
> idea.
>
> Allow compile-time interface enforcement via a simpler, more "normal"
> inheritance syntax (the simplest use cases of the CRTP).
>
> Example:
>
> // C++11 "simple" compile-time interface
>
> template <typename T>
> struct interface
> {
> void fn() { return static_cast<T*>(this)->fn_impl(); }
> };
>
> struct thing : interface<thing>
> {
> void fn_impl() { /* ... */ }
> };
>
> thing t;
> t.fn();
>
>
> // Proposed "simpler" compile-time interface
>
> // Restrictions on a static interface
> // 1) No data members
> // 2) Public methods only
> // 3) No type dependency on derived type
> // 4) Declarations only, no method implementations
> // 5) Any others???
> //
> // If any of those restrictions are not acceptable, resort to CRTP
>
> struct interface
> {
> void fn();
> };
>
> struct thing : [keyword_goes_here] interface
> {
> void fn() { /* ... */ }
> };
>
> thing t;
> t.fn();
>
>
> Of course, the actual keyword to plug in there to indicate compile-time
> interface inheritance could be anything. Candidates I could think of were:
> static
> const
> constexpr
>
> There would be no virtual table introduced, only compile-time checking
> that the interface is met. I'm not sure if final/override would apply in
> these cases. Thoughts?
>
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1753_4958257.1378318193242
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd vote for <span style=3D"font-family: courier new,monos=
pace;">static</span>.<br><br>Can you please give an example that truly exer=
cises the construct? Yours works all the same with<br><br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> thing<br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> fn</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/* ...=
*/</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>thing t</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>t</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">fn</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br></span></div></code></div><div><br><br></div><br><br><br>On Wednesday,=
September 4, 2013 7:15:23 PM UTC+2, Michael Price - Dev wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">As useful as the CRTP is,=
it can be awfully intimidating/confusing for people not familiar with it. =
I'm looking for opinions on the following idea.<div><br></div><div>Al=
low compile-time interface enforcement via a simpler, more "normal" inherit=
ance syntax (the simplest use cases of the CRTP).</div><div><br></div><div>=
Example:</div><div><br></div><div><font face=3D"courier new, monospace">// =
C++11 "simple" compile-time interface</font></div><div><font face=3D"courie=
r new, monospace"><br></font></div><div><font face=3D"courier new, monospac=
e">template <typename T></font></div><div><font face=3D"courier new, =
monospace">struct interface</font></div><div><font face=3D"courier new, mon=
ospace">{</font></div><div><font face=3D"courier new, monospace"> &nb=
sp; void fn() { return static_cast<T*>(this)->fn_<wbr>impl(); }</f=
ont></div><div><font face=3D"courier new, monospace">};</font></div><div><f=
ont face=3D"courier new, monospace"><br></font></div><div><font face=3D"cou=
rier new, monospace">struct thing : interface<thing></font></div><div=
><font face=3D"courier new, monospace">{</font></div><div><font face=3D"cou=
rier new, monospace"> void fn_impl() { /* ... */ }</font></div=
><div><font face=3D"courier new, monospace">};</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">thing t;</font></div><div><font face=3D"courier new, monospace=
">t.fn();</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><font face=3D"courier new, monospace"><br></font></div><div><di=
v><font face=3D"courier new, monospace">// Proposed "simpler" compile-time =
interface</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><font face=3D"courier new, monospace">// Restrictions on a stat=
ic interface</font></div><div><font face=3D"courier new, monospace">// &nbs=
p;1) No data members</font></div><div><font face=3D"courier new, monospace"=
>// 2) Public methods only</font></div><div><font face=3D"courier new=
, monospace">// 3) No type dependency on derived type</font></div><di=
v><font face=3D"courier new, monospace">// 4) Declarations only, no m=
ethod implementations</font></div><div><font face=3D"courier new, monospace=
">// 5) Any others???</font></div><div><font face=3D"courier new, mon=
ospace">//</font></div><div><font face=3D"courier new, monospace">// =
If any of those restrictions are not acceptable, resort to CRTP</font></div=
><div><font face=3D"courier new, monospace"><br></font></div><div><font fac=
e=3D"courier new, monospace">struct interface<br></font></div><div><font fa=
ce=3D"courier new, monospace">{</font></div><div><font face=3D"courier new,=
monospace"> void fn();</font></div><div><font face=3D"courier=
new, monospace">};</font></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><font face=3D"courier new, monospace">struct thing : =
[keyword_goes_here] interface</font></div><div><font face=3D"courier new, m=
onospace">{</font></div><div><font face=3D"courier new, monospace"> &=
nbsp; void fn() { /* ... */ }</font></div><div><font face=3D"courier new, m=
onospace">};</font></div><div><font face=3D"courier new, monospace"><br></f=
ont></div><div><font face=3D"courier new, monospace">thing t;</font></div><=
div><font face=3D"courier new, monospace">t.fn();</font></div></div><div><b=
r></div><div><br></div><div>Of course, the actual keyword to plug in there =
to indicate compile-time interface inheritance could be anything. Can=
didates I could think of were:</div><div><font face=3D"courier new, monospa=
ce">static</font></div><div><font face=3D"courier new, monospace">const</fo=
nt></div><div><font face=3D"courier new, monospace">constexpr</font></div><=
div><br></div><div>There would be no virtual table introduced, only compile=
-time checking that the interface is met. I'm not sure if final/overr=
ide would apply in these cases. Thoughts?</div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1753_4958257.1378318193242--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 4 Sep 2013 17:37:45 -0700 (PDT)
Raw View
------=_Part_4843_4679197.1378341465250
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, September 4, 2013 10:15:23 AM UTC-7, Michael Price - Dev
wrote:
>
> As useful as the CRTP is, it can be awfully intimidating/confusing for
> people not familiar with it. I'm looking for opinions on the following
> idea.
>
> Allow compile-time interface enforcement via a simpler, more "normal"
> inheritance syntax (the simplest use cases of the CRTP).
>
> Example:
>
> // C++11 "simple" compile-time interface
>
> template <typename T>
> struct interface
> {
> void fn() { return static_cast<T*>(this)->fn_impl(); }
> };
>
> struct thing : interface<thing>
> {
> void fn_impl() { /* ... */ }
> };
>
> thing t;
> t.fn();
>
>
> // Proposed "simpler" compile-time interface
>
> // Restrictions on a static interface
> // 1) No data members
> // 2) Public methods only
> // 3) No type dependency on derived type
> // 4) Declarations only, no method implementations
> // 5) Any others???
> //
> // If any of those restrictions are not acceptable, resort to CRTP
>
> struct interface
> {
> void fn();
> };
>
> struct thing : [keyword_goes_here] interface
> {
> void fn() { /* ... */ }
> };
>
> thing t;
> t.fn();
>
>
> Of course, the actual keyword to plug in there to indicate compile-time
> interface inheritance could be anything. Candidates I could think of were:
> static
> const
> constexpr
>
> There would be no virtual table introduced, only compile-time checking
> that the interface is met. I'm not sure if final/override would apply in
> these cases. Thoughts?
>
Forget the keyword; I'm not even sure what that code is supposed to *mean*.
Can you clarify the exact meaning of such a declaration? What does
`interface::fn` do, what type does it's `this` refer to, and how does that
relate to `thing::fn`?
Also, why is `interface` not a *template*? Or more to the point, *how* is
it not a template?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4843_4679197.1378341465250
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 4, 2013 10:15:23 AM UTC-7,=
Michael Price - Dev wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">As useful as the CRTP is, it can be awfully intimidating/conf=
using for people not familiar with it. I'm looking for opinions on th=
e following idea.<div><br></div><div>Allow compile-time interface enforceme=
nt via a simpler, more "normal" inheritance syntax (the simplest use cases =
of the CRTP).</div><div><br></div><div>Example:</div><div><br></div><div><f=
ont face=3D"courier new, monospace">// C++11 "simple" compile-time interfac=
e</font></div><div><font face=3D"courier new, monospace"><br></font></div><=
div><font face=3D"courier new, monospace">template <typename T></font=
></div><div><font face=3D"courier new, monospace">struct interface</font></=
div><div><font face=3D"courier new, monospace">{</font></div><div><font fac=
e=3D"courier new, monospace"> void fn() { return static_cast&l=
t;T*>(this)->fn_<wbr>impl(); }</font></div><div><font face=3D"courier=
new, monospace">};</font></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><font face=3D"courier new, monospace">struct thing : =
interface<thing></font></div><div><font face=3D"courier new, monospac=
e">{</font></div><div><font face=3D"courier new, monospace"> v=
oid fn_impl() { /* ... */ }</font></div><div><font face=3D"courier new, mon=
ospace">};</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"courier new, monospace">thing t;</font></div><di=
v><font face=3D"courier new, monospace">t.fn();</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace"><br></font></div><div><div><font face=3D"courier new, monospac=
e">// Proposed "simpler" compile-time interface</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">// Restrictions on a static interface</font></div><div><font f=
ace=3D"courier new, monospace">// 1) No data members</font></div><div=
><font face=3D"courier new, monospace">// 2) Public methods only</fon=
t></div><div><font face=3D"courier new, monospace">// 3) No type depe=
ndency on derived type</font></div><div><font face=3D"courier new, monospac=
e">// 4) Declarations only, no method implementations</font></div><di=
v><font face=3D"courier new, monospace">// 5) Any others???</font></d=
iv><div><font face=3D"courier new, monospace">//</font></div><div><font fac=
e=3D"courier new, monospace">// If any of those restrictions are not =
acceptable, resort to CRTP</font></div><div><font face=3D"courier new, mono=
space"><br></font></div><div><font face=3D"courier new, monospace">struct i=
nterface<br></font></div><div><font face=3D"courier new, monospace">{</font=
></div><div><font face=3D"courier new, monospace"> void fn();<=
/font></div><div><font face=3D"courier new, monospace">};</font></div><div>=
<font face=3D"courier new, monospace"><br></font></div><div><font face=3D"c=
ourier new, monospace">struct thing : [keyword_goes_here] interface</font><=
/div><div><font face=3D"courier new, monospace">{</font></div><div><font fa=
ce=3D"courier new, monospace"> void fn() { /* ... */ }</font><=
/div><div><font face=3D"courier new, monospace">};</font></div><div><font f=
ace=3D"courier new, monospace"><br></font></div><div><font face=3D"courier =
new, monospace">thing t;</font></div><div><font face=3D"courier new, monosp=
ace">t.fn();</font></div></div><div><br></div><div><br></div><div>Of course=
, the actual keyword to plug in there to indicate compile-time interface in=
heritance could be anything. Candidates I could think of were:</div><=
div><font face=3D"courier new, monospace">static</font></div><div><font fac=
e=3D"courier new, monospace">const</font></div><div><font face=3D"courier n=
ew, monospace">constexpr</font></div><div><br></div><div>There would be no =
virtual table introduced, only compile-time checking that the interface is =
met. I'm not sure if final/override would apply in these cases. Thoug=
hts?</div></div></blockquote><div><br>Forget the keyword; I'm not even sure=
what that code is supposed to <i>mean</i>. Can you clarify the exact meani=
ng of such a declaration? What does `interface::fn` do, what type does it's=
`this` refer to, and how does that relate to `thing::fn`?<br><br>Also, why=
is `interface` not a <i>template</i>? Or more to the point, <i>how</i> is =
it not a template?<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4843_4679197.1378341465250--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 18:06:06 -0700 (PDT)
Raw View
------=_Part_4852_8051421.1378343166189
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, September 5, 2013 1:15:23 AM UTC+8, Michael Price - Dev wrote:
>
> // Restrictions on a static interface
> // 1) No data members
> // 2) Public methods only
>
This is too restrictive to be useful.
> // 3) No type dependency on derived type
>
That's the whole point of CRTP. Your example uses a type-dependent
expression to call fn_impl. Are you sure this is what you mean?
> // 4) Declarations only, no method implementations
>
Again, your already example violates this. As any, it seems, must.
> // 5) Any others???
> //
> // If any of those restrictions are not acceptable, resort to CRTP
>
So, we should give hand-holding for the more delicate users, then abandon
them when they actually need something non-trivial?
> There would be no virtual table introduced, only compile-time checking
> that the interface is met. I'm not sure if final/override would apply in
> these cases. Thoughts?
>
Maybe check the current thread on "mixins". The idea sounds similar but not
nearly so restrictive.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4852_8051421.1378343166189
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 5, 2013 1:15:23 AM UTC+8, M=
ichael Price - Dev wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><font face=3D"courier new, monospace">// Restrictions on a stat=
ic interface</font><div><div><font face=3D"courier new, monospace">//  =
;1) No data members</font></div><div><font face=3D"courier new, monospace">=
// 2) Public methods only</font></div></div></div></blockquote><div><=
br>This is too restrictive to be useful.<br> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><font face=3D"courie=
r new, monospace">// 3) No type dependency on derived type</font></di=
v></div></div></blockquote><div><br>That's the whole point of CRTP. Your ex=
ample uses a type-dependent expression to call <span style=3D"font-family: =
courier new,monospace;">fn_impl</span>. Are you sure this is what you mean?=
<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div><font face=3D"courier new, monospace">// 4) Declarations=
only, no method implementations</font></div></div></div></blockquote><div>=
<br>Again, your already example violates this. As any, it seems, must.<br>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv><div><font face=3D"courier new, monospace">// 5) Any others???</fo=
nt></div><div><font face=3D"courier new, monospace">//</font></div><div><fo=
nt face=3D"courier new, monospace">// If any of those restrictions ar=
e not acceptable, resort to CRTP</font></div></div></div></blockquote><div>=
<br>So, we should give hand-holding for the more delicate users, then aband=
on them when they actually need something non-trivial?<br> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">There would be no =
virtual table introduced, only compile-time checking that the interface is =
met. I'm not sure if final/override would apply in these cases. Thoug=
hts?</div></blockquote><div><br>Maybe check the current thread on "mixins".=
The idea sounds similar but not nearly so restrictive.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4852_8051421.1378343166189--
.