On 2013-03-11 18:36, Iain Buclaw wrote:
> (The D conversion seems to think it's lisp).

(LOL)

On 03/03/2013 08:34 PM, Dicebot wrote:
>
>I'd argue that at least templates should not require
> run-time stuff at all.

Templates do not require any runtime support.

"Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.357.1363023395.14496.digitalmars-d@puremagic.com...
>
> (The D conversion seems to think it's lisp).
>

    Expression resolveLoc(Loc loc, Scope sc)
    {
    tracein("resolveLoc");
    scope(success) traceout("resolveLoc");
    scope(failure) traceerr("resolveLoc");
    {
        FuncDeclaration fd;
        if (sc.callsc && sc.callsc.func)
        fd = sc.callsc.func;
         else fd = sc.func;
        const(char)* s;
        if (fd)
        {
            const(char)* funcStr = fd.Dsymbol.toPrettyChars();
            HdrGenState hgs;
            OutBuffer buf = new OutBuffer();
            functionToCBuffer2(cast(TypeFunction)fd.type, buf, &hgs, 0,
funcStr);
            buf.writebyte(0);
            s = cast(const(char)*)buf.extractData();
        }
         else {
            s = "";
        }
        Expression e = new StringExp(loc, cast(char*)s);
        e = e.semantic(sc);
        e = e.castTo(sc, type);
        return e;
    }
    }

Am 12.03.2013 03:25, schrieb Daniel Murphy:
> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message
> news:mailman.357.1363023395.14496.digitalmars-d@puremagic.com...
>>
>> (The D conversion seems to think it's lisp).
>>
>
>      Expression resolveLoc(Loc loc, Scope sc)
>      {
>      tracein("resolveLoc");
>      scope(success) traceout("resolveLoc");
>      scope(failure) traceerr("resolveLoc");
>      {
>          FuncDeclaration fd;
>          if (sc.callsc && sc.callsc.func)
>          fd = sc.callsc.func;
>           else fd = sc.func;
>          const(char)* s;
>          if (fd)
>          {
>              const(char)* funcStr = fd.Dsymbol.toPrettyChars();
>              HdrGenState hgs;
>              OutBuffer buf = new OutBuffer();
>              functionToCBuffer2(cast(TypeFunction)fd.type, buf, &hgs, 0,
> funcStr);
>              buf.writebyte(0);
>              s = cast(const(char)*)buf.extractData();
>          }
>           else {
>              s = "";
>          }
>          Expression e = new StringExp(loc, cast(char*)s);
>          e = e.semantic(sc);
>          e = e.castTo(sc, type);
>          return e;
>      }
>      }
>
>

looks not that bad - the big question for me is - do you think that this could be the way to do the port (or do you just "test" how far you can get with automated conversion)

"dennis luehring" <dl.soluz@gmx.net> wrote in message news:khmgep$1a6s$1@digitalmars.com...
>
> looks not that bad - the big question for me is - do you think that this could be the way to do the port (or do you just "test" how far you can get with automated conversion)

This is the way.

With automatic conversion, development can continue on the C++ frontend until the D version is ready to become _the_ frontend.

The C++ code needs a lot of cleanup.

On 12 March 2013 02:25, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.357.1363023395.14496.digitalmars-d@puremagic.com...
> >
> > (The D conversion seems to think it's lisp).
> >
>
>     Expression resolveLoc(Loc loc, Scope sc)
>     {
>     tracein("resolveLoc");
>     scope(success) traceout("resolveLoc");
>     scope(failure) traceerr("resolveLoc");
>     {
>         FuncDeclaration fd;
>         if (sc.callsc && sc.callsc.func)
>         fd = sc.callsc.func;
>          else fd = sc.func;
>         const(char)* s;
>         if (fd)
>         {
>             const(char)* funcStr = fd.Dsymbol.toPrettyChars();
>             HdrGenState hgs;
>             OutBuffer buf = new OutBuffer();
>             functionToCBuffer2(cast(TypeFunction)fd.type, buf, &hgs, 0,
> funcStr);
>             buf.writebyte(0);
>             s = cast(const(char)*)buf.extractData();
>         }
>          else {
>             s = "";
>         }
>         Expression e = new StringExp(loc, cast(char*)s);
>         e = e.semantic(sc);
>         e = e.castTo(sc, type);
>         return e;
>     }
>     }
>
>
>

Yes, I know it can be cleaned up.  Just thought I might chime in on a point I thought was amusing.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:mailman.373.1363091214.14496.digitalmars-d@puremagic.com...
> On 12 March 2013 02:25, Daniel Murphy <yebblies@nospamgmail.com> wrote:
>
>>
>
> Yes, I know it can be cleaned up.  Just thought I might chime in on a
> point
> I thought was amusing.
>

I know.  Your remark inspired me to clean it up!

Am 12.03.2013 10:59, schrieb Daniel Murphy:
> "dennis luehring" <dl.soluz@gmx.net> wrote in message
> news:khmgep$1a6s$1@digitalmars.com...
>>
>> looks not that bad - the big question for me is - do you think that this
>> could be the way to do the port (or do you just "test" how far you can get
>> with automated conversion)
>
> This is the way.
>
> With automatic conversion, development can continue on the C++ frontend
> until the D version is ready to become _the_ frontend.
>
> The C++ code needs a lot of cleanup.
>

maybe it will get near perfection :) and become an standard tool like htod

"dennis luehring" <dl.soluz@gmx.net> wrote in message news:khnbps$31c5$1@digitalmars.com...
> Am 12.03.2013 10:59, schrieb Daniel Murphy:
>> "dennis luehring" <dl.soluz@gmx.net> wrote in message news:khmgep$1a6s$1@digitalmars.com...
>>>
>>> looks not that bad - the big question for me is - do you think that this
>>> could be the way to do the port (or do you just "test" how far you can
>>> get
>>> with automated conversion)
>>
>> This is the way.
>>
>> With automatic conversion, development can continue on the C++ frontend until the D version is ready to become _the_ frontend.
>>
>> The C++ code needs a lot of cleanup.
>>
>
> maybe it will get near perfection :) and become an standard tool like htod
>

Unfortunately it only works because it can make a lot of assumptions about the dmd source, and the subset of C++ it uses.  The same approach can be used with other C++ projects, but not the same tool.

On Tuesday, 12 March 2013 at 14:32:05 UTC, Daniel Murphy wrote:
> Unfortunately it only works because it can make a lot of assumptions about
> the dmd source, and the subset of C++ it uses.  The same approach can be
> used with other C++ projects, but not the same tool.

Visual D comes with a "C++ to D" conversion wizard (also usable as a stand-alone command-line tool):
http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion