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