[m-dev.] Remove managed C++ support from Mercury

[Peter Ross]

On Tue, Oct 07, 2003 at 12:15:51AM +1000, Fergus Henderson wrote:
> On 06-Oct-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > I've just tried to use the .NET grades with v1.1 of the framework and it
> > no longer compiles anymore and every error that I have gotten so far is
> > due to the Managed C++ stuff.
> >
> > I suggest that we start to phase out the support for MC++ directly in
> > Mercury as it has always been the most brittle part of the .NET
> > implementation.
> 
> I'm not sure that it's fair to describe the MC++ support as "brittle".
> Are the problems that you are encountering due to bugs in the Mercury
> compiler's MC++ support, bugs in MC++ itself, changes in MC++,
> or merely due to changes in the .NET Framework library that this MC++
> code is using?
> 
> If, as I suspect, it is the last of these, then it would be wrong to
> describe the problem as being due to the "brittleness" of the MC++ support.
> 
The two problems I have encountered so far are:
    * runtime/mercury_mcpp.cpp no longer compiles, I get the link error
        LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol
          _main referenced in function _mainCRTStartup
        mercury_mcpp.dll : fatal error LNK1120: 1 unresolved externals
    * one needs to place public keywords on enums and structs
      which previously didn't need it.

So as you can see the problems so far have been to do with the MC++
compiler itself changing.

In my experience, we've had the most problems generating MC++ code which
was in an acceptable format for the MC++ compiler to consume.  It is
quite often very difficult to work out why the MC++ code isn't correct.

There is also a third problem that Zoltans recent change to make
io__stream a foreign_type.  This foreign type is
"class [mscorlib]System.Object[]" and the Mercury compiler doesn't
generate correct MC++ code for foreign types which are arrays. 

So in this case the problem is with the Mercury compiler itself not
supporting foreign types which are arrays in MC++.


> > As a start, I will attempt to remove all the managed C++ dependencies
> > inside the Mercury compiler.
> > 
> > This would also improve the situation in that this would also move us
> > one step closer to porting the Mercury compiler to work with mono, where
> > there is only a C# compiler available.
> 
> I would be very happy to convert all of the code in the Mercury standard
> library which uses MC++ foreign code to instead use C# foreign code.
> However, I would be very unhappy to drop the support for MC++ foreign
> code in the Mercury compiler.

It is, of course, possible to leave the support in the compiler.
However in my experience embedding MC++ in Mercury is difficult and
error-prone, while the C# embedding has rarely been problematic.

There should be no reason why this is so as both languages are meant to
be equally as .NET integrated.

I don't mind leaving it in, but I think that we would save ourselves and
our users a lot of grief by not allowing MC++ to be directly embedded
into Mercury.  If a user needs to use some of the features of MC++ they
can still write an assembly that does what they want and it can still be
consumed from Mercury.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------