Re: Non-C bindings in GNOME

[Murray Cumming <murrayc usa net>]

On Sun, 2002-08-18 at 18:27, Miguel de Icaza wrote:
> Lets take an extreme example to illustrate this: Scheme macros are not
> part of the CLS, because that would force every language implementor to
> understand these concepts, which might not only be very hard to
> implement, but might not make a lot for a user of another language. 

Yes, like I said a CLR for all languages is probably not possible.

> Same applies for example to a C++ template: you would not want to force
> every programming language to understand templates and be a producer and
> a consumer of them.

Templates are probably not a good example because they are more of a
compile-time feature than a runtime feature, though it's not that
simple.
 
> So hence, the CLS subset. 
>  
> C++ can be a consumer and a producer.  But when you produce code to be
> consumed by other languages, you are subject to a number of restrictions
> imposed by the CLS specification (the compiler will sometimes report a
> warning, and sometimes report an error).  
> 
> These restrictions are not only applied to the C++ language, they also
> apply to C# itself (the language of choice for the .NET Framework) and
> every other CLS producer 

MS created a language just for the CLR, which included stuff that the
CLR didn't allow?

> But for your internal code (or for classes which are not CLS compliant),
> you can do anything you feel like doing (C++ templates, C# boxed value
> types, Lisp macros, Eiffel/C++ multiple inheritance and what not). 

I didn't know that internal implementations could be in full C++. But
still
-  It's a major problem that full C++ can't be used in APIs. For
instance, I can't use std::string in a CLR API that's implemented in
C++.
- I doubt that the .NET environment will be always allow this
"untrusted" code.
 
> So you can think of the CLS subset as a contract that various languages
> can consume and use (along the lines of a CORBA IDL definition for
> example).
> 
> So Managed C++ provides the features to expose APIs to .NET and to
> consume APIs from .NET.  

This is all interesting, but I don't think you've said whether CLR APIs
can be used in regular C++. For instance

- A CLR API would tend to use attributes, and I'd need to use C++
extensions to access them.
- CLR objects have a simpler java-like memory model. Can I use normal
C++ memory management with them?
- Can I use a CLR type as a template argument? 

I know that i have the choice of using or not using those extensions,
but isn't my choice removed as soon as I need to use an API which
demands those extensions?
 
-- 
Murray Cumming
murrayc usa net
www.murrayc.com