On Tue, Jun 1, 2010 at 11:43 PM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote: >> (2) we should prefer standard solution over home-grown hacks, unless >> there is a clear demonstration of value. For example, it would be >> unwise to prefer our current VEC_xxx over std::vector. Conversely, >> we should probably have our own hash table, since there is none in >> C++98. > > 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).
std::vector can be garbage collected. > > How would we handle these in a C++ GCC? I have no clear ideas on that > today. Perhaps we might > > a. have our own vector template which is almost exactly like std::vector > but named differently except that it is specially supported by GGC & > gengtype. > > b. add special annotations (maybe attributes or pragmas or GTY macros > invocations or something else...) inside the code of the definition of > std::vec template (perhaps inside libstdc++-v3/include/std/vector) to no, you don't want to do this because we wan't to start with any C++98 compiler including GCC's we released before the switch. > add GTY support. However, this makes our compiler less able to use some > other's vendor std::vec > > c. add special annotations on every use of our vectors. BTW, this is > what our current practice of vec.h already do. > > But still I don't understand how precisely we would have garbage > collected vectors, or vectors of garbage collected pointers. We need > them. > > And if possible, the solution should be generic enough to work for any > other standard C++ container (i.e. maps, ...). >
