2010/6/2 Basile Starynkevitch <bas...@starynkevitch.net>: > I am not entirely convinced of that. VEC is supported not only by > infamous vec.h macros (which we surely want to replace by some template, > possibly std::vec) but also by gengtype (and the Gcc Garbage Collector). > > I strongly believe we will need a garbage collector (perhaps improving > the current one). So we surely will continue to need garbage collected > vectors (with all the variants existing in today's GCC). > > How would we handle these in a C++ GCC? I have no clear ideas on that > today. Perhaps we might >
See http://gcc.gnu.org/wiki/gcc-in-cxx , section "Major TODO": work out the details of using STL containers with GC allocated objects. This means teaching gengtype how to generate code to traverse STL containers, which would then be used during GC. This is not a task for the faint-hearted. Basically we can teach gengtype to walk std::vector. But I don't see how we can avoid dependency in gengtype on vector internal structures (_M_impl) and similar, and if that would not preclude building gcc with 3rd party standard library (which would be a real concern). > c. add special annotations on every use of our vectors. BTW, this is > what our current practice of vec.h already do. We can make gengtype recognize std::vector variables even without GTY annotations. -- Laurynas
