Topic: [concepts] Concepts and Archetypes (Type Erasure)
Author: Herb Sutter <hsutter@microsoft.com>
Date: Fri, 5 Jul 2013 21:30:44 +0000
Raw View
> enisbayramoglu@gmail.com writes:
> | There's something that concerns me about the progress of the upcoming
> | C++ standards. I'm concerned that the currently proposed way of
> | introducing concepts into C++ will rule out an opportunity of
> | seamlessly merging concepts with a very closely related idea, that is t=
ype
> | erasure and archetypes.
Yes, but one issue is that it's not free: "type erasure" implicitly implies=
"indirection overhead." That's why:
> | What did we gain by this? Now we can actually call the template=20
> | just_increment function without including its definition.
Yes, trading off performance for separate template compilation is something=
we can do today, and it was explored extensively for C++0x concepts for se=
veral years which used a concept map for basically the same technique as yo=
u proposed.
FWIW, I think the real potential improvement for separate template compilat=
ion will come with modules -- if it comes at all, but I'm cautiously optimi=
stic about modules' progress with this, as it's much simpler than export te=
mplate attempted in the 1990s.
gdr@euclid.axiomatics.org writes:
> It was a conscious design decision, based on past experience, not to use
> archetypes (and by implication "concept maps") as either operational mode=
l
> or implementation model.
Yes. A concepts approach based on concept maps was deeply explored last dec=
ade with C++0x concepts, and at least some of us were convinced that it act=
ually turned out to be one of the key problematic parts of that earlier des=
ign with unresolved design and performance issues.
So yes, this has been deeply explored.
Herb
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: enisbayramoglu@gmail.com
Date: Fri, 5 Jul 2013 21:21:26 -0700 (PDT)
Raw View
------=_Part_3788_25270564.1373084486353
Content-Type: text/plain; charset=ISO-8859-1
Dear Herb and Gaby, I can see how using concept maps as the default
operational model would eliminate many optimization opportunities of
templates (demise of template metaprogramming) as well as adding an extra
layer of indirection, but isn't there any benefit in *optionally* creating
concept maps? Or was it decided that the effort needed to implement such a
dual operational model is not justified by the added benefits one could
obtain by hand coding the concept maps where needed?
Enis
On Saturday, July 6, 2013 12:30:44 AM UTC+3, Herb Sutter wrote:
>
> > enisbay...@gmail.com <javascript:> writes:
> > | There's something that concerns me about the progress of the upcoming
> > | C++ standards. I'm concerned that the currently proposed way of
> > | introducing concepts into C++ will rule out an opportunity of
> > | seamlessly merging concepts with a very closely related idea, that is
> type
> > | erasure and archetypes.
>
> Yes, but one issue is that it's not free: "type erasure" implicitly
> implies "indirection overhead." That's why:
>
> > | What did we gain by this? Now we can actually call the template
> > | just_increment function without including its definition.
>
> Yes, trading off performance for separate template compilation is
> something we can do today, and it was explored extensively for C++0x
> concepts for several years which used a concept map for basically the same
> technique as you proposed.
>
> FWIW, I think the real potential improvement for separate template
> compilation will come with modules -- if it comes at all, but I'm
> cautiously optimistic about modules' progress with this, as it's much
> simpler than export template attempted in the 1990s.
>
> g...@euclid.axiomatics.org <javascript:> writes:
> > It was a conscious design decision, based on past experience, not to use
> > archetypes (and by implication "concept maps") as either operational
> model
> > or implementation model.
>
> Yes. A concepts approach based on concept maps was deeply explored last
> decade with C++0x concepts, and at least some of us were convinced that it
> actually turned out to be one of the key problematic parts of that earlier
> design with unresolved design and performance issues.
>
> So yes, this has been deeply explored.
>
> Herb
>
>
>
--
---
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_3788_25270564.1373084486353
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Dear Herb and Gaby, I can see how using concept maps as the default operati=
onal model would eliminate many optimization opportunities of templates (de=
mise of template metaprogramming) as well as adding an extra layer of indir=
ection, but isn't there any benefit in *optionally* creating concept maps? =
Or was it decided that the effort needed to implement such a dual operation=
al model is not justified by the added benefits one could obtain by hand co=
ding the concept maps where needed?<div><br></div><div>Enis</div><div><br><=
/div><div>On Saturday, July 6, 2013 12:30:44 AM UTC+3, Herb Sutter wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">> <a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"2oHtMKCqb80J">enisbay...@gmail.com<=
/a> writes:
<br>> | There's something that concerns me about the progress of the upc=
oming
<br>> | C++ standards. I'm concerned that the currently proposed way of
<br>> | introducing concepts into C++ will rule out an opportunity of
<br>> | seamlessly merging concepts with a very closely related idea, th=
at is type
<br>> | erasure and archetypes.
<br>
<br>Yes, but one issue is that it's not free: "type erasure" implicitly imp=
lies "indirection overhead." That's why:
<br>
<br>> | What did we gain by this? Now we can actually call the template=
=20
<br>> | just_increment function without including its definition.
<br>
<br>Yes, trading off performance for separate template compilation is somet=
hing we can do today, and it was explored extensively for C++0x concepts fo=
r several years which used a concept map for basically the same technique a=
s you proposed.
<br>
<br>FWIW, I think the real potential improvement for separate template comp=
ilation will come with modules -- if it comes at all, but I'm cautiously op=
timistic about modules' progress with this, as it's much simpler than expor=
t template attempted in the 1990s.
<br>
<br><a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2oHt=
MKCqb80J">g...@euclid.axiomatics.org</a> writes:
<br>> It was a conscious design decision, based on past experience, not =
to use
<br>> archetypes (and by implication "concept maps") as either operation=
al model
<br>> or implementation model.
<br>
<br>Yes. A concepts approach based on concept maps was deeply explored last=
decade with C++0x concepts, and at least some of us were convinced that it=
actually turned out to be one of the key problematic parts of that earlier=
design with unresolved design and performance issues.
<br>
<br>So yes, this has been deeply explored.
<br>
<br>Herb
<br>
<br>
<br></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 />
<br />
<br />
------=_Part_3788_25270564.1373084486353--
.
Author: Herb Sutter <hsutter@microsoft.com>
Date: Mon, 8 Jul 2013 17:14:01 +0000
Raw View
--_000_4f8a23454eb847efa08217cf39744c09BN1PR03MB107namprd03pro_
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
My impression is that the C++0x Concept model of =93assuming=94 concept map=
s, specifying concepts in terms of those, and then relying on optimization =
to get rid of the overhead them away was not successful.
However, the current Concepts Lite model of not assuming concept maps leave=
s the door open to considering providing concept mapping in the future =96 =
the key difference being that it would be an additional optional layer that=
could be added if its use is desired, rather than integral to the core mod=
el and would have to be escaped from if its use is undesired.
Herb
From: enisbayramoglu@gmail.com [mailto:enisbayramoglu@gmail.com]
Sent: Friday, July 5, 2013 9:21 PM
To: std-proposals@isocpp.org
Cc: concepts@isocpp.org; Herb Sutter
Subject: Re: [concepts] Re: [std-proposals] Concepts and Archetypes (Type E=
rasure)
Dear Herb and Gaby, I can see how using concept maps as the default operati=
onal model would eliminate many optimization opportunities of templates (de=
mise of template metaprogramming) as well as adding an extra layer of indir=
ection, but isn't there any benefit in *optionally* creating concept maps? =
Or was it decided that the effort needed to implement such a dual operation=
al model is not justified by the added benefits one could obtain by hand co=
ding the concept maps where needed?
Enis
On Saturday, July 6, 2013 12:30:44 AM UTC+3, Herb Sutter wrote:
> enisbay...@gmail.com<javascript:> writes:
> | There's something that concerns me about the progress of the upcoming
> | C++ standards. I'm concerned that the currently proposed way of
> | introducing concepts into C++ will rule out an opportunity of
> | seamlessly merging concepts with a very closely related idea, that is t=
ype
> | erasure and archetypes.
Yes, but one issue is that it's not free: "type erasure" implicitly implies=
"indirection overhead." That's why:
> | What did we gain by this? Now we can actually call the template
> | just_increment function without including its definition.
Yes, trading off performance for separate template compilation is something=
we can do today, and it was explored extensively for C++0x concepts for se=
veral years which used a concept map for basically the same technique as yo=
u proposed.
FWIW, I think the real potential improvement for separate template compilat=
ion will come with modules -- if it comes at all, but I'm cautiously optimi=
stic about modules' progress with this, as it's much simpler than export te=
mplate attempted in the 1990s.
g...@euclid.axiomatics.org<javascript:> writes:
> It was a conscious design decision, based on past experience, not to use
> archetypes (and by implication "concept maps") as either operational mode=
l
> or implementation model.
Yes. A concepts approach based on concept maps was deeply explored last dec=
ade with C++0x concepts, and at least some of us were convinced that it act=
ually turned out to be one of the key problematic parts of that earlier des=
ign with unresolved design and performance issues.
So yes, this has been deeply explored.
Herb
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--_000_4f8a23454eb847efa08217cf39744c09BN1PR03MB107namprd03pro_
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">My impression is that the=
C++0x Concept model of =93assuming=94 concept maps, specifying con=
cepts in terms of those, and then relying on optimization to get rid
of the overhead them away was not successful.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">However, the current Conc=
epts Lite model of not assuming concept maps leaves the door open to consid=
ering providing concept mapping in the future =96 the key
difference being that it would be an additional optional layer that could =
be added if its use is desired, rather than integral to the core model and =
would have to be escaped from if its use is undesired.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Herb<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"=
;Calibri","sans-serif"">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:"Calibri","sans-serif""> enisba=
yramoglu@gmail.com [mailto:enisbayramoglu@gmail.com]
<br>
<b>Sent:</b> Friday, July 5, 2013 9:21 PM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Cc:</b> concepts@isocpp.org; Herb Sutter<br>
<b>Subject:</b> Re: [concepts] Re: [std-proposals] Concepts and Archetypes =
(Type Erasure)<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Dear Herb and Gaby, I can see how using concept maps=
as the default operational model would eliminate many optimization opportu=
nities of templates (demise of template metaprogramming) as well as adding =
an extra layer of indirection, but
isn't there any benefit in *optionally* creating concept maps? Or was it d=
ecided that the effort needed to implement such a dual operational model is=
not justified by the added benefits one could obtain by hand coding the co=
ncept maps where needed?<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Enis<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">On Saturday, July 6, 2013 12:30:44 AM UTC+3, Her=
b Sutter wrote:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">> <a href=3D"javas=
cript:" target=3D"_blank">
enisbay...@gmail.com</a> writes: <br>
> | There's something that concerns me about the progress of the upcomin=
g <br>
> | C++ standards. I'm concerned that the currently proposed way=
of <br>
> | introducing concepts into C++ will rule out an opportunity o=
f <br>
> | seamlessly merging concepts with a very closely related idea, that i=
s type <br>
> | erasure and archetypes. <br>
<br>
Yes, but one issue is that it's not free: "type erasure" implicit=
ly implies "indirection overhead." That's why:
<br>
<br>
> | What did we gain by this? Now we can actually call the template <br>
> | just_increment function without including its definition. <br>
<br>
Yes, trading off performance for separate template compilation is something=
we can do today, and it was explored extensively for C++0x concept=
s for several years which used a concept map for basically the same techniq=
ue as you proposed.
<br>
<br>
FWIW, I think the real potential improvement for separate template compilat=
ion will come with modules -- if it comes at all, but I'm cautiously optimi=
stic about modules' progress with this, as it's much simpler than export te=
mplate attempted in the 1990s.
<br>
<br>
<a href=3D"javascript:" target=3D"_blank">g...@euclid.axiomatics.org</a> wr=
ites: <br>
> It was a conscious design decision, based on past experience, not to u=
se <br>
> archetypes (and by implication "concept maps") as either ope=
rational model <br>
> or implementation model. <br>
<br>
Yes. A concepts approach based on concept maps was deeply explored last dec=
ade with C++0x concepts, and at least some of us were convinced tha=
t it actually turned out to be one of the key problematic parts of that ear=
lier design with unresolved design and performance
issues. <br>
<br>
So yes, this has been deeply explored. <br>
<br>
Herb <br>
<br>
<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>
<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 />
<br />
<br />
--_000_4f8a23454eb847efa08217cf39744c09BN1PR03MB107namprd03pro_--
.