------=_Part_1862_964800397.1432370781921
Content-Type: multipart/alternative;
 boundary="----=_Part_1863_781353863.1432370781921"

------=_Part_1863_781353863.1432370781921
Content-Type: text/plain; charset=UTF-8

Hi,

I have written an idea I got to extend the C++ language on my blog and have
been advised to post it here, so here it is. The basic idea is to help the
compiler remove functions that are actually used but with no side effects.
It does it automatically for simple functions, but it cannot always do it.
An example I have is with a signal system. Imagine it is like this:

template <size_t ID>
class Sender {
public:
  // some code
  static void send(/* parameters */);
};

template <size_t ID>
class Receiver {
public:
  // some code
  template <typename Function>
  void receive(Function f);
};

// Usage //////////////////////

// Elsewhere in the code ------
Receiver<0> receiver;

// later...
Sender<0>::send(/* parameters */);

// later...
receiver.receive([] (/* parameters */) {
  // something
});

Pretty simple, each signal is differentiated by an ID. When a signal needs
to be sent, one has just to call the send() function and every receivers
that exist at that time will receive the signal and handle it when the
receive() function is called.
With a GUI library, for example, a lot of signals will be sent whether
there is a receiver or not. But the send() function is not optimized out
(at least in my test application with GCC and clang and -O3), so some CPU
cycle are wasted when there are no receivers. My idea is then a keyword
that indicates that if a function or a class does not exist at link time,
when the executable is build, the dependent function calls can simply be
removed from the program, with no side-effects, and some performance
enhancements. For example, if we used as keyword "instancif" ("instance
if"), it could be used like that:

// condition is a class or a function
instancif(SomeClassOrFunction) void f1() {}
// condition is a member function
instancif(SomeClass::SomeFunction<int>) void f2() {}

// also useful for classes?
instancif(Something) class C1 {
  void f3();
  template <typename T>
  void f4(T);
  template <typename T>
  T f5();
  void f6();
};

// only for a class member
instancif(Something) void C1::f3() {}
// mixed with template
template <typename T>
instancif(SomeTemplateClass<T>) void C1::f4(T) {}
// also with template for condition
template <typename T, typename V>
instancif(SomeTemplateClass<V>) T C1::f5() { return {}; }
// and specialization
template <typename T>
instancif(SomeOtherTemplateClass<int, T>) void C1::f6() {}

The keyword is not useful for a library user, so I believe it should be
placed in the same manner as the "inline" keyword before the implementation
of the function.

So, do you have an opinion about that? Thanks.

Regards,
Adrien Hamelin

PS: I have a comment that says this could be mixed with the possible
"static if".
PPS: the original blog post
is https://aboutcpp.wordpress.com/2015/05/19/proposal-optimizing-out-useless-functions/

--

---
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_1863_781353863.1432370781921
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I have written an idea I got to ext=
end the C++ language on my blog and have been advised to post it here, so h=
ere it is. The basic idea is to help the compiler remove functions that are=
 actually used but with no side effects. It does it automatically for simpl=
e functions, but it cannot always do it.</div><div>An example I have is wit=
h a signal system. Imagine it is like this:</div><div><br></div><div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">size_t ID</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Sender</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">public</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// some code</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">static</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sen=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #800;" class=3D"styled-by-prettify">/* parameters */</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></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>&nbsp;<br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">size_t ID</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Receiver</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// some code</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Function</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> receive</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Fun=
ction</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// Usage //////////////////////</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;<br></=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Elsewhere=
 in the code ------</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Receiver</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> receiver</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;<br></span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// later...</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Sender</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">send</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">/* parameters */</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp;<br></span><span style=3D"color: #800;" class=3D"styled-by=
-prettify">// later...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>receiver</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">receive</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">([]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">/* parameters */</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// something</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">});</span></div></code></div><div class=3D"line=
 number25 index24 alt2" style=3D"font-family: Consolas, 'Bitstream Vera San=
s Mono', 'Courier New', Courier, monospace; font-size: 15px; line-height: 1=
6.5px; color: rgb(55, 55, 55); outline: 0px !important; padding-right: 1em =
!important; padding-left: 1em !important; border-radius: 0px !important; bo=
ttom: auto !important; float: none !important; height: auto !important; lef=
t: auto !important; overflow: visible !important; position: static !importa=
nt; right: auto !important; top: auto !important; width: auto !important; b=
ox-sizing: content-box !important; direction: ltr !important; -webkit-box-s=
hadow: none !important; box-shadow: none !important; white-space: pre !impo=
rtant; background-image: none !important; background-attachment: initial !i=
mportant; background-size: initial !important; background-origin: initial !=
important; background-clip: initial !important; background-position: initia=
l !important; background-repeat: initial !important;"><br></div></div><div>=
Pretty simple, each signal is differentiated by an ID. When a signal needs =
to be sent, one has just to call the send() function and&nbsp;every receive=
rs that exist at that time will receive the signal and handle it when the r=
eceive() function is called.</div><div>With a GUI library, for example, a l=
ot of signals will be sent whether there is a receiver or not. But the send=
() function is not optimized out (at least in my test application with GCC =
and clang and -O3), so some CPU cycle are wasted when there are no receiver=
s. My idea is then a keyword that indicates that if a function or a class d=
oes not exist at link time, when the executable is build, the dependent fun=
ction calls can simply be removed from the program, with no side-effects, a=
nd some performance enhancements. For example, if we used as keyword "insta=
ncif" ("instance if"), it could be used like that:</div><div><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"><span style=3D"color: #800;"=
 class=3D"styled-by-prettify">// condition is a class or a function</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>instancif</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">SomeClassOrFunction</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">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> f1</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-pretti=
fy"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 condition is a member function</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>instancif</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">SomeClass</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">SomeFunction</span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> f2</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"><br>&nbsp;<br></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// also useful for classes?</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>instancif</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Something</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: #008;" =
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> C1 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> f3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">template<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> f4</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; T f5</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> f6</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp;<br></span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// only for a class member</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>instancif</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Something</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> C1</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">f3</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #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"><br></span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// mixed with template</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>ins=
tancif</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeTemplateC=
lass</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> C1</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">f4</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">T</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: #660;" class=3D"styled-by-prettify">{}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// also with template for condition</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">template</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> V</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>in=
stancif</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeTemplate=
Class</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">V</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> T C1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">f5</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"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</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 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"color: #800;" c=
lass=3D"styled-by-prettify">// and specialization</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>instancif</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Some=
OtherTemplateClass</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> C1</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">f6</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">{}</spa=
n></div></code></div><div class=3D"line number26 index25 alt1" style=3D"fon=
t-family: Consolas, 'Bitstream Vera Sans Mono', 'Courier New', Courier, mon=
ospace; font-size: 15px; line-height: 16.5px; color: rgb(55, 55, 55); outli=
ne: 0px !important; padding-right: 1em !important; padding-left: 1em !impor=
tant; border-radius: 0px !important; bottom: auto !important; float: none !=
important; height: auto !important; left: auto !important; overflow: visibl=
e !important; position: static !important; right: auto !important; top: aut=
o !important; width: auto !important; box-sizing: content-box !important; d=
irection: ltr !important; -webkit-box-shadow: none !important; box-shadow: =
none !important; white-space: pre !important; background-image: none !impor=
tant; background-attachment: initial !important; background-size: initial !=
important; background-origin: initial !important; background-clip: initial =
!important; background-position: initial !important; background-repeat: ini=
tial !important;"><br></div></div><div>The keyword is not useful for a libr=
ary user, so I believe it should be placed in the same manner as the "inlin=
e" keyword before the implementation of the function.</div><div><br></div><=
div>So, do you have an opinion about that? Thanks.</div><div><br></div><div=
>Regards,</div><div>Adrien Hamelin</div><div><br></div><div>PS: I have a co=
mment that says this could be mixed with the possible "static if".</div><di=
v>PPS: the original blog post is&nbsp;https://aboutcpp.wordpress.com/2015/0=
5/19/proposal-optimizing-out-useless-functions/</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&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 />
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_1863_781353863.1432370781921--
------=_Part_1862_964800397.1432370781921--

.

------=_Part_2168_1570797638.1432399265764
Content-Type: multipart/alternative;
 boundary="----=_Part_2169_1379429295.1432399265764"

------=_Part_2169_1379429295.1432399265764
Content-Type: text/plain; charset=UTF-8



On Saturday, May 23, 2015 at 4:46:22 AM UTC-4, Adrien Hamelin wrote:
>
> With a GUI library, for example, a lot of signals will be sent whether
> there is a receiver or not. But the send() function is not optimized out
> (at least in my test application with GCC and clang and -O3), so some CPU
> cycle are wasted when there are no receivers. My idea is then a keyword
> that indicates that if a function or a class does not exist at link time,
> when the executable is build, the dependent function calls can simply be
> removed from the program, with no side-effects, and some performance
> enhancements.
>

You seem to be suggesting this under the belief that the GCC doesn't
optimize this out because the standard *forbids* them. If that's true, then
you ought to be able to point to the part of the standard that explicitly
forbids this.

And if you don't know what that part of the standard is, then I would
suggest that you're not knowledgable enough about the possible impact to
the standard to suggest this.

Also, I'm pretty sure the standard doesn't forbid this. After all,
compilers can choose not to output code for various functions, under all
kinds of circumstances. So long as the program behaves exactly as if it had
(in accord with the C++ standard), that's fine. So it seems to me that this
is a quality-of-implementation issue, not a standards issue.

The difference between what you're suggesting and a proposed `static if` is
substantial. `static if` makes it so that the contents are conditionally
*compiled*. And compilation is a process that is very much controlled by
the standard. What you're talking about is code generation and
optimization, which the standard doesn't talk about so much.

--

---
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_2169_1379429295.1432399265764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, May 23, 2015 at 4:46:22 AM UTC-4, Adr=
ien Hamelin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>With a GUI library, for example, a lot of signals will be sent wh=
ether there is a receiver or not. But the send() function is not optimized =
out (at least in my test application with GCC and clang and -O3), so some C=
PU cycle are wasted when there are no receivers. My idea is then a keyword =
that indicates that if a function or a class does not exist at link time, w=
hen the executable is build, the dependent function calls can simply be rem=
oved from the program, with no side-effects, and some performance enhanceme=
nts.</div></div></blockquote><div><br>You seem to be suggesting this under =
the belief that the GCC doesn't optimize this out because the standard <i>f=
orbids</i> them. If that's true, then you ought to be able to point to the =
part of the standard that explicitly forbids this.<br><br>And if you don't =
know what that part of the standard is, then I would suggest that you're no=
t knowledgable enough about the possible impact to the standard to suggest =
this.<br><br>Also, I'm pretty sure the standard doesn't forbid this. After =
all, compilers can choose not to output code for various functions, under a=
ll kinds of circumstances. So long as the program behaves exactly as if it =
had (in accord with the C++ standard), that's fine. So it seems to me that =
this is a quality-of-implementation issue, not a standards issue.<br><br>Th=
e difference between what you're suggesting and a proposed `static if` is s=
ubstantial. `static if` makes it so that the contents are conditionally <i>=
compiled</i>. And compilation is a process that is very much controlled by =
the standard. What you're talking about is code generation and optimization=
, which the standard doesn't talk about so much.<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&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 />
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_2169_1379429295.1432399265764--
------=_Part_2168_1570797638.1432399265764--

.

------=_Part_1746_1790564539.1432401831095
Content-Type: multipart/alternative;
 boundary="----=_Part_1747_1329861562.1432401831095"

------=_Part_1747_1329861562.1432401831095
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm sorry if I was not clear, I said nothing about the standard and same as=
=20
you I do not believe the standard forbids anything in that case. What I am=
=20
saying is that optimization is not an easy task, and there are limits to=20
what can be done automatically. I found a case where such a limit currently=
=20
applies and I had an idea to possibly push further the speed of C++ so I=20
posted it here to make it known and criticized. As you said, I do not know=
=20
everything and I believe this group is here to discuss ideas to valid or=20
reject them with good reasons, or maybe adapt them if they are the=20
beginning of something good.

Also I know that my proposal and a "static if" are different. There just=20
was a comment that maybe the two could be mixed so I mentioned it. If you=
=20
do no think this is possible or not something we could want, please just=20
say it.

So, do you have an opinion about the idea?

Le samedi 23 mai 2015 18:41:05 UTC+2, Nicol Bolas a =C3=A9crit :
>
>
>
> On Saturday, May 23, 2015 at 4:46:22 AM UTC-4, Adrien Hamelin wrote:
>>
>> With a GUI library, for example, a lot of signals will be sent whether=
=20
>> there is a receiver or not. But the send() function is not optimized out=
=20
>> (at least in my test application with GCC and clang and -O3), so some CP=
U=20
>> cycle are wasted when there are no receivers. My idea is then a keyword=
=20
>> that indicates that if a function or a class does not exist at link time=
,=20
>> when the executable is build, the dependent function calls can simply be=
=20
>> removed from the program, with no side-effects, and some performance=20
>> enhancements.
>>
>
> You seem to be suggesting this under the belief that the GCC doesn't=20
> optimize this out because the standard *forbids* them. If that's true,=20
> then you ought to be able to point to the part of the standard that=20
> explicitly forbids this.
>
> And if you don't know what that part of the standard is, then I would=20
> suggest that you're not knowledgable enough about the possible impact to=
=20
> the standard to suggest this.
>
> Also, I'm pretty sure the standard doesn't forbid this. After all,=20
> compilers can choose not to output code for various functions, under all=
=20
> kinds of circumstances. So long as the program behaves exactly as if it h=
ad=20
> (in accord with the C++ standard), that's fine. So it seems to me that th=
is=20
> is a quality-of-implementation issue, not a standards issue.
>
> The difference between what you're suggesting and a proposed `static if`=
=20
> is substantial. `static if` makes it so that the contents are conditional=
ly=20
> *compiled*. And compilation is a process that is very much controlled by=
=20
> the standard. What you're talking about is code generation and=20
> optimization, which the standard doesn't talk about so much.
>

--=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_1747_1329861562.1432401831095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm sorry if I was not clear, I said nothing about the sta=
ndard and same as you I do not believe the standard forbids anything in tha=
t case. What I am saying is that optimization is not an easy task, and ther=
e are limits to what can be done automatically. I found a case where such a=
 limit currently applies&nbsp;and I had an idea to possibly push further th=
e speed of C++ so I posted it here to&nbsp;make it known and criticized. As=
 you said, I do not know everything and I believe this group is here to dis=
cuss ideas to valid or reject them with good reasons, or maybe adapt them i=
f they are the beginning of something good.<div><br></div><div>Also I know =
that my proposal and a "static if" are different. There just was a comment =
that maybe the two could be mixed so I mentioned it. If you do no think thi=
s is possible or not something we could want, please just say it.<br><div><=
br></div><div>So, do you have an opinion about the idea?<br><br>Le samedi 2=
3 mai 2015 18:41:05 UTC+2, Nicol Bolas a =C3=A9crit&nbsp;:<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"><br><br>On Saturday, May 23, 2=
015 at 4:46:22 AM UTC-4, Adrien Hamelin wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>With a GUI library, for example, a lot of =
signals will be sent whether there is a receiver or not. But the send() fun=
ction is not optimized out (at least in my test application with GCC and cl=
ang and -O3), so some CPU cycle are wasted when there are no receivers. My =
idea is then a keyword that indicates that if a function or a class does no=
t exist at link time, when the executable is build, the dependent function =
calls can simply be removed from the program, with no side-effects, and som=
e performance enhancements.</div></div></blockquote><div><br>You seem to be=
 suggesting this under the belief that the GCC doesn't optimize this out be=
cause the standard <i>forbids</i> them. If that's true, then you ought to b=
e able to point to the part of the standard that explicitly forbids this.<b=
r><br>And if you don't know what that part of the standard is, then I would=
 suggest that you're not knowledgable enough about the possible impact to t=
he standard to suggest this.<br><br>Also, I'm pretty sure the standard does=
n't forbid this. After all, compilers can choose not to output code for var=
ious functions, under all kinds of circumstances. So long as the program be=
haves exactly as if it had (in accord with the C++ standard), that's fine. =
So it seems to me that this is a quality-of-implementation issue, not a sta=
ndards issue.<br><br>The difference between what you're suggesting and a pr=
oposed `static if` is substantial. `static if` makes it so that the content=
s are conditionally <i>compiled</i>. And compilation is a process that is v=
ery much controlled by the standard. What you're talking about is code gene=
ration and optimization, which the standard doesn't talk about so much.<br>=
</div></div></blockquote></div></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&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 />
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_1747_1329861562.1432401831095--
------=_Part_1746_1790564539.1432401831095--

.

On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:
> So, do you have an opinion about that? Thanks.

I think the answer is "that is not how compilers usually work". You're
suggesting that the compilation process reach all the way to the link step,
where it can verify whether the symbol exists, then begin optimising again.
Most compilers won't do any type of code generation at link time. Linkers are
known to do code relaxation at link time, but that's hardly anything close to
what you're suggesting.

I said "usually": modern compilers are now coming with link-time code
generation support, where they will produce all the code at link time. Your
feature would *require* LTCG in order to work at all. That is, without LTCG,
it would be a useless annotation. And since we're talking about LTCG and
whole-program optimisations, are you sure the compiler is unable to remove
unused functions?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_1751_1244457312.1432405070985
Content-Type: multipart/alternative;
 boundary="----=_Part_1752_1250804651.1432405070985"

------=_Part_1752_1250804651.1432405070985
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes about LTCG.

I am pretty sure that a compiler removes unused function, especially with=
=20
LTCG. What i am talking about are not unused functions, but used ones that=
=20
have no effects. Like in my example, the signal is always sent whether or=
=20
not there is a receiver. But if there are no receivers for a specific=20
signal in the whole program, this is just code that does something for=20
nothing and this is not optimized out in my test for sufficiently complex=
=20
functions. But i do not write compilers, so of course i am not a 100% sure.

Le samedi 23 mai 2015 20:09:37 UTC+2, Thiago Macieira a =C3=A9crit :
>
> On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:=20
> > So, do you have an opinion about that? Thanks.=20
>
> I think the answer is "that is not how compilers usually work". You're=20
> suggesting that the compilation process reach all the way to the link=20
> step,=20
> where it can verify whether the symbol exists, then begin optimising=20
> again.=20
> Most compilers won't do any type of code generation at link time. Linkers=
=20
> are=20
> known to do code relaxation at link time, but that's hardly anything clos=
e=20
> to=20
> what you're suggesting.=20
>
> I said "usually": modern compilers are now coming with link-time code=20
> generation support, where they will produce all the code at link time.=20
> Your=20
> feature would *require* LTCG in order to work at all. That is, without=20
> LTCG,=20
> it would be a useless annotation. And since we're talking about LTCG and=
=20
> whole-program optimisations, are you sure the compiler is unable to remov=
e=20
> unused functions?=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>
>

--=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_1752_1250804651.1432405070985
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes about LTCG.<div><br></div><div>I am pretty sure that a=
 compiler removes unused function, especially with LTCG. What i am talking =
about are not unused functions, but used ones that have no effects. Like in=
 my example, the signal is always sent whether or not there is a receiver. =
But if there are no receivers for a specific signal in the whole program, t=
his is just code that does something for nothing and this is not optimized =
out in my test for sufficiently complex functions. But i do not write compi=
lers, so of course i am not a 100% sure.<br><br>Le samedi 23 mai 2015 20:09=
:37 UTC+2, Thiago Macieira a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:
<br>&gt; So, do you have an opinion about that? Thanks.
<br>
<br>I think the answer is "that is not how compilers usually work". You're=
=20
<br>suggesting that the compilation process reach all the way to the link s=
tep,=20
<br>where it can verify whether the symbol exists, then begin optimising ag=
ain.=20
<br>Most compilers won't do any type of code generation at link time. Linke=
rs are=20
<br>known to do code relaxation at link time, but that's hardly anything cl=
ose to=20
<br>what you're suggesting.
<br>
<br>I said "usually": modern compilers are now coming with link-time code=
=20
<br>generation support, where they will produce all the code at link time. =
Your=20
<br>feature would *require* LTCG in order to work at all. That is, without =
LTCG,=20
<br>it would be a useless annotation. And since we're talking about LTCG an=
d=20
<br>whole-program optimisations, are you sure the compiler is unable to rem=
ove=20
<br>unused functions?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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&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 />
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_1752_1250804651.1432405070985--
------=_Part_1751_1244457312.1432405070985--

.

------=_Part_1837_1448004476.1432405427306
Content-Type: multipart/alternative;
 boundary="----=_Part_1838_1326540328.1432405427307"

------=_Part_1838_1326540328.1432405427307
Content-Type: text/plain; charset=UTF-8

On Saturday, May 23, 2015 at 2:09:37 PM UTC-4, Thiago Macieira wrote:
>
> On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:
> > So, do you have an opinion about that? Thanks.
>
> I think the answer is "that is not how compilers usually work". You're
> suggesting that the compilation process reach all the way to the link
> step,
> where it can verify whether the symbol exists, then begin optimising
> again.
> Most compilers won't do any type of code generation at link time. Linkers
> are
> known to do code relaxation at link time, but that's hardly anything close
> to
> what you're suggesting.
>
> I said "usually": modern compilers are now coming with link-time code
> generation support, where they will produce all the code at link time.
> Your
> feature would *require* LTCG in order to work at all. That is, without
> LTCG,
> it would be a useless annotation. And since we're talking about LTCG and
> whole-program optimisations, are you sure the compiler is unable to remove
> unused functions?
>

After looking at his `send`/`receive` example (in a mirror while standing
upside down), I think I understand why his code confounds the compiler.

I think the idea is that `Sender<int>`, for each integer it gets
instantiated with, has a static data member, that is a *runtime* list of
functions. Only a corresponding instance of `Receiver<int>` can add to or
remove from this list. Therefore, if nobody instantiates a `Receiver<int>`
for that particular integer ID, then nobody can have added to or removed
from the list. Therefore `Sender<int>::send` will always get an empty list.

The problem is that the list of functions is runtime-defined (it would be
perhaps a std::vector rather than a std::array or something). And that
makes it exceedingly difficult for whole program optimization to realize
that the only code that modifies the data structure is in `Receiver<int>`.
And therefore, it's hard to realize that if there are no `Receiver<int>`
objects, then the corresponding `Sender<int>::send` will get an empty list,
and therefore will do nothing.

Quite frankly, this is such an edge case that it's not worth the
committee's time to discuss it, let alone a full-on keyword.

--

---
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_1838_1326540328.1432405427307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, May 23, 2015 at 2:09:37 PM UTC-4, Thiago Maci=
eira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday 23 May =
2015 01:46:21 Adrien Hamelin wrote:
<br>&gt; So, do you have an opinion about that? Thanks.
<br>
<br>I think the answer is "that is not how compilers usually work". You're=
=20
<br>suggesting that the compilation process reach all the way to the link s=
tep,=20
<br>where it can verify whether the symbol exists, then begin optimising ag=
ain.=20
<br>Most compilers won't do any type of code generation at link time. Linke=
rs are=20
<br>known to do code relaxation at link time, but that's hardly anything cl=
ose to=20
<br>what you're suggesting.
<br>
<br>I said "usually": modern compilers are now coming with link-time code=
=20
<br>generation support, where they will produce all the code at link time. =
Your=20
<br>feature would *require* LTCG in order to work at all. That is, without =
LTCG,=20
<br>it would be a useless annotation. And since we're talking about LTCG an=
d=20
<br>whole-program optimisations, are you sure the compiler is unable to rem=
ove=20
<br>unused functions?
<br></blockquote><div><br>After looking at his `send`/`receive` example (in=
 a mirror while standing upside down), I think I understand why his code co=
nfounds the compiler.<br><br>I think the idea is that `Sender&lt;int&gt;`, =
for each integer it gets instantiated with, has a static data member, that =
is a <i>runtime</i> list of functions. Only a corresponding instance of `Re=
ceiver&lt;int&gt;` can add to or remove from this list. Therefore, if nobod=
y instantiates a `Receiver&lt;int&gt;` for that particular integer ID, then=
 nobody can have added to or removed from the list. Therefore `Sender&lt;in=
t&gt;::send` will always get an empty list.<br><br>The problem is that the =
list of functions is runtime-defined (it would be perhaps a std::vector rat=
her than a std::array or something). And that makes it exceedingly difficul=
t for whole program optimization to realize that the only code that modifie=
s the data structure is in `Receiver&lt;int&gt;`. And therefore, it's hard =
to realize that if there are no `Receiver&lt;int&gt;` objects, then the cor=
responding `Sender&lt;int&gt;::send` will get an empty list, and therefore =
will do nothing.<br><br>Quite frankly, this is such an edge case that it's =
not worth the committee's time to discuss it, let alone a full-on keyword.<=
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&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 />
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_1838_1326540328.1432405427307--
------=_Part_1837_1448004476.1432405427306--

.

------=_Part_149_60001510.1432405763273
Content-Type: multipart/alternative;
 boundary="----=_Part_150_1275548127.1432405763273"

------=_Part_150_1275548127.1432405763273
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is just an example, don't you think it would apply in other cases too?=
=20
If not then I believe you are right.

Le samedi 23 mai 2015 20:23:47 UTC+2, Nicol Bolas a =C3=A9crit :
>
> On Saturday, May 23, 2015 at 2:09:37 PM UTC-4, Thiago Macieira wrote:
>>
>> On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:=20
>> > So, do you have an opinion about that? Thanks.=20
>>
>> I think the answer is "that is not how compilers usually work". You're=
=20
>> suggesting that the compilation process reach all the way to the link=20
>> step,=20
>> where it can verify whether the symbol exists, then begin optimising=20
>> again.=20
>> Most compilers won't do any type of code generation at link time. Linker=
s=20
>> are=20
>> known to do code relaxation at link time, but that's hardly anything=20
>> close to=20
>> what you're suggesting.=20
>>
>> I said "usually": modern compilers are now coming with link-time code=20
>> generation support, where they will produce all the code at link time.=
=20
>> Your=20
>> feature would *require* LTCG in order to work at all. That is, without=
=20
>> LTCG,=20
>> it would be a useless annotation. And since we're talking about LTCG and=
=20
>> whole-program optimisations, are you sure the compiler is unable to=20
>> remove=20
>> unused functions?=20
>>
>
> After looking at his `send`/`receive` example (in a mirror while standing=
=20
> upside down), I think I understand why his code confounds the compiler.
>
> I think the idea is that `Sender<int>`, for each integer it gets=20
> instantiated with, has a static data member, that is a *runtime* list of=
=20
> functions. Only a corresponding instance of `Receiver<int>` can add to or=
=20
> remove from this list. Therefore, if nobody instantiates a `Receiver<int>=
`=20
> for that particular integer ID, then nobody can have added to or removed=
=20
> from the list. Therefore `Sender<int>::send` will always get an empty lis=
t.
>
> The problem is that the list of functions is runtime-defined (it would be=
=20
> perhaps a std::vector rather than a std::array or something). And that=20
> makes it exceedingly difficult for whole program optimization to realize=
=20
> that the only code that modifies the data structure is in `Receiver<int>`=
..=20
> And therefore, it's hard to realize that if there are no `Receiver<int>`=
=20
> objects, then the corresponding `Sender<int>::send` will get an empty lis=
t,=20
> and therefore will do nothing.
>
> Quite frankly, this is such an edge case that it's not worth the=20
> committee's time to discuss it, let alone a full-on keyword.
>

--=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_150_1275548127.1432405763273
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is just an example, don't you think it would apply in=
 other cases too? If not then I believe you are right.<div><br>Le samedi 23=
 mai 2015 20:23:47 UTC+2, Nicol Bolas a =C3=A9crit&nbsp;:<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">On Saturday, May 23, 2015 at 2=
:09:37 PM UTC-4, Thiago Macieira wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">On Saturday 23 May 2015 01:46:21 Adrien Hamelin wrote:
<br>&gt; So, do you have an opinion about that? Thanks.
<br>
<br>I think the answer is "that is not how compilers usually work". You're=
=20
<br>suggesting that the compilation process reach all the way to the link s=
tep,=20
<br>where it can verify whether the symbol exists, then begin optimising ag=
ain.=20
<br>Most compilers won't do any type of code generation at link time. Linke=
rs are=20
<br>known to do code relaxation at link time, but that's hardly anything cl=
ose to=20
<br>what you're suggesting.
<br>
<br>I said "usually": modern compilers are now coming with link-time code=
=20
<br>generation support, where they will produce all the code at link time. =
Your=20
<br>feature would *require* LTCG in order to work at all. That is, without =
LTCG,=20
<br>it would be a useless annotation. And since we're talking about LTCG an=
d=20
<br>whole-program optimisations, are you sure the compiler is unable to rem=
ove=20
<br>unused functions?
<br></blockquote><div><br>After looking at his `send`/`receive` example (in=
 a mirror while standing upside down), I think I understand why his code co=
nfounds the compiler.<br><br>I think the idea is that `Sender&lt;int&gt;`, =
for each integer it gets instantiated with, has a static data member, that =
is a <i>runtime</i> list of functions. Only a corresponding instance of `Re=
ceiver&lt;int&gt;` can add to or remove from this list. Therefore, if nobod=
y instantiates a `Receiver&lt;int&gt;` for that particular integer ID, then=
 nobody can have added to or removed from the list. Therefore `Sender&lt;in=
t&gt;::send` will always get an empty list.<br><br>The problem is that the =
list of functions is runtime-defined (it would be perhaps a std::vector rat=
her than a std::array or something). And that makes it exceedingly difficul=
t for whole program optimization to realize that the only code that modifie=
s the data structure is in `Receiver&lt;int&gt;`. And therefore, it's hard =
to realize that if there are no `Receiver&lt;int&gt;` objects, then the cor=
responding `Sender&lt;int&gt;::send` will get an empty list, and therefore =
will do nothing.<br><br>Quite frankly, this is such an edge case that it's =
not worth the committee's time to discuss it, let alone a full-on keyword.<=
br></div></div></blockquote></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&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 />
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_150_1275548127.1432405763273--
------=_Part_149_60001510.1432405763273--

.

------=_Part_2278_420200045.1432406298410
Content-Type: multipart/alternative;
 boundary="----=_Part_2279_1375924979.1432406298410"

------=_Part_2279_1375924979.1432406298410
Content-Type: text/plain; charset=UTF-8

On Saturday, May 23, 2015 at 2:29:23 PM UTC-4, Adrien Hamelin wrote:
>
> This is just an example, don't you think it would apply in other cases
> too? If not then I believe you are right.
>

My point was that, in order to confound the currently existing LTCG and
whole-program optimization schemes, you had to build a system where
communication between two static objects was based on a runtime object. I'm
sure that applies to more cases than yours, but how many? I don't think it
comes up very much.

And all you gained was... saving one function call. A call that would maybe
touch a couple of pieces of memory, then leave.

My point is that it seems very much like an edge case, something that
doesn't happen very much and, even when it does happen, doesn't have a
particularly great impact on the result.

Lastly, I don't believe that the standard has any authority to govern "code
generation" of this level. So, while an attribute *might* be appropriate,
that would be all it could be.

--

---
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_2279_1375924979.1432406298410
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, May 23, 2015 at 2:29:23 PM UTC-4, Adrien Hame=
lin 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">Thi=
s is just an example, don't you think it would apply in other cases too? If=
 not then I believe you are right.</div></blockquote><div><br>My point was =
that, in order to confound the currently existing LTCG and whole-program op=
timization schemes, you had to build a system where communication between t=
wo static objects was based on a runtime object. I'm sure that applies to m=
ore cases than yours, but how many? I don't think it comes up very much.<br=
><br>And all you gained was... saving one function call. A call that would =
maybe touch a couple of pieces of memory, then leave.<br><br>My point is th=
at it seems very much like an edge case, something that doesn't happen very=
 much and, even when it does happen, doesn't have a particularly great impa=
ct on the result.<br><br>Lastly, I don't believe that the standard has any =
authority to govern "code generation" of this level. So, while an attribute=
 <i>might</i> be appropriate, that would be all it could be.</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&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 />
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_2279_1375924979.1432406298410--
------=_Part_2278_420200045.1432406298410--

.

------=_Part_1765_413137810.1432406681683
Content-Type: multipart/alternative;
 boundary="----=_Part_1766_792541919.1432406681684"

------=_Part_1766_792541919.1432406681684
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well that is exactly for that kind of opinions that I posted here. Kind of=
=20
sad for my idea, but thanks anyway :-)
Maybe it can still exist as a compiler extension someday, if this happens=
=20
more than you think.

Le samedi 23 mai 2015 20:38:18 UTC+2, Nicol Bolas a =C3=A9crit :
>
> On Saturday, May 23, 2015 at 2:29:23 PM UTC-4, Adrien Hamelin wrote:
>>
>> This is just an example, don't you think it would apply in other cases=
=20
>> too? If not then I believe you are right.
>>
>
> My point was that, in order to confound the currently existing LTCG and=
=20
> whole-program optimization schemes, you had to build a system where=20
> communication between two static objects was based on a runtime object. I=
'm=20
> sure that applies to more cases than yours, but how many? I don't think i=
t=20
> comes up very much.
>
> And all you gained was... saving one function call. A call that would=20
> maybe touch a couple of pieces of memory, then leave.
>
> My point is that it seems very much like an edge case, something that=20
> doesn't happen very much and, even when it does happen, doesn't have a=20
> particularly great impact on the result.
>
> Lastly, I don't believe that the standard has any authority to govern=20
> "code generation" of this level. So, while an attribute *might* be=20
> appropriate, that would be all it could be.
>

--=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_1766_792541919.1432406681684
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well that is exactly for that kind of opinions that I post=
ed here. Kind of sad for my idea, but thanks anyway :-)<div>Maybe it can st=
ill exist as a compiler extension someday, if this happens more than you th=
ink.<br><br>Le samedi 23 mai 2015 20:38:18 UTC+2, Nicol Bolas a =C3=A9crit&=
nbsp;:<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">On Satu=
rday, May 23, 2015 at 2:29:23 PM UTC-4, Adrien Hamelin wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">This is just an example, don't y=
ou think it would apply in other cases too? If not then I believe you are r=
ight.</div></blockquote><div><br>My point was that, in order to confound th=
e currently existing LTCG and whole-program optimization schemes, you had t=
o build a system where communication between two static objects was based o=
n a runtime object. I'm sure that applies to more cases than yours, but how=
 many? I don't think it comes up very much.<br><br>And all you gained was..=
.. saving one function call. A call that would maybe touch a couple of piece=
s of memory, then leave.<br><br>My point is that it seems very much like an=
 edge case, something that doesn't happen very much and, even when it does =
happen, doesn't have a particularly great impact on the result.<br><br>Last=
ly, I don't believe that the standard has any authority to govern "code gen=
eration" of this level. So, while an attribute <i>might</i> be appropriate,=
 that would be all it could be.</div></div></blockquote></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&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 />
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_1766_792541919.1432406681684--
------=_Part_1765_413137810.1432406681683--

.

On Saturday 23 May 2015 11:44:41 Adrien Hamelin wrote:
> Maybe it can still exist as a compiler extension someday, if this happens
> more than you think.

Look for GCC's __attribute__((weakref("xxxx"))). This allows you to have a
callable function for which you can also test whether it's null or not
(function exists or not). This may be an input to LTCG: if the symbol is found
not to exist at link-time (whole program optimisation, not a library), the
whole code could be eliminated via dead code analysis.

You'll need to know the mangled names of the variables and functions.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.