Clarifications on the array template, and some about the CLR namespaces

Garrett returns with some observations:

Damn Cool. My only reservation is that it doens’t *resemble* a native array, but that’s ok too 🙂   In some ways that is far better than the alternative. I was never quite thrilled about the cryptic nature of managed arrays before.

Yeah, us either.  That’s why we did it. 🙂

Is then the syntax for a managed array of managed objects:
array<Object^>^ array = gcnew array<Object^>(10); ?

Otherwise, I would assume that if you didn’t need the ^ inside the <> you wouldn’t be prepared for native garbage collected types in a post Whidby release.

Yup, you hit the nail on the head.  I only showed value types, for simplicity’s sake, but ref types you’ll also want to be able to put in a managed array.  And yes, the syntax you’ve provided is correct.  If you want a size 10 array of managed strings, you do array<String^>^ strarr = gcnew array<String^>(10);.

And your reasoning seems valid, too.  It is worth pointing out that you can also do managed arrays of native pointers to native types:  class A{};  array<A*>^ arr = gcnew array<A*>(10);.  I’ll let you fill in the blanks as to where we can take that post-Whidbey.

Garrett also asks:

I notice that the namespace using went from
   #using <mscorlib.dll>
   using namespace System;
   using namespace stdcli::language;
Is there a new “mapping” of namespaces going on here? Is the “System” namespace replaced with “stdcli::language” ?

No, and its totally my fault for not explaining what was going on.  This is why you should never rush blog posts, people! 🙂

First, why the #using <mscorlib.dll> disappeared.  In Managed Extensions, you compile with /clr, and then are required to put the #using at the start of every file.  When doing Whidbey C++, we realized that if we’re requiring it at the start of every file, we could just put it in for you, so we did.

Second, about the namespaces.  The System namespace still exists, and is quite vital.  A lot of stuff is under that namespace.  But in my example, I didn’t use anything from that namespace (except for the one System::Console::WriteLine, which you’ll notice was fully qualified).  Its the array type that is in the stdcli::language namespace, along with a few other types (pin_ptr and interior_ptr, which I’ll talk about at a later date).

The justification for putting the array type in that namespace is pretty straightforward: people have array as an identifier all over the place.  We simply couldn’t make it a general keyword and break them.  So, we put it inside a namespace.   That way, you could have array as an identifier, and then fully qualify the stdcli::language::array type when you wanted to use it.  Or, if you were writing a new program, or knew you had no instances of an identifier named array, you could just do a using on the namespace safely.

If you ever wonder about why the language design team made a choice they made, you can almost always be certain the reason is because they didn’t want to break existing users.  They make every effort not to.

Comments (1)

  1. Garrett Serack says:

    I always wondered about the need for #using <mscorlib.dll> everywhere. I always thought that since the dawn of C you needed to include things like stdio anyway, that everyone just figured that we wouldn’t mind. I’m very glad that design decisions like this are being made.

    You mentioned:

    class A{}; array<A>^ arr = gcnew array<A>(10);.


    Are you saying that whidbey will support this? What is it doing to the native pointer? Boxing?

    As an aside, one of my developers has brought a concern with moving large sums of text between Managed and Umanaged code. If the source text is in a CLR String, and we want to pass(even read-only) to unmanaged code, it appears that there is no way to get a pointer to the String’s buffer directly. We have to use the marshalling stuff to get it there, which in itself makes a copy.

    Given that one of managed C++ and CLI/C++ ‘s goals (imnsho) is to facilitate leveraging existing native c++ code, has any thought been given to this?


Skip to main content