gcc-in-cxx branch created
Ivan Levashew
I.Levashew@bluebottle.com
Wed Jun 25 02:08:00 GMT 2008
Ian Lance Taylor пиÑеÑ:
> Ivan Levashew <I.Levashew@bluebottle.com> writes:
>
>> Ian Lance Taylor пиÑеÑ:
>>> The other major TODO is to 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.
>>>
>> That's one of the many reasons against C++. Even damn Cyclone will
>> beat C++ here.
>
> Your comment makes little sense in context. Nobody could claim that
> the existing gengtype code is simple. Not many people understand how
> it works at all. In order to support STL containers holding GC
> objects, it will need to be modified.
I'm sure there is a library of GC-managed components in C++.
> The fact that modifying it is
> nontrivial is not an argument either for or against C++.
Bruno has a better critique on C++.
>
> I don't know what you mean by your reference to the Cyclone variant of
> C, unless you are trying to say something about gcc's use of garbage
> collection.
>
Cyclone has many options for memory management. I don't know for sure if
there is a need for GC in GCC at all.
Cyclone has a roots not only in C, but also ML. Some techniques like
pattern matching, aggregates, variadic arrays, tuples looks to be more
appropriate here than their C++'s metaprogrammed template analogues.
I'm just trying to be constructive.
Compilation is IMHO a task for functional PLs, and ML heritage is a plus.
Cyclone's current implementation compiles into C, so there will be no
bootstrapping problem as soon as there are C output in the tarballs.
Complexity of porting existing code base to C++ is comparable to one of
porting it to Cyclone (in contrast to moving it to a functional PL).
--
If you want to get to the top, you have to start at the bottom
More information about the Gcc
mailing list