On Mar 5, 2013 6:56 AM, "Daniel Murphy" <yebbl...@nospamgmail.com> wrote: > > "David Nadlinger" <s...@klickverbot.at> wrote in message > news:tbfgbhevqojgnawnx...@forum.dlang.org... > > > > Second, rewriting all of *LDC's* code in D would be a huge task, as the > > use of C++ templates is pervasive through the LLVM C++ API (even if they > > are used pretty judiciously), and the LLVM C API is a lot less powerful in > > some aspects. Thus, care should be taken that the D frontend can actually > > be used with some of the virtual method implementations still in C++ (e.g. > > toElem/toElemDtor and similar LDC-specific ones). > > > > Your (Andrei's) initial post sounded like this would be the case. But if I > > interpreted some of the posts correctly, Daniel Murphy has an automatic > > translator in the works for porting over the whole compiler (except for > > the backend) at once, which might be a problem for LDC. > > > > David > > I think we can solve this, but it's a lot of work. > > 1. Refactor the glue layer to use a proper visitor pattern > 2. Implement extern(C++) classes (where > https://github.com/D-Programming-Language/dmd/pull/644 was supposed to be > headed) > > This should allow us to have the dmd glue layer written in D, with the > ldc/gdc glue layers written in c++. > > It would require all three glue layers to be refactored together, but I > don't see a way to avoid this. Hopefully we can get rid of most of the > gdc/ldc specific frontend patches along the way. > > What do you and Iain think about this approach? > >
I think C++ classes would be more ill to implement than what I see initially in that link. Mangling is another problem as well. I've seen differing C++ compilers have subtle differences. I'll try to find one discrepancy between D and g++. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
