On Wed, Nov 29, 2017, at 12:56 AM, Eric Rescorla wrote: > On Mon, Nov 27, 2017 at 6:41 PM, Xidorn Quan <m...@upsuper.org> wrote: >> On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: >> > On Mon, Nov 27, 2017 at 4:07 PM, smaug <sm...@welho.com> wrote: >> > > And auto makes code reading harder. It hides important >> > > information like lifetime management. It happens easily with >> > > auto that one doesn't even start to think whether >> > > nsCOMPtr/RefPtr should be used there. >> > >> > This statement seems perhaps a touch to universalist; it may be >> > the case that it makes it harder for *you* to read, but I find it >> > makes it easier for me to read. I also don't think it's a >> > coincidence that it's a common feature of modern languages (Rust >> > and Go, to name just two), so I suspect I'm not alone in thinking >> > auto is a good thing. >> >> Using Rust and Go as examples isn't very fair.>> >> Go has GC, and Rust has compile-time lifetime checking, so they are>> >> basically free from certain kind of lifetime issues. > > I don't think that it's unfair. My point was that these are features > that language designers and users think are desirable, which is why > they get added to languages. After all, you could certainly build a > language like Rust or Go that didn't have any type inference; people > would just wonder what you were thinking. And I strongly suspect they > got added to C++ for the same reason.> > With that said, this kind of lifetime issue in C++ largely arises from > the use of raw pointers (or auto_ptr, I guess, though that's been > deprecated), and in the specific cases under discussion here, by > intermixing old-style memory management with a bunch of the newer > features. We could of course deal with that by not letting anybody use > the new features, but it seems like a more promising direction would > be to move to a more modern memory management idiom, which C++-14 > already supports. Yes and no. That kind of lifetime issues are mainly raised from the use of raw pointers (as well as references, actually), but how do you (in your imagination) plan to get rid of all the raw pointers in the wild? Replace every code which currently returns / holds a raw pointer with a RefPtr / UniquePtr instead? Add weak reference wrapper for every type we need to weak reference? I don't believe that's something realistic.
Even ignoring the scale of code needs to change, this kind of "modern memory management" would likely come with a runtime cost in C++ (rather than mostly compile-time cost in Rust). It is more similar to the runtime cost Go would pay for its GC, but even worse, a refcount-based memory management system would generally be more expensive on runtime than a tracing GC. And I don't think that's a cost we (or most other C++ users) want to pay. To be honest, I don't really see how (more) modern C++ (14 and up) really makes memory management any better. There are more new features which tend to hide lifetime issues and let users bite the bullet themselves. Taking my example above again, std::string_view, which is added in C++17, can easily lead to UAF without any raw pointer usage in user code. How would the modern memory management idiom (which according to you, C++14 have already supported) help here? I'm not saying that we shouldn't let anybody use the new features. But certain new features really need more carefulness. They can be used when they wouldn't footgun, but they should be avoided otherwise. A new features' being there doesn't mean we must use it everywhere, and it will really make things better. - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
