steve naroff wrote: > > On Dec 14, 2008, at 10:59 AM, Sebastian Redl wrote: > >> Now consider an IDE that integrates the Clang libraries for online >> syntax checking, auto-completion information, and similar things. >> Given that it works on code being edited, there will be lots of >> errors, and every single compilation with errors will leak. >> > > Are you saying that the only way to plug the leaks is to use smart > pointers *everywhere*? No. You could alternatively do a close audit of every commit do make sure every single control path carefully deletes all objects of which the current function retains ownership. The current state of the parser and sema tells me that this wasn't happening. So, let the compiler do the audit instead, and let programmers focus on the difficult cases, i.e. where raw pointers are used. > >> The moment the IDE implementor realizes this, he will think very hard >> about not using Clang. >> > > > As you are well aware, clang is an Open Source project that is under > active development. Memory leaks would certainly need to be addressed > before IDE integration is practical. In general, clang's architecture > has been driven by it's clients. If you are integrating clang within > an IDE, then I am confident your work will indeed solve problems faced > by IDE developers. I'm not doing this. But it was a scenario Chris mentioned when I initially posted about the leaks. > >> >>> In general, the Parser doesn't do much dynamic memory allocation >>> (yet you've had to make *many* changes to the Parser/Action API's). >> This is not really true. While the parser doesn't do much dynamic >> memory allocation by itself, it handles very many heap-allocated >> objects from Sema. > > It *is* true. Sema does the allocation, not the Parser. Since Sema > does the allocation, I don't know why the Parser interface needs to > change. It isn't about who does allocations, it's about who has ownership. If the Sema does an allocation and passes the ownership of the object to the parser, then the parser is fully responsible for the object. I personally believe that the ability to encode ownership in types is sufficient reason to do it. Since C++ has a very expressive, statically checked type system, it seems a waste not to put as much information as possible in there. Most people I know who like C++ like it because of the strong and expressive typing, as opposed to the uncertainty you often have in dynamic languages. If you encode ownership in types, the interface between parser and sema has to change.
Sebastian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
