I've just about got the DMD frontend compiling with VC++ .NET. (with stubbed out backend)  If anyone cares and would like the changes, drop me a line at seanpalmer@directvinternet.com

By far the biggest issues so far have been:

* many many missing #include directives
* no interface to the backend was provided by Walter, so I had to reverse
engineer one just so I could see if the thing would compile.  This would be
very handy because I had to invent a couple flag type names and I'm not sure
they'll match the real backend.
* long long -> __int64 BS (not completely solvable with just typedefs as the
damned printf format specifications are different too (%lld -> %i64d,
%llu -> %i64u) and so is the int literal syntax (1LL -> 1I64, 1ULL ->
1UI64).  Why M$ doesn't support long long I'll never know.  gcc sure won't
support __int64 and kin.
* complex_t isn't all that compatible with std::complex<long double>
* enumerations do not have |= or &= operators

Sean

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq5d03$1ou7$1@digitaldaemon.com...
> I've just about got the DMD frontend compiling with VC++ .NET. (with
stubbed
> out backend)  If anyone cares and would like the changes, drop me a line
at
> seanpalmer@directvinternet.com
>
> By far the biggest issues so far have been:
>
> * many many missing #include directives

??

> * no interface to the backend was provided by Walter, so I had to reverse engineer one just so I could see if the thing would compile.  This would
be
> very handy because I had to invent a couple flag type names and I'm not
sure
> they'll match the real backend.
> * long long -> __int64 BS (not completely solvable with just typedefs as
the
> damned printf format specifications are different too (%lld -> %i64d, %llu -> %i64u) and so is the int literal syntax (1LL -> 1I64, 1ULL -> 1UI64).  Why M$ doesn't support long long I'll never know.  gcc sure won't support __int64 and kin.

I should do a typedef.

> * complex_t isn't all that compatible with std::complex<long double>

It's more compatible with C99, Microsoft has no announced intention to support C99 that I've seen.

> * enumerations do not have |= or &= operators

?

"Walter" <walter@digitalmars.com> wrote in message news:aq6asn$2nkr$2@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq5d03$1ou7$1@digitaldaemon.com...
> > I've just about got the DMD frontend compiling with VC++ .NET. (with
> stubbed
> > out backend)  If anyone cares and would like the changes, drop me a line
> at
> > seanpalmer@directvinternet.com
> >
> > By far the biggest issues so far have been:
> >
> > * many many missing #include directives
>
> ??

Yeah, I was surprised by that too.  Not sure what might have gone wrong there.  But almost every file needed about 5 or so extra #includes to get it working.  Usually "mars.h", "declaration.h", "expression.h", "statement.h", "aggregate.h", "lexer.h".  Maybe you had a precompiled header or something. It's possible that I botched something too.  Also I had to make an Id class. "root.h" was referred to sometimes with explicit relative path, sometimes without.  I got about half done stubbing out the backend;  fairly painful. Only one or two files don't compile now.

> > * no interface to the backend was provided by Walter, so I had to
reverse
> > engineer one just so I could see if the thing would compile.  This would
> be
> > very handy because I had to invent a couple flag type names and I'm not
> sure
> > they'll match the real backend.

No comment on this one?

> > * long long -> __int64 BS (not completely solvable with just typedefs as
> the
> > damned printf format specifications are different too (%lld -> %i64d, %llu -> %i64u) and so is the int literal syntax (1LL -> 1I64, 1ULL -> 1UI64).  Why M$ doesn't support long long I'll never know.  gcc sure
won't
> > support __int64 and kin.
>
> I should do a typedef.

There are at least two sets of typedefs already.  They're just not used consistently.  Like I said it still won't help with the literal syntax or printf format specifiers.

> > * complex_t isn't all that compatible with std::complex<long double>
>
> It's more compatible with C99, Microsoft has no announced intention to support C99 that I've seen.

I'm sure Digital Mars' complex support is nice, but I didn't have that.  ;) std::complex<T> was available.  It's either that or write my own.

> > * enumerations do not have |= or &= operators
>
> ?

I'm not sure if it's standard, but VC sure doesn't provide them.  You should declare variables as int, not enum, if you want to mask enum flags.  I think some of the problem might be the way I stubbed the backend;  I am going to revisit that and see if I can't do it better.

Sean

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq7rl5$16rd$1@digitaldaemon.com...
>Also I had to make an Id class.

Check out idgen.c, that should build it.

Well that's handy to know.  <doh!>  I forgot you used this kind of source-writing program.  Wasn't looking for it.

Case in point:  idgen.c produces an id.h which needs #include "identifier.h", and id.c which needs #include "lexer.h"

One more thing:  VC++ will not compile *.c as C++.  They have to be named *.cpp, *.cc, or *.cxx.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aq90ir$2i23$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq7rl5$16rd$1@digitaldaemon.com...
> >Also I had to make an Id class.
>
> Check out idgen.c, that should build it.

Sean L. Palmer wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:aq6asn$2nkr$2@digitaldaemon.com...
> 
>>"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message
>>news:aq5d03$1ou7$1@digitaldaemon.com...
>>
>>>I've just about got the DMD frontend compiling with VC++ .NET. (with
>>
>>stubbed
>>
>>>out backend)  If anyone cares and would like the changes, drop me a line
>>
>>at
>>
>>>seanpalmer@directvinternet.com
>>>
>>>By far the biggest issues so far have been:
>>>
>>>* many many missing #include directives
>>
>>??
> 
> Yeah, I was surprised by that too.  Not sure what might have gone wrong
> there.  But almost every file needed about 5 or so extra #includes to get it
> working.  Usually "mars.h", "declaration.h", "expression.h", "statement.h",
> "aggregate.h", "lexer.h".  Maybe you had a precompiled header or something.
> It's possible that I botched something too.  Also I had to make an Id class.
> "root.h" was referred to sometimes with explicit relative path, sometimes
> without.  I got about half done stubbing out the backend;  fairly painful.
> Only one or two files don't compile now.

Walter has his compilation setup so that it includes "total.h" at the beginning of every file.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq93lt$2l6f$1@digitaldaemon.com...
> One more thing:  VC++ will not compile *.c as C++.  They have to be named *.cpp, *.cc, or *.cxx.

Doesn't VC have a switch for that?

That explains alot.  ;)

I may have to scrap this port and start over.

Sean

P.S. I hate porting C++.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:aq9dkr$2v8j$1@digitaldaemon.com...
> Walter has his compilation setup so that it includes "total.h" at the beginning of every file.

Not to my knowledge, though I haven't ever needed to look for it before now. This is definitely one of those things C++ should have standardized imho. Why would you name your file *.c when it contains C++ code?  Depending overly on compiler switches seems shortsighted.  The de-facto standard is definitely *.cpp, for good or ill.  *Every* compiler supports *.cpp.  I'm sticking with that.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aqbmi9$2a3n$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aq93lt$2l6f$1@digitaldaemon.com...
> > One more thing:  VC++ will not compile *.c as C++.  They have to be
named
> > *.cpp, *.cc, or *.cxx.
>
> Doesn't VC have a switch for that?

Hi,

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:aqd6mr$p38$1@digitaldaemon.com...

> Not to my knowledge, though I haven't ever needed to look for it before
now.

I bet you have found the switch by now: "/TP".

> This is definitely one of those things C++ should have standardized imho.

A language definition should not contain platform specific issues such as dependencies of the file system. Note that the C++ standard works equally well on platforms that does not support file extensions.

Regards,
Martin M. Pedersen