Topic: Adding compile-time code generation to C++
Author: Martin Molzer <martin.molzer@gmx.de>
Date: Tue, 30 Jun 2015 13:35:28 -0700 (PDT)
Raw View
------=_Part_1097_1696328854.1435696528854
Content-Type: multipart/alternative;
boundary="----=_Part_1098_206151606.1435696528854"
------=_Part_1098_206151606.1435696528854
Content-Type: text/plain; charset=UTF-8
The intent for this is mostly interest in compile-time reflection and
building code on its result. As it turns out, it would be useful for much
more. While the c++11/c++14 standard brought us type_traits, it misses out
on giving us the ability to generate code.
The following is my take on it, not meant to be complete but rather a
sketch for general discussion. As far as I can see, it would barely break
any existing source, nor does it require revolutionary semantics.
Note: All names introduced are up to discussion.
The idea is that language constructs are representable by types that are
only available at compile time (in constexpr context). This is because
expressions come in so many different constructs and arrangements that
simply defining templated meta types is not really affordable, nor is it
readable.
1. A new specifier is needed - __constexprtype in the following, a standin
until further decisions. Note: constexpr could be used. A type specified as
constexpr is called a constexpr-type. Of course not every type is suitable
as a constexpr-type. Because such type is mostly used in conjunction with
constexpr functions, it seems natural to use the same restrictions as for
the return type of a constexpr function - a constexpr-type must thus be a
LiteralType.
Obviously, because it is meant to only be available at compile time, there
have to be restrictions when one can use such a type. It is standing to
reason that it can only be used in constexpr context, that is:
1. As a template parameter although usage is restricted in this case,
see below *
2. As a parameter in a constexpr function
3. As a constexpr (member, global or class-static) object
*) It is not allowed to use the parameter in e.g. a non-constexpr
context, though
Note: this forces evaluation of any expression containing a
constexpr-type at compile time because it can not be delayed until runtime
Because constexpr-types are only available during compile time, it wouldn't
make sense to declare any non-constexpr member methods, thus all member
methods, constructors and destructors are automatically declared constexpr.
TODO: do all of a constexpr-type's specializations have to have the
constexpr? What does this mean - are some instantiations allowed in
non-constexpr context.
Example (for syntactic presentation only):
constexpr class integral {
int val;
integral(int value) : val(value) {}
};
An actual use case is pointed out below.
2. Further, a set of types has to be defined to represent syntactic units
(see [gram]) during compile-time. Every compiler has to implement its own
interface to those types, thus a representation during runtime is and
should not be available. All those types should be constexpr-types.
Their purpose is to represent syntactically correct language constructs,
not semantically correct ones.
All those types should have constructors defined according to their
grammatical definition.
Example:
constexpr class token {
token(identifier); // Constructs a token from an identifier.
token(keyword); // etc...
token(literal);
token(operator);
token(punctuator);
// ... omitted
};
A special type parser_input is used to represent arbitrary, unparsed
preprocessing-token. It is only later given meaning to when it is converted
to one of the more precise types (see below).
Objects of those types, named snytax-classes in the following, ultimately
have to be constructed from parsed input (after string literal
concatenation is probably a suitable place). This part is up to closer
inspection, one of the following syntax may be the choice to go:
class Foo; // Doesn't have to be declared, included for readability
constexpr int derive_hash(class_name) { return 0; } // example declaration
of a method receiving such an argument
// Proposed calls:
derive_hash(__parse<class_name>(Foo)); // where __parse is some keyword
// general case: func(__parse<syntax-class-type>(raw text input))
derive_hash(__parse(Foo)); // special case, no syntax-class is given, so it
is parsed
// as parser_input and then implicitly converted
to class_name
// Not prefered:
derive_hash(Foo); // raw text is converted implicitly to the syntax-class
Another special syntax-class is parser_output. It represents the code
equivalent of syntax-class-objects. When the parser encounters an constexpr
expression which result is of (possibly c-qualified) parser_output, the
code represented by it is parsed as if it was found instead of the
expression. To convert any object of a syntax-class to parser_output the
keyword __unparse(object) proposed (reverse process of __parse). This could
be replaced by an implicit cast instead of reserving again another keyword
(which could break compatibility).
I haven't found one but is there already a working group for similar
purpose? I would appreciate feedback on this first sketch of, let's call it
"type-safe macros" for the moment. This is all not very highly developed,
all thoughts so far come from me alone (an 18-year old university student).
--
---
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_1098_206151606.1435696528854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The intent for this is mostly interest in compile-time ref=
lection and building code on its result. As it turns out, it would be usefu=
l for much more. While the c++11/c++14 standard brought us type_traits, it =
misses out on giving us the ability to generate code.<br><br>The following =
is my take on it, not meant to be complete but rather a sketch for general =
discussion. As far as I can see, it would barely break any existing source,=
nor does it require revolutionary semantics.<br><br>Note: All names introd=
uced are up to discussion.<br><br><u> &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp; </u><br><br>The idea is that langu=
age constructs are representable by types that are only available at compil=
e time (in constexpr context). This is because expressions come in so many =
different constructs and arrangements that simply defining templated meta t=
ypes is not really affordable, nor is it readable. <br><br>1. A new specifi=
er is needed - __constexprtype in the following, a standin until further de=
cisions. Note: constexpr could be used. A type specified as constexpr is ca=
lled a constexpr-type. Of course not every type is suitable as a constexpr-=
type. Because such type is mostly used in conjunction with constexpr functi=
ons, it seems natural to use the same restrictions as for the return type o=
f a constexpr function - a constexpr-type must thus be a LiteralType.<br><b=
r>Obviously, because it is meant to only be available at compile time, ther=
e have to be restrictions when one can use such a type. It is standing to r=
eason that it can only be used in constexpr context, that is:<br><ol><li>&n=
bsp; As a template parameter although usage is restricted in this cas=
e, see below *</li><li> As a parameter in a constexpr function<=
/li><li> As a constexpr (member, global or class-static) object=
</li></ol> <br> *) It is not allowed to=
use the parameter in e.g. a non-constexpr context, though<br> &=
nbsp; Note: this forces evaluation of any expression containing a constexpr=
-type at compile time because it can not be delayed until runtime<br><br>Be=
cause constexpr-types are only available during compile time, it wouldn't m=
ake sense to declare any non-constexpr member methods, thus all member meth=
ods, constructors and destructors are automatically declared constexpr.<br>=
<br>TODO: do all of a constexpr-type's specializations have to have the con=
stexpr? What does this mean - are some instantiations allowed in non-conste=
xpr context.<br><br>Example (for syntactic presentation only):<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> integral </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">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> val</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> integral</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> value</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> val</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">value</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;" cla=
ss=3D"styled-by-prettify">{}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></div></code></div><br><br><br>An actual use case is pointed=
out below.<br><br>2. Further, a set of types has to be defined to represen=
t syntactic units (see [gram]) during compile-time. Every compiler has to i=
mplement its own interface to those types, thus a representation during run=
time is and should not be available. All those types should be constexpr-ty=
pes.<br>Their purpose is to represent syntactically correct language constr=
ucts, not semantically correct ones.<br><br>All those types should have con=
structors defined according to their grammatical definition.<br><br>Example=
:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
stexpr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> token </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> token</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">identifier</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// Constructs a token from an identifier.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
token</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">keywor=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// etc...</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> token</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">literal</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> token</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> token</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">punctuator</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// ... omitted</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><br><br><br>=
A special type parser_input is used to represent arbitrary, unparsed prepro=
cessing-token. It is only later given meaning to when it is converted to on=
e of the more precise types (see below).<br><br>Objects of those types, nam=
ed snytax-classes in the following, ultimately have to be constructed from =
parsed input (after string literal concatenation is probably a suitable pla=
ce). This part is up to closer inspection, one of the following syntax may =
be the choice to go:<br><br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// Doesn't have to be d=
eclared, included for readability</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">constexpr</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> derive_hash</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">class_=
name</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">0</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-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// example declaration of=
a method receiving such an argument</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// Proposed calls:</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>derive_hash</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">__parse</span><span style=3D"color: #080;" class=3D=
"styled-by-prettify"><class_name></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
where __parse is some keyword</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// general case: func(__parse<syntax-class-type>(raw tex=
t input))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>derive_hash</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">__par=
se</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// special case, no syntax-class is give=
n, so it is parsed</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> =
</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// as parser_input and then implicitly converted to=
class_name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// No=
t prefered:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>derive_hash</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// raw text is converted im=
plicitly to the syntax-class</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br>Another special syntax-=
class is parser_output. It represents the code equivalent of syntax-class-o=
bjects. When the parser encounters an constexpr expression which result is =
of (possibly c-qualified) parser_output, the code represented by it is pars=
ed as if it was found instead of the expression. To convert any object of a=
syntax-class to parser_output the keyword __unparse(object) proposed (reve=
rse process of __parse). This could be replaced by an implicit cast instead=
of reserving again another keyword (which could break compatibility).<br><=
u> &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; </u><br><br>I haven't found one but is there already a working gro=
up for similar purpose? I would appreciate feedback on this first sketch of=
, let's call it "type-safe macros" for the moment. This is all not very hig=
hly developed, all thoughts so far come from me alone (an 18-year old unive=
rsity student).<br><br><br></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 <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 />
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_1098_206151606.1435696528854--
------=_Part_1097_1696328854.1435696528854--
.
Author: hun.nemethpeter@gmail.com
Date: Tue, 30 Jun 2015 13:46:44 -0700 (PDT)
Raw View
------=_Part_1130_1053883392.1435697205033
Content-Type: multipart/alternative;
boundary="----=_Part_1131_173048888.1435697205033"
------=_Part_1131_173048888.1435697205033
Content-Type: text/plain; charset=UTF-8
I'm thinking on some similar construct. I want a lambda like expression,
where every variable is predeclared in the capture block, or it can get
parameters from as a normal parameter.
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md
--
---
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_1131_173048888.1435697205033
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm thinking on some similar construct. I want a lambda li=
ke expression, where every variable is predeclared in the capture block, or=
it can get parameters from as a normal parameter.<br><br><a href=3D"https:=
//github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/c=
onstexpr_id_proposal.md">https://github.com/hun-nemethpeter/cpp-reflector-m=
ini/blob/master/constexpr-ast/constexpr_id_proposal.md</a><br><br></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 <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 />
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_1131_173048888.1435697205033--
------=_Part_1130_1053883392.1435697205033--
.
Author: martin.molzer@gmx.de
Date: Tue, 30 Jun 2015 14:26:00 -0700 (PDT)
Raw View
------=_Part_1034_2053794532.1435699560721
Content-Type: multipart/alternative;
boundary="----=_Part_1035_1620041093.1435699560721"
------=_Part_1035_1620041093.1435699560721
Content-Type: text/plain; charset=UTF-8
I've thought of an example, using the upcoming concepts-lite with c++1y.
When you have heard of the "fastest-possible-forwarding" you pretty much
know what I'm about to talk about.
We could implement a type that, given a type-concept as template parameter,
can build a "public interface" representing that concept and that can store
objects of any type fulfilling the concept.
template<concept C>
constexpr member_specification fillbody() {
// Some fancy implementation, "iterating" over all declared methods
// And returning a list of declarations/implementations of all those
// methods using the method of "fastest-possible-forwarding".
return constructed_members;
}
template<concept C>
class ConceptFacade {
template<C T>
ConceptFacade(T obj); // Ctor
__unparse(fillbody<C>())
};
template<concept C, C T>
void rebind(ConceptFacade&, T obj); // etc...
Combined with "using declarations for variables and functions" this could
make a 100% covering facade of the concept where you can bind any variable
satisfying the concept C to the ConceptFacade and use them all in the same
way: as if they had only the concept defined.
--
---
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_1035_1620041093.1435699560721
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've thought of an example, using the upcoming concepts-li=
te with c++1y. When you have heard of the "fastest-possible-forwarding" you=
pretty much know what I'm about to talk about.<br>We could implement a typ=
e that, given a type-concept as template parameter, can build a "public int=
erface" representing that concept and that can store objects of any type fu=
lfilling the concept.<br><br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">template</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">concept</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> member_specifi=
cation fillbody</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">// Some fancy=
implementation, "iterating" over all declared methods</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> </span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// And returning a list=
of declarations/implementations of all those</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">// methods using the method of "=
fastest-possible-forwarding".</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> <br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> constructed_members</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=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: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">concept</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">ConceptFacade</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">C T</span><span style=3D"col=
or: #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: #606;" class=3D"styled-by-prettify">ConceptFacade</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">T obj</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// Ctor</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br> __unparse</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">fillbody</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">C</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">>())</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> <br> <br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">concept</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> C=
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> rebind</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">ConceptFacade</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&,</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> T obj</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">// etc...</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span></div></code></div><br><br>Combined with "usi=
ng declarations for variables and functions" this could make a 100% coverin=
g facade of the concept where you can bind any variable satisfying the conc=
ept C to the ConceptFacade and use them all in the same way: as if they had=
only the concept defined.<br><br></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 <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 />
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_1035_1620041093.1435699560721--
------=_Part_1034_2053794532.1435699560721--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Wed, 1 Jul 2015 03:45:48 -0700 (PDT)
Raw View
------=_Part_1906_1940449221.1435747548217
Content-Type: multipart/alternative;
boundary="----=_Part_1907_1443394005.1435747548217"
------=_Part_1907_1443394005.1435747548217
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, 30 June 2015 21:35:28 UTC+1, Martin Molzer wrote:
>
> I haven't found one but is there already a working group for similar=20
> purpose? I would appreciate feedback on this first sketch of, let's call =
it=20
> "type-safe macros" for the moment. This is all not very highly developed,=
=20
> all thoughts so far come from me alone (an 18-year old university student=
).
>
Reflection is SG7. At Lenexa (May of this year) there were presented two of=
=20
the three currently leading comprehensive proposals:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4451
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4447
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4428.pdf was not=
=20
presented, but a previous version was presented to SG7 previously (at=20
Rapperswil IIRC). Botond Ballo's trip=20
report https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards=
-meeting-in-lenexa-may-2015/=20
is worth reading (scroll down to "SG 7 (Reflection)".
I'd argue that your ideas are closest to Mat=C2=B4u=CB=87s Chochl=C2=B4=C4=
=B1k's strong static=20
reflection - perhaps you could investigate whether that would allow you to=
=20
achieve what you're aiming for?
(Personally I find the variadic proposal most natural in syntax; I remain=
=20
to be convinced that there is any benefit in allowing reification of=20
structural elements as opposed to types, declarations and possibly names).
--=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/.
------=_Part_1907_1443394005.1435747548217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 30 June 2015 21:35:28 UTC+1, Martin Molzer wr=
ote:<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">I haven't=
found one but is there already a working group for similar purpose? I woul=
d appreciate feedback on this first sketch of, let's call it "type-safe mac=
ros" for the moment. This is all not very highly developed, all thoughts so=
far come from me alone (an 18-year old university student).</div></blockqu=
ote><div><br></div><div>Reflection is SG7. At Lenexa (May of this year) the=
re were presented two of the three currently leading comprehensive proposal=
s:</div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4451<=
br></div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4447=
<br></div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n442=
8.pdf was not presented, but a previous version was presented to SG7 previo=
usly (at Rapperswil IIRC). Botond Ballo's trip report https://botondba=
llo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-=
2015/ is worth reading (scroll down to "SG 7 (Reflection)".<br></div><div><=
br></div><div>I'd argue that your ideas are closest to Mat=C2=B4u=CB=
=87s Chochl=C2=B4=C4=B1k's strong static reflection - perhaps you could inv=
estigate whether that would allow you to achieve what you're aiming for?</d=
iv><div><br></div><div>(Personally I find the variadic proposal most natura=
l in syntax; I remain to be convinced that there is any benefit in allowing=
reification of structural elements as opposed to types, declarations and p=
ossibly names).</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 <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 />
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_1907_1443394005.1435747548217--
------=_Part_1906_1940449221.1435747548217--
.