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). 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 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, ...). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
