Okay, this is half the argument. The second half would be: - Does auto cause such mistakes more often than it prevents them? The benefit claimed for auto is that it usually makes code more legible. Hopefully that prevents mistakes, on the balance.
- Is ranged-for more prone to iterator invalidation errors than the older form? I believe I've seen .Length() calls hoisted out of old-form loop conditions pretty frequently. The advantage of ranged-for is claimed to be that it depends on the operand's iteration API, instead of requiring the programmer to invent an iteration technique each time they write a loop. - Are closures more prone to ownership mistakes than the pre-closure technique? How does this compare with their benefits to legibility? When evaluating the impact of new features, we should not let the familiarity of the mistakes we've been making in C++98 for twenty years cause us to focus only on the risks from change. That misjudgment would hurt the quality of the code. On Mon, Oct 30, 2017 at 8:03 AM, smaug <sm...@welho.com> wrote: > On 10/30/2017 04:52 PM, Simon Sapin wrote: > >> On 30/10/17 15:05, smaug wrote: >> >>> And let's be careful with the new C++ features, pretty please. We >>> managed to not be careful when we started to use auto, or ranged-for >>> or lambdas. I'd prefer to not fix more security critical bugs or >>> memory leaks just because of fancy hip and cool language features ;) >>> >> >> Careful how? How do new language features lead to security bugs? Is new >> compiler code not as well tested and could have miscompiles? Are specific >> features easy to misuse? >> >> > > With auto we've managed to hide the ownership of some objects from > reader/reviewer (and I guess also from the patch author), > and this has lead to both to security issues and memory leaks. > > Ranged-for lead to security critical crashes when we converted some old > style > for (i = 0; i < array.Length(); ++i) to use it, since ranged-for doesn't > play well when the array changes underneath you. > These days we crash safely there. > > With lambdas understanding who owns what becomes harder, and before some > checks, we had (I think rather short while) issues when > there was a raw pointer to a refcounted object captured in a lambda and > the lambda was then dispatched to the event loop. > Nothing guaranteed the captured object to stay alive. > > Basically, some "new" features have hidden important aspects of the > lifetime management of objects, and by > doing that, made it easier to write broken code and harder by the > reviewers to catch the mistakes. > > > > -Olli > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
