[rdnzl-devel] C++/CLI (Was: "C++/CLR")

Edi Weitz edi at agharta.de
Sun Feb 19 09:39:03 UTC 2006


On Sat, 18 Feb 2006 20:24:21 -0500, "Dan Muller" <s8ctxw402 at sneakemail.com> wrote:

> Good news, sort of. I found out that you can use the /MD
> (Multi-Threaded DLL) switch instead of /MT (Multi-Threaded). At
> least, it compiles. The downside is that the file MSVCR80.DLL must
> be available at run-time.

I googled a bit and found this here:

  Affected User Scenario:
  Users will need to replace /MT with /MD for their code targeting
  .NET

  Description:
  There is no support in the CRT for statically linking managed
  applications.

  Customer Workaround:
  Customer needs to change /MT to /MD and link dynamically to the CRT.

  Rationale:
  There is no support in the C Runtime Library to statically link to a
  managed application.  All managed applications have to be
  dynamically linked; thus the reason to make the two compiler options
  conflict.

  <http://www.codeproject.com/managedcpp/WhidbeyBreakingChanges.asp>

> I've looked fairly extensively at C++/CLI while studying the
> possibility of porting some C++ code at my day job. Syntactically,
> it's a vast improvement over Managed C++. If you ever decide you'd
> like to port RDNZL to it, let me know. Schedule permitting, I'd be
> glad to help, or even just do it for you -- it's not a very large
> project.

Thanks for offering!  I might try it myself, but most likely not
before April.  Feel free to work on it... :)

>>> ;; This approach doesn't work
>>> ;(import-types "ClassLibrary1")
>>
>>   (import-types "ClassLibrary1" "Class1")
>>
>> works for me if the DLL is in the LispWorks folder.
>
> I haven't had time to figure this out yet. I did have the DLL there,
> otherwise it wouldn't have loaded the other way.

Hmm, so you didn't provide any types to import.  If you didn't get an
error message, it means the assembly was loaded but with zero types
imported.

Cheers,
Edi.



More information about the rdnzl-devel mailing list