www.digitalmars.com         C & C++   DMDScript  

D - VC++

reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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
Nov 04 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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
?
Nov 04 2002
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
"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
Nov 04 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Nov 05 2002
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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.
Nov 05 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Nov 06 2002
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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?
Nov 07 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
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
Nov 07 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Nov 05 2002
parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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.
Nov 07 2002