On 5/29/12, Richard Guenther <richard.guent...@gmail.com> wrote: > On May 25, 2012 Mike Stump <mikest...@comcast.net> wrote: > > On May 25, 2012, at 10:50 AM, Lawrence Crowl wrote: > > > Diego and I looked long and hard at this issue. It all came > > > down to a sequence of problems. First, libstdc++ isn't rigged > > > for GTY, > > > > If portability to other C++ compilers wasn't a concern, we could > > extend out g++ to make supporting GTY better, so that we can > > simplify and refine the GTY stuff. I fear we need some light > > weight reflection, might make a nice language feature for a > > future C++ standard, if done well. > > Seconded. It points the finger of my #1 concern with the C++ > conversion - our GC. We need a GC scheme that allows us to use > standard library containers, and the scheme that was outlined > earlier would work.
Using the standard library containers is not a prerequisite to using C++, nor is it the source of primary benefit. You can build the compiler completely independently of the standard library. There are even good reasons to do so. More importantly, the standard library containers have different operations, different semantics, and different performance implications from the existing containers. Replacing any existing container uses with standard library uses is actually many tasks, which should be done incrementally after the infrastructure is in place. More importantly, some of that replacement would not be trivial, and the specialists in particular data structures might be better suited to it. > Are the TR1 hash table implementations using any non-C++98/03 > features? If not then I would suggest to use our TR1 hash tables. Almost by definition they are not using non-C++03 features. I do not think we should try to make that change in one step, but make it an eventual goal. -- Lawrence Crowl
