------=_Part_35_24477471.1380274826936
Content-Type: text/plain; charset=ISO-8859-1

Having now followed this group for a few weeks I have noticed a great fear
of breaking someone's code when introducing new features. While this is of
course important in general it can be taken too far. Adding overloads of
methods is a typical case. Here is a recent example:

Someone suggested a new stringstream::str() const && overload to grab the
string buffer out of a stringstream that will not be used anymore. The
problem is that if someone has written move(mystringstream).str() today
they may rely on the non-existance of a const&& overload and continue using
the stream afterwards. This use of move() is clearly ill-adviced as the
notion of move() is that it renders the moved object unusable. Still, for
fear that someone may rely on the move() being a nop in this case the
suggestion was quite strongly advocated against.

My suggestion is to work towards creating a tool that can do a statistical
analysis of different potentially code breaking standard changes by
scanning a large base of source code. This would be a non-trivial task of
course, but I think today doable. Clang can be used as a basis for the
analysis itself and there are plently of places with lots of source code
like github and sourceforge. The main obstacle I see is to be able to
automate the build environment setup. It is quite easy to download a
project from sourceforge but to get all the include directories etc. set up
to compile it not standardized. Even if only cmake projects are considered
there is usually a lot of handiwork required to get projects compilable.

There are of course a lot of large and important code bases that are not
reached by this type of tool as they are proprietary. As an extension,
however, it would be possible to offer some kind of satellite setup where a
company with a large and valuable code base (and possibly a say in the
standards committe) could have their own scanning server which receives
jobs from the central tool and only delivers the statistics back, say
"there were 4 uses of move(stringstream).str() in 176563466 lines of code".
As the statistics is human readable the risk of leaking sensitive
information can be controlled.

The other problem is how to define a test. Ideally in the example you would
test for uses of move(stringstream).str() where the stringstream was
actually used after this statement. This would require quite a lot of
analysis and probably some specific C++ code written in the Clang code
base. Just detecting move(stringstream).str() could maybe be done by some
kind of general pattern matching in the AST, while just detecting
move(stringstream) would be simple but useless as it would get myriads of
uninteresting hits.

The motivation is of course to be able to say with some confidence that
while a standard change is potentially code breaking we have x million
lines of code where this does not happen. Also allowing anyone with a
proprietary code base to get their code scanned for potential problems
before the standard change would give the committe leverage in saying that
anyone not participating could be left uncatered for.

Another example where such code scanning would be interesting is the
introduction of names like Object into the std namespace which will happen
if some concepts lite suggestions get accepted into the standard. Here I
think that a scan  would detect lots of code that would break severly... A
scan could tell if I'm right in this or if it is a non-issue.

--

---
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_35_24477471.1380274826936
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Having now followed this group for a few weeks I have noti=
ced a great fear of breaking someone's code when introducing new features. =
While this is of course important in general it can be taken too far. Addin=
g overloads of methods is a typical case. Here is a recent example:<div><br=
></div><div>Someone suggested a new stringstream::str() const &amp;&amp; ov=
erload to grab the string buffer out of a stringstream that will not be use=
d anymore. The problem is that if someone has written move(mystringstream).=
str() today they may rely on the non-existance of a const&amp;&amp; overloa=
d and continue using the stream afterwards. This use of move() is clearly i=
ll-adviced as the notion of move() is that it renders the moved object unus=
able. Still, for fear that someone may rely on the move() being a nop in th=
is case the suggestion was quite strongly advocated against.</div><div><br>=
</div><div>My suggestion is to work towards creating a tool that can do a s=
tatistical analysis of different potentially code breaking standard changes=
 by scanning a large base of source code. This would be a non-trivial task =
of course, but I think today doable. Clang can be used as a basis for the a=
nalysis itself and there are plently of places with lots of source code lik=
e github and sourceforge. The main obstacle I see is to be able to automate=
 the build environment setup. It is quite easy to download a project from s=
ourceforge but to get all the include directories etc. set up to compile it=
 not standardized. Even if only cmake projects are considered there is usua=
lly a lot of handiwork required to get projects compilable.</div><div><br><=
/div><div>There are of course a lot of large and important code bases that =
are not reached by this type of tool as they are proprietary. As an extensi=
on, however, it would be possible to offer some kind of satellite setup whe=
re a company with a large and valuable code base (and possibly a say in the=
 standards committe) could have their own scanning server which receives jo=
bs from the central tool and only delivers the statistics back, say "there =
were 4 uses of move(stringstream).str() in 176563466 lines of code". As the=
 statistics is human readable the risk of leaking sensitive information can=
 be controlled.</div><div><br></div><div>The other problem is how to define=
 a test. Ideally in the example you would test for uses of move(stringstrea=
m).str() where the stringstream was actually used after this statement. Thi=
s would require quite a lot of analysis and probably some specific C++ code=
 written in the Clang code base. Just detecting move(stringstream).str() co=
uld maybe be done by some kind of general pattern matching in the AST, whil=
e just detecting move(stringstream) would be simple but useless as it would=
 get myriads of uninteresting hits.</div><div><br></div><div>The motivation=
 is of course to be able to say with some confidence that while a standard =
change is potentially code breaking we have x million lines of code where t=
his does not happen. Also allowing anyone with a proprietary code base to g=
et their code scanned for potential problems before the standard change wou=
ld give the committe leverage in saying that anyone not participating could=
 be left uncatered for.</div><div><br></div><div>Another example where such=
 code scanning would be interesting is the introduction of names like Objec=
t into the std namespace which will happen if some concepts lite suggestion=
s get accepted into the standard. Here I think that a scan &nbsp;would dete=
ct lots of code that would break severly... A scan could tell if I'm right =
in this or if it is a non-issue.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_35_24477471.1380274826936--

.

--089e0158af4eef3c8704e75e2648
Content-Type: text/plain; charset=ISO-8859-1

On 27 September 2013 04:40, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

>
> My suggestion is to work towards creating a tool that can do a statistical
> analysis of different potentially code breaking standard changes by
> scanning a large base of source code.
>

Why is this in std-proposals?  I see nothing here that needs to be
addressed by the C++ Standard.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--089e0158af4eef3c8704e75e2648
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 27 September 2013 04:40, Bengt Gustafsson <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank"=
>bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><br></div><div>My suggestion is to work towards creating a tool that c=
an do a statistical analysis of different potentially code breaking standar=
d changes by scanning a large base of source code.</div>

</div></blockquote><div><br></div><div>Why is this in std-proposals? =A0I s=
ee nothing here that needs to be addressed by the C++ Standard.</div></div>=
-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158af4eef3c8704e75e2648--

.

------=_Part_761_17449934.1380330238042
Content-Type: text/plain; charset=ISO-8859-1

No, but to make changes to the standard it is quite obvious that being able
to assess the impact is important. I showed this quite clearly, I think,
using a few examples.

But if there is a more suitable list where you discuss the methods and
processes and tools used when working with C++ standard changes I can
repost there.

Den fredagen den 27:e september 2013 kl. 16:17:11 UTC+2 skrev Nevin ":-)"
Liber:
>
> On 27 September 2013 04:40, Bengt Gustafsson <bengt.gu...@beamways.com<javascript:>
> > wrote:
>
>>
>> My suggestion is to work towards creating a tool that can do a
>> statistical analysis of different potentially code breaking standard
>> changes by scanning a large base of source code.
>>
>
> Why is this in std-proposals?  I see nothing here that needs to be
> addressed by the C++ Standard.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

---
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_761_17449934.1380330238042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No, but to make changes to the standard it is quite obviou=
s that being able to assess the impact is important. I showed this quite cl=
early, I think, using a few examples.<div><br></div><div>But if there is a =
more suitable list where you discuss the methods and processes and tools us=
ed when working with C++ standard changes I can repost there.</div><div><di=
v><div><br>Den fredagen den 27:e september 2013 kl. 16:17:11 UTC+2 skrev Ne=
vin ":-)" Liber:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On 27 September 2013 04:40, Bengt Gustafsson <span dir=3D"ltr">&lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"3yFVwlK62mcJ"=
>bengt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br><div>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><br></div><div>My suggestion is to work towards creating a tool that c=
an do a statistical analysis of different potentially code breaking standar=
d changes by scanning a large base of source code.</div>

</div></blockquote><div><br></div><div>Why is this in std-proposals? &nbsp;=
I see nothing here that needs to be addressed by the C++ Standard.</div></d=
iv>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"3yFVwlK62mcJ">ne...@eviloverlord=
..com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_761_17449934.1380330238042--

.

--001a11c2c8ea7f00c604e772983c
Content-Type: text/plain; charset=ISO-8859-1

On 27 September 2013 20:03, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

> But if there is a more suitable list where you discuss the methods and
> processes and tools used when working with C++ standard changes I can
> repost there.
>

I don't know where (maybe compiler-specific forums, Usenet, etc.), but that
doesn't make it appropriate for here.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--001a11c2c8ea7f00c604e772983c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 27 September 2013 20:03, Bengt Gustafsson <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank"=
>bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
But if there is a more suitable list where you discuss the methods and proc=
esses and tools used when working with C++ standard changes I can repost th=
ere.<br>

</div></blockquote><div><br></div><div>I don&#39;t know where (maybe compil=
er-specific forums, Usenet, etc.), but that doesn&#39;t make it appropriate=
 for here.=A0</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c8ea7f00c604e772983c--

.

------=_Part_1342_21540792.1380416346997
Content-Type: text/plain; charset=ISO-8859-1


On Friday, September 27, 2013 5:40:26 PM UTC+8, Bengt Gustafsson wrote:
>
> Having now followed this group for a few weeks I have noticed a great fear
> of breaking someone's code when introducing new features. While this is of
> course important in general it can be taken too far. Adding overloads of
> methods is a typical case. Here is a recent example:
>
> Someone suggested a new stringstream::str() const && overload to grab the
> string buffer out of a stringstream that will not be used anymore. The
> problem is that if someone has written move(mystringstream).str() today
> they may rely on the non-existance of a const&& overload and continue using
> the stream afterwards. This use of move() is clearly ill-adviced as the
> notion of move() is that it renders the moved object unusable. Still, for
> fear that someone may rely on the move() being a nop in this case the
> suggestion was quite strongly advocated against.
>

If the user wrote that, then they intended for move() not to be a no-op.
That's an idiomatic rvalue member access. Perhaps the code wasn't *tested*to work as they intended, and perhaps they added something later to use the
moved-from object, and now there's a bug per their intent that isn't
getting caught. That they could predict the no-op is besides the point;
such is the nature of "unspecified state." Part of that proposal is that
O(1) may not be guaranteed if the implementation doesn't/can't reassign
ownership of the underlying buffer.


> My suggestion is to work towards creating a tool that can do a statistical
> analysis of different potentially code breaking standard changes by
> scanning a large base of source code. This would be a non-trivial task of
> course, but I think today doable.
>

What advance in computer science makes this doable?


> Clang can be used as a basis for the analysis itself and there are plently
> of places with lots of source code like github and sourceforge.
>

Volume of source isn't the answer. People write in idioms, and tend not to
be very adventurous. My current project doesn't even *parse* in Clang.


> The main obstacle I see is to be able to automate the build environment
> setup. It is quite easy to download a project from sourceforge but to get
> all the include directories etc. set up to compile it not standardized.
> Even if only cmake projects are considered there is usually a lot of
> handiwork required to get projects compilable.
>
> There are of course a lot of large and important code bases that are not
> reached by this type of tool as they are proprietary. As an extension,
> however, it would be possible to offer some kind of satellite setup where a
> company with a large and valuable code base (and possibly a say in the
> standards committe) could have their own scanning server which receives
> jobs from the central tool and only delivers the statistics back, say
> "there were 4 uses of move(stringstream).str() in 176563466 lines of code".
> As the statistics is human readable the risk of leaking sensitive
> information can be controlled.
>

You could sell such a product. Companies could write-up their own feedback
and send it to official channels such as proposal authors.

A good value proposition can make money for everyone. But the initial
investment here sounds pretty high.


> The other problem is how to define a test. Ideally in the example you
> would test for uses of move(stringstream).str() where the stringstream was
> actually used after this statement. This would require quite a lot of
> analysis and probably some specific C++ code written in the Clang code
> base. Just detecting move(stringstream).str() could maybe be done by some
> kind of general pattern matching in the AST, while just detecting
> move(stringstream) would be simple but useless as it would get myriads of
> uninteresting hits.
>

An AST search index would be a nice tool for proposal authors. But most
code hasn't been fully updated to C++11. What we do now is theorize about
what could go wrong, and that's not such a bad way to predict the future
:v) .

I don't think move(ss).str() probably ever literally occurs unless the user
is intending a move operation and "living with" the copy for now. Finding
problems would be more a matter of finding all instances of move(x).y where
x is type-dependent and multiplying by the probability of an argument into
a generic function being a stringstream.

The necessary statistics may not be very well-developed. Academic review
might turn up some kind of analysis techniques.


> Another example where such code scanning would be interesting is the
> introduction of names like Object into the std namespace which will happen
> if some concepts lite suggestions get accepted into the standard. Here I
> think that a scan  would detect lots of code that would break severly... A
> scan could tell if I'm right in this or if it is a non-issue.
>

RIP Google Code Search.


--

---
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_1342_21540792.1380416346997
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, September 27, 2013 5:40:26 PM UTC+8, Bengt =
Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Having now followed this group for a few weeks I have noticed a great f=
ear of breaking someone's code when introducing new features. While this is=
 of course important in general it can be taken too far. Adding overloads o=
f methods is a typical case. Here is a recent example:<div><br></div><div>S=
omeone suggested a new stringstream::str() const &amp;&amp; overload to gra=
b the string buffer out of a stringstream that will not be used anymore. Th=
e problem is that if someone has written move(mystringstream).str() today t=
hey may rely on the non-existance of a const&amp;&amp; overload and continu=
e using the stream afterwards. This use of move() is clearly ill-adviced as=
 the notion of move() is that it renders the moved object unusable. Still, =
for fear that someone may rely on the move() being a nop in this case the s=
uggestion was quite strongly advocated against.</div></div></blockquote><di=
v><br>If the user wrote that, then they intended for move() not to be a no-=
op. That's an idiomatic rvalue member access. Perhaps the code wasn't <i>te=
sted</i> to work as they intended, and perhaps they added something later t=
o use the moved-from object, and now there's a bug per their intent that is=
n't getting caught. That they could predict the no-op is besides the point;=
 such is the nature of "unspecified state." Part of that proposal is that O=
(1) may not be guaranteed if the implementation doesn't/can't reassign owne=
rship of the underlying buffer.<br>&nbsp;</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>My suggestion is to work towards cre=
ating a tool that can do a statistical analysis of different potentially co=
de breaking standard changes by scanning a large base of source code. This =
would be a non-trivial task of course, but I think today doable.</div></div=
></blockquote><div><br>What advance in computer science makes this doable?<=
br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div> Clang can be used as a basis for the analysis itself and there are =
plently of places with lots of source code like github and sourceforge.</di=
v></div></blockquote><div><br>Volume of source isn't the answer. People wri=
te in idioms, and tend not to be very adventurous. My current project doesn=
't even <i>parse</i> in Clang.<br>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div> The main obstacle I see is to be abl=
e to automate the build environment setup. It is quite easy to download a p=
roject from sourceforge but to get all the include directories etc. set up =
to compile it not standardized. Even if only cmake projects are considered =
there is usually a lot of handiwork required to get projects compilable.</d=
iv><div><br></div><div>There are of course a lot of large and important cod=
e bases that are not reached by this type of tool as they are proprietary. =
As an extension, however, it would be possible to offer some kind of satell=
ite setup where a company with a large and valuable code base (and possibly=
 a say in the standards committe) could have their own scanning server whic=
h receives jobs from the central tool and only delivers the statistics back=
, say "there were 4 uses of move(stringstream).str() in 176563466 lines of =
code". As the statistics is human readable the risk of leaking sensitive in=
formation can be controlled.</div></div></blockquote><div><br>You could sel=
l such a product. Companies could write-up their own feedback and send it t=
o official channels such as proposal authors.<br><br>A good value propositi=
on can make money for everyone. But the initial investment here sounds pret=
ty high.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>The other problem is how to define a test. Ideally in the e=
xample you would test for uses of move(stringstream).str() where the string=
stream was actually used after this statement. This would require quite a l=
ot of analysis and probably some specific C++ code written in the Clang cod=
e base. Just detecting move(stringstream).str() could maybe be done by some=
 kind of general pattern matching in the AST, while just detecting move(str=
ingstream) would be simple but useless as it would get myriads of uninteres=
ting hits.</div></div></blockquote><div><br>An AST search index would be a =
nice tool for proposal authors. But most code hasn't been fully updated to =
C++11. What we do now is theorize about what could go wrong, and that's not=
 such a bad way to predict the future :v) .<br><br>I don't think <span styl=
e=3D"font-family: courier new,monospace;">move(ss).str()</span> probably ev=
er literally occurs unless the user is intending a move operation and "livi=
ng with" the copy for now. Finding problems would be more a matter of findi=
ng all instances of <span style=3D"font-family: courier new,monospace;">mov=
e(x).y</span> where x is type-dependent and multiplying by the probability =
of an argument into a generic function being a stringstream.<br><br>The nec=
essary statistics may not be very well-developed. Academic review might tur=
n up some kind of analysis techniques.<br>&nbsp;</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>Another example where such co=
de scanning would be interesting is the introduction of names like Object i=
nto the std namespace which will happen if some concepts lite suggestions g=
et accepted into the standard. Here I think that a scan &nbsp;would detect =
lots of code that would break severly... A scan could tell if I'm right in =
this or if it is a non-issue.</div></div></blockquote><div><br>RIP Google C=
ode Search.<br>&nbsp;<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1342_21540792.1380416346997--

.