Re: Non-C bindings in GNOME

[Miguel de Icaza <miguel ximian com>]

Hello,

    Murray, I think you are confusing two different pieces:

 	CLR: The Common Language Runtime.
	CLS: The Common Language Specification.

    The first is the virtual machine that offers the services to run any
kind of programming language and use any features from your language as
you see fit.  The later is a specification for interoperability.

    The CLR will let you run a program that has components written in
multiple languages.  For instance, Visual Studio.NET has chunks written
in C++ and chunks written in C# and chunks written by third-party
vendors in other random languages.

    The CLS on the other hand is a set of *conventions* that allow
languages to produce APIs that are easily reusable by other programming
languages.  And the keyword here is *easily*.  

    That does not meant that you can not interop with other languages
with other features, its just not on the agreed contract for interop.  

    Example: the next version of C# will support templates, and it will
be possible to define templates in C++, C# or F# and consume it in any
of those languages, but Scheme, JavaScript and Basic will not likely get
support for templates ever. 

> 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.

The CLR has been designed to host any language on it. 

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

Again, CLR != CLS.


> 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++.

That is correct.  

If you did this, then every language on the CLR would have to understand
std::string.  For public APIs on the CLR, use the type `String'.

> - I doubt that the .NET environment will be always allow this
> "untrusted" code.

I do not know what you mean here. 


> 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.

Yes, you can use CLR APIs from C++, they look like namespaced methods in
classes:

quack$ cat hello.cpp
#using <mscorlib.dll>

void main ()
{
	System::Console::WriteLine ("hello .NET");
}


> - CLR objects have a simpler java-like memory model. Can I use normal
> C++ memory management with them?

I do not understand your question.

Do you mean things like: can you take the address of it?  yes, you can. 
you can poke inside them if you want (see next sample).

> - Can I use a CLR type as a template argument? 

Yes (I had to learn to use templates to write this up.  So my example
sucks, but you get the idea):

#using <mscorlib.dll>
#include <stdio.h>

template <class X>
int len (X a) {
        return a->Length;
}

main ()
{
        System::String *a = new System::String ("hello");
	void *p = &a;

        printf ("Len: %d\n", len (a));
	printf ("ptr: %p\n", p);
}

Upon execution I get:
Len: 5
ptr: 0012F7AC

> 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?

Think of the .NET APIs just like another API.  Just like you think of
the `libc' API.  No matter how much you want to some nice C++ gadget,
the close(2) system call will impose its will on you: it will always
take an int, and it will always return an int.  

Miguel.