So, here's the problem.

            throw "fritz";

what does the compiler do? it has to set everything up at compile-time, then it actually gets handled by a run-time library that makes use of a limited form of type reflection to figure the kind of object having been thrown.

there's no context, really. we don't know if the person is going to catch x, y, or z, so we can't know what to throw in any particular instance. this is all set up at compile-time.

Now, here is the rub:

          void f()

           {

                     try { g(); }

                     catch ( String^ s ) {}

                     catch ( const char* pcs ) {}

            }

            void g()

             {

                     throw "fritz";

              }

What gets caught? what an impossible question. one could argue if we are compiling for the CLR, then String^ should match, and if we are in native, and so on. But there's no reason to believe that just because we are compiling for the CLR, people are using String and not just const char*.

So, a string literal is thrown as a type const char*, not as String^.  My first reaction was, gosh, that's terrible. Then, I thought, what am I thinking? It seems a very small matter. It's not even something I would run into since I don't throw anything but class objects. I just add it for completeness.

I think if this bothers you, then you are bothered by our entire effort. Just as a sounding. That is, not everybody is happy with our work on C++/CLI. There are some folks out there that feel concern that we are somehow messing with their language, and we shouldn't be allowed to do that.

we aren't doing it that way at all. We have really wanted to be good c++ citizens while being excellent Microsoft employees. I have never felt any pressure to compromise either while I have been here. We have had an extraordinary degree of freedom not simply in our design, but in our being able to reach out and work with the general c++ community. this language is a coalition. I think we have all wanted to put the best face on C++ in what we regard as an otherwise hostile environment for C++. We think this is a win-win situation for everyone. if you don't like something, you should let us know. we're not a hundred thousand leagues removed from our users. if you want to use the language, you have every right to tell us what you think about it; how you find it; what you want. if you make a good case for it, I think it could be done. that's just my opinion. but I think we have an opportunity to together as a C++ community put forth C++ in an otherwise hostile environment that for some unbelievable reason thinks C# or Java comes anywhere near being as good a language. I don't understand it. It's not a question of knocking those languages. They took so much from C++ -- it's not hard, after all the hard stuff was worked out, to go back and clean it up. sure. C++ is messy. it was real hard to do. it was getting done while we were using it. we didn't know where it was going. Bjarne was implementing it, using it, it became the tool we all used to make our living. we wanted it to be the best possible language for programmers. at least I did. I don't have a philosophy. I don't make standards. I just program and write. and I do that best in C++. C# and Java mean nothing to me. Now I have my own language to use on .NET. That was my personal agenda in all this. I think you should check it out.

it was a great adventure. I find C++/CLI is something interesting again about C++ for me anyway. I'm not a fan of standards. I've never finally been involved in one. It's making a language that interests me, not in clean-up and all that necessary stuff for real-world production. I don't have the head for that.

so, I just wanted to make a personal statement. I have watched the team here for almost 3 years. I worked with them sometimes. I snarled at them sometimes. I was fed up with them once or twice. and yet they have produced something really wonderful in my opinion, and it is much better than I had dared imagine. I just love it. I can't wait to program with it – I'd like to drop everything and just start. this is exactly what I have been waiting for. to have a language to program .net. we didn't have one before.

C++/CLI is a entry visa nto what I call 3-dimensional programming. The CLR gives you the run-time as an entity to query, to modify, to almost in a sense be alive in. everything in a native program has to be done at compile-time. that is way too early for me to know exactly what needs to be done in many interesting environments. can't I wait? I'm not that performance critical that I need the machine.

my first analogy was going to be between the traditional Disney animation and the Pixar CGI, but I think a better analogy is between an instinct and a decision. that is, an instinct is the trigger of a built-in behavior that is insulated from and unaffected by the environment. a decision considers the environment (context) and memory (past behavior) in order to choose a best action. this is what is missing from native static programming. it really can't be smart enough for the kinds of problems we need to solve now in my estimate. I can't prove that.

I gave a talk at Disney Feature Animation a few months ago about C++/CLI, and a friend of mine who I love dearly, asked me, what do I need that for? he is in charge of plug-in 3D tools for Maya, a modeling toolkit for computer graphics. And he is right. But we need it I believe as a community going forward. and in that sense, we have opened that doorway for the C++ programmer. The worst case scenario was that the price of admission to this world was to have to renounce C++ -- I mean, mea culpa. we're such savages – we worry about performance, we break the type system, we make use of the underlying machine, we don't follow enough rules. we're loose cannons. Can't have loose cannons. I personally didn't want to accept that as being a true statement.

But you cannot argue something like that. I can't say, hypothetically, C++ can be as good a language under .NET as Java or C#. Nobody would hear that – they would just see Lippman being defensive, or delusional. you have to demonstrate it. That's the only way to really convince people. That's the only way I can ever convince myself in fact. So, that is what C++/CLI means to me.

I know Bjarne has his reservations and dislikes. Well, so do we all, if truth be told. But it's still just so wonderful overall. who cares if it's not perfect. I don't – I haven't gotten anything perfect, trust me. i don't know if it is better than this or that or the next thing. but it's really pretty good and i'm going to use it. and we really did it as a team.

public ref class R {

public:

  void foo( System::String^ ); // (1)

  void foo( std::string );     // (2)

  void foo( const char* );     // (3)

};

void bar( R^ r )

{

  // which one?

  r->foo( "Pooh" );

}

In the original Managed Extensions for C++, the invocation of foo() within bar() resolved to (3), exactly the same as it does under ISO-C++. That is,

void bar( R^ r )

{

  // under Managed Extensions to C++, resolved to

  // void foo( const char* );

  r->foo( "Pooh" );

}

To briefly review: In ISO-C++, the type of "Pooh" is const char[5]. There is no exact match of "Pooh" to any of the three instances of foo(). However, the trivial conversion of const char[5] to const char* represents a best match, and this is why (3) is invoked. There was no built-in notion of a string literal having any relationship to System::String.

And this was changed in the design of C++/CLI. Actually, it was changed twice, and that is the talking point of this entry – to explain why the initial change had to be further refined.

The overall effect of the change is to extend dual citizenship to a string literal compiled for the CLI. The initial change is described in my earlier entry entitled String Literals are now a Trivial Conversion to String. Here is a brief review of the issue.

The first question is, what is the exact type of "Pooh" within C++/CLI? One answer is, well, obviously, it is of type const char[5] – otherwise, it could not be compatible with ISO-C++. We can't change that.

The initial solution, therefore, was to introduce a new trivial conversion, that of a string literal to a System::String, that is of equal precedence with the trivial conversion of a string literal to const char*. This provides a somewhat elegant symmetry, but in practice results in a flurry of ambiguous calls. For example, under this design, the invocation of foo() now fails,

void bar( R^ r )

{

  // under interim C++/CLI, flagged as ambiguous

  // the following two candidate functions are equally good …

  //       void foo( System::String^ );

  //       void foo( const char* );

  r->foo( "Pooh" );

}

To disambiguate the call, the user would have to provide an explicit cast,

void bar( R^ r )

{

  // ok: void foo( System::String^ );

  r->foo( safe_cast<String^>( "Pooh" ));

}

In practice, in nearly every case, the C++/CLI programmer wished to have the String instance invoked in preference to the C-style string instance. And so giving equal precedence to both conversions was both a step forward (in recognizing the special relationship of a string literal to System::String under the CLI) and two steps back (the presence of the const char* argument in effect neutralized that relationship (first step back) and required an explicit cast to resolve (second step back) ).

So, we had to fix that. That is, under the CLI, we want a string literal to more closely be a kind of System::String than const char*. The question was, how could that be achieved without breaking ISO-C++ compatibility? How might you resolve that?

The insight to resolve this is to realize that the dual citizenship of a string literal applies to its fundamental type, not to its set of trivial conversions. In effect, under C++/CLI, the underlying type of a string literal such as "Pooh" is both const char[5] (its native inheritance) and System::String (its managed underlying unified type). Under C++/CLI, the string literal is an exact match to System::String and the trivial conversion to const char* is not considered. That is, under the revised C++/CLI language specification, the ambiguity has been resolved in favor of System::String,

void bar( R^ r )

{

  // ok: under current C++/CLI,

  //     void foo( System::String^ );

  r->foo( "Pooh" );

}

This reflects a fundamental difference between ISO-C++ and C++/CLI in their type systems. In ISO-C++, types are independent except when explicitly part of the same class inheritance hierarchy. Thus, there is no implicit type relationship between a string literal and the std::string class type, even though they share a common abstraction domain.

C++/CLI, on the other hand, supports a unified type system. Every type, including literal values, is implicitly a kind of Object. This is why we can call methods through a literal value or an object of the built-in types. The value 5 is of type Int32. The string literal is of type String. It just doesn't work to treat a string literal as either more like or equal to a C-Style string.

The integrated conversion hierarchy allows a working ISO-C++ program to continue to exhibit the same behavior when compiled for the CLI, while a new C++/CLI program exercising the CLI types reflects the new type priority of the string literal.

Most readers and programmers have little patience with this level of detail, and often point to discussions of C++ type conversions as evidence of its complexity. However, I don't think that is quite fair. The existence of these rules is necessary if one is to reach an intuitive language behavior and guarantee a uniform behavior across implementations. It is because the language generally behaves in a type-intuitive way that allows programmers in fact to ignore these details.

While the length of this discussion might seem disproportionate to the topic's importance, it strikes me as a canonical example of the extent to which we have had to work to integrate the CLI type system into the ISO-C++ semantic framework. This should also suggests certain good practices when a native class is being recast to a CLI class type. It is better, for example, to refashion the set of member functions accepting string literals rather than simply stirring in an additional String instance to our stew of overloaded functions, seasoning it to local taste.

void f( int ix )

{

    // explicit placement on the CLI heap

    int^ result = gcnew int( -1 );

    // exercise result …

    // implicit boxing of the integer value ix …

    Console::WriteLine( "{0} :: {1}", ix, result );

};

and (b) when it is contained within a reference type either as a member or as an element of a CLI array. For example,

public enum class Color

     { white, red, orange, yellow, green, blue, indigo, violet };

public value class Point

{

    Color m_color;

    float m_x, m_y;

    // …

};

public ref class Rectangle

{

    Point bottom_left;

    Point top_right;

    // …

};

void f( Point p )

{

    Rectangle  ^hit = gcnew Rectangle( -2, -2, 2, 2 );

    array<int> ^fib = gcnew int(8){ 1,1,2,3,5,8,13,21 };

    // …

}

In f(), we allocate two whole objects on the CLI heap, a Rectangle and an array of eight integer elements. The Rectangle object contains two interior value class Point members. These are located on the CLI heap as fixed offsets into the area allocated to the containing Rectangle. Within each Point are two floating point members and a Color member. These are also located on the CLI heap as fixed offsets into the two interior Point objects.

If the Rectangle object is relocated during a sweep of the garbage collector, all its interior members, of course, are relocated as well. The same is true with a CLI array. When the array is relocated, the addresses of each of its elements change as well. We cannot safely assign the address of any interior member or array element to a non-tracking pointer or reference. This isn't just a pitfall that we must learn to recognize and sidestep. Rather, the language disallows it. Our attempt results in a compile-time error. For example,

// error: cannot assign an interior member

//        to a non-tracking pointer …

Point *p_bl = hit->BottomLeft;

We need a form of tracking entity to hold the address of an interior member. What are some of the requirements on this entity? Well, one common pattern we felt necessary to support is that of an iterator – in particular when applied to the elements of a CLI array. For example,

void f( array<int> ^fib )

{

    SomeTrackingPointerNotation begin = &fib[0];

    SomeTrackingPointerNotation end = &fib[ fib->Length ];

    for ( ; begin != end; ++begin )

          // …

}

Our SomeTrackingPointerNotation needs to support pointer arithmetic. That is, when we write ++begin, this does not increment the address by 1, but rather by the size of the element type. For example, since array element are of type int, each increment must add sizeof(int) to the current address value.

Neither the tracking handle (^) nor its indirect cousin, the tracking reference (%), supports pointer arithmetic. Moreover, a tracking reference does not support pointer comparison, such as

begin != end

Like a native reference, a tracking reference, once initialized, serves as an alias to the underlying object to which it refers. The comparison is not of the two tracking addresses but of the values stored at those addresses. This is not the iterator semantics we need.

In a native design, we decide whether to go with a pointer or a reference declaration based on two primary factors:

(1)                  if the object we wish to refer to is unavailable at the time of declaration, then we must declare a pointer and set it to null. A reference requires an initial object.  So does a tracking reference.

(2)                  if we wish to refer to more than a single object during the lifetime of the declaration, then we must also declare a pointer. A reference cannot be reset to refer to a second or subsequent object. Neither can a tracking reference.

What this suggests is that we need an analogous choice when the constraints of a tracking reference make it ill-suited to our design. A third, more flexible form of tracking entity, the interior pointer (interior_ptr<>), is given over to this role. It can refer to no object (but only by setting it to nullptr, not 0). And it can be reset to refer to a second or subsequent object. Moreover, it supports both pointer arithmetic and pointer comparison. For example,

int sum( array<int> ^arr )

{

    if ( ! arr )

         return 0;

    interior_ptr<int> begin = nullptr;

    interior_ptr<int> end = &arr[ fib->Length ];

    int sum = arr[0];

    for ( begin = &arr[1]; begin != end; ++begin )

          sum += *begin;

    return sum;

}

The declaration of an interior pointer is limited to local objects, including function parameters and return types. If we don't provide an initial value, the compiler automatically inserts code to set it to nullptr – so the explicit initialization in the above example is not strictly necessary. The type specified within the template brackets identifies the kind of object addressed; we do not indicate a pointer within the brackets unless we intend two or more levels of indirection. For example,

public ref class Matrix sealed {

    float *m_mat;

public:

    property interior_ptr<float*> Mat

    {

        interior_ptr<float*> get(){ return &mp_mat; }

    }

    // …

};

http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/TransGuide.asp

Although there has been considerable effort made in correcting all errors within the text, I am sadly aware that how imperfect these pieces of mine nevertheless turn out. So, on the one hand, I believe this guide will prove valuable to those needing this information. On the other hand, I also believe there are areas that (a) could have been made clearer, and (b) details that … well, that are in error. If you do use this guide and find either (a) or (b) (or some (c), (d), or (e) not itemized), please let me know, either by a comment to this entry or by a private email.

Speaking of which – comments, that is. Due to the open nature of the internet, the providers of this site have found it necessary to provide a form of budget firewall – that is, they have put in place a facility to moderate the comments. This basically means that I see each comment before it becomes public, and it requires a click of my mouse in order for it to be published. I have not – not as yet, anyway – not published a comment; however, oddly enough, I can't prove that.

In any case, those of you whom have been reading this from the beginning will notice that patchwork pieces of the translation guide have been posted here in one form or another. Often, comments have helped me recognize shortcomings and recast material in a hopefully more comprehensible manner. For example, my treatment of deterministic finalization in the translation guide was considerably reworked to address some of the posted comments to the initial blog entry on that topic. As W.H.Auden said in a different context, a piece of writing is never finished, it is simply abandoned.

http://msdn.microsoft.com/visualc/?pull=/library/en-us/dnvs05/html/stl-netprimer.asp?frame=true

If for some reason, this doesn't show up in the post as a clickable link, you can just visit the visual c++ subportion of the msdn site at

 http://msdn.microsoft.com/visualc

and hopefully find a link to it there. In any case, the Visual C++ site, under the care and breeding of Brian Johnson and Ami Vora, has really been spiffed up with some very neat content and is worth a lookie-loo.

For the article, David Clark, who did a wonderful job editing the piece, asked me to come up with a summary limited to 200. I misread that as 200 words, and wrote the following. I then discovered to my chagrin that it referred to 200 characters, including white space. I thought, well, white space is without content, so if I remove that, I get perhaps another 75 characters to play with, but that doesn't actually work … In any case, here is the summary that had to be sliced mercilessly:

For the experienced programmer, the hardest part of moving to a new development platform such as .NET is often the absence of familiar tools through which she has honed her skills and on which she depends. For the experienced C++ programmer, one such essential toolkit is the Standard Template Library (STL), and its absence under .NET until now has been a significant disappointment. With Visual C++ 2005, we fix that by providing an STL.NET library. This article, the first in a series, provides a general overview of the STL program model using STL.NET – it discusses sequential and associative containers, the generic algorithms, and the iterator abstraction that binds the two, using plenty of program examples to illustrate each point. It begins by briefly considering the alterative container models available to the .NET programmer using C++ -- the existing System::Collections library, the new System::Collections::Generic library, and, of course, STL.NET. To provide for the widest readership, this article does not require familiarity with the STL library; however, it does presume some experience with the C++ programming language.

This summary, when reduced to 200 characters, plus the white space i threw back in, ended as follows:

With Visual C++ 2005, the Standard Template Library (STL) has been re-engineered to work under the .NET Framework. This article, the first in a series, provides a general tour of STL.NET.

Talk about a poor relative. In any case, this article is culled from a text I am writing on the C++ binding to the CLI, so if you have any concerns or comments or a content wish-list, please drop me a line.

(1) isn't the support for two mechanisms that are similar in intent but which differ in both gross and subtle semantic behavior confusing for a user?

(2) doesn't the dual nature of these constructs increase the liklihood of programmer error?

(3) isn't this a canonical illustration of the undisciplined nature of the C++ language design where everything but the kitchen sink seems to get thrown in? you guys just can't get your act together, can you?

Let's see what kind of answers I can offer. [Disclaimer: of course, these are my thoughts, and do not represent either the corporate views or policies of Microsoft.]

The C++ binding to the CLI which I refer to as C++/CLI represents an integration of two separate object models: the static object model of native C++ and the dynamic program model of the CLI. We've seen conflicts between these two models before – in particular between the native and CLI enum, the native and CLI array, and the native and CLI reference class.

Under the CLI object model, individual languages are – not to put too fine a point on it – somewhat diminished – much as how in a modern country, the individual states while soverign are constrained to the laws of the central authority. For example, the CLI defines the underlying type system within which a language operates, as well as the inheritance model. As we saw in an earlier blog, the CLI does not, for example, support private inheritance, value inheritance (that is, the inheritance of implementation but not of type), or multiple inheritance (MI). While a language can choose to support these aspects of inheritance, that support requires a mapping onto the existing CLI object model because there is no direct support.

The Eiffel language under CLI, for example, choose to provide an MI mapping because it felt that (a) MI is a valuable inheritance model, and (b) its users would be dimished without its support under the CLI – that is, it would give its users a dimished programming experience under the CLI than on native platforms, and this would likely deter them from migrating to the CLI itself – or at least of migrating to the CLI while continuing to exercise their Eiffel expertise and culture.

We did not feel the same imperative as Eiffel with regards to multiple inheritance. But we did feel that imperative towards deterministic finalization of reference types declared within a local block, and so we provided a mapping of a class destructor to a IDisposable::Dispose() method, which is the CLI pattern of reclaiming resources prior to garbage collection finalization. Similarly, we did feel the imperative towards automatic memberwise copy and initialization – as supported by a copy assignment operator and copy constructor – and so we provided a mapping. (But these mappings are constrained by the underlying CLI implementation. We could not map memberwise copy into a value class because we could not guarantee that it could be carried out in all circumstances – at least that is my understanding. I haven't myself verified that but taken it on faith.)

Again, we did this because without these mappings of essential aspects of the native C++ programming experience, we believe the C++ user would have a diminished experience of programming under the CLI than on the native platform, and that this would deter them from migrating to the CLI – or at least of migrating to the CLI while continuing to exercise their C++ expertise and culture. The template mechanism is another of the essential aspects of modern C++ programming. We believe its absence would represents a significant hole in quality of programmer life when using C++/CLI. Personally, that is my deep belief.

So, with regard to parameterized types, it felt imperative that we provide some mechanism beyond what was offerred by the System::Collections namespace. The first mechanim that naturally comes to mind to the C++ programmer, of course, is templates. But what about generics? Why couldn't C++/CLI use generics for containing the CLI types, and leave templates for the non-CLI types? Why map the template mechanism into C++/CLI to support the CLI reference class, value class, interface class, delegate, and function?

The honest answer is because we were left with no choice. One of the generic talking points in presentations, specifications, and hallway whispering, is that generics, while borrowing from C++ template, "does not suffer many of the complexities" of C++ templates.

What are considered as superfluous complexities of C++ templates and were therefore eliminated from the generic mechanism – partial template specialization, the ability to inherit from the type parameter, support for non-type and template type parameters, the ability to specialize either an entire or selected members of a template, and so on – are considered by professional C++ programmers and designers of the language as essential modern programming design patterns that are fundamental to existing production code and widely-used libraries, such as the STL, LOKI, and Boost.

The real problem is that although the C++ community and language designers and implementors have deep experience with parameterized types, that experience was not tapped while the design of generics were underway.

So, we did not have any choice but to provide support of templates for CLI types and to provide an STL.NET implementation. This is great stuff if you care about C++ and want to see it succeed under .NET. Except for performance issues, C++/CLI, in my biased opinion, is shaping up as the premier C++ experience available. Personally, I'm so keen on the new language that I'm planning to reimplement my mscfront translator into the C++/CLI code from native. I'll be reporting my progress on that in quite some detail in a series of blog entries once I get the C++/CLI text I'm working on in shape.  

So, that's why we have templates. Why did we also provide support for generics? Generics are deeply integrated into the CLI, and for that reason solve a number of problems left unsolved in C++ – in particular, the instantiation model. Because there is no concept of a runtime within native C++, there is no native concept of how a template is instantiated[1] – that is, when the binding of an actual parameter to the formal parameter occurs and to what extent. The work of the ISO committee in this area has not been stellar.

Generics provides a constraint mechanism, something whose absence is keenly felt in the template mechanism.[2] A generic type is recognized by the CIL – the intermediate language; a template class is not, and so template classes are not cross-language and, it turns out, not cross-assembly as well. That is to say, every serious CLI language has to provide generic support. And that is what we do. Perhaps if we had been participants in the design, the outcome could have been different. But that, to repeat my aunt's favorite refrain, is water under the bridge.

So, from my perspective, that is why we support both the template and generic solutions for parameterized types, and have tried to integrate them into a elegant symmetry.

I thought I would follow up on the issue of overload function resolution. And so this entry discusses how a candidate function list is built up. (I realize this is somewhat esoteric, but. Well, I hope someone finds it worth a spin around the page.)

The first question of course, is, what the heck is a candidate function list? Literally, a candidate function list is the set of functions sharing the same name visible at a call point. As we'll see, the complexity, when present, has to do with determining the actual set of visible functions.

It's always good to begin with a simple example – hopefully, if we can master this one, our confidence will surge, and we can march on to the question of namespace, qualified type names in the signature of a function, and the using declaration in general. Here is our example,

void f(); // (1)

void f( String^ ); // (2)

void f( const string& ); // (3)

void f( String^, array<String^>^ ); // (4)

int main( array<String^> ^args )

{

    if ( args == nullptr )

         handle_invalid_command_line();

    for each ( String^ s in args )

        f( s );

}

There are four candidate functions to the call of f() within main(). By inspection, we can see that only two of them are viable – that is, only the (2) and (3) instances can match the actual invocation. (And (2) is the best viable function.)

So that was simple. Things start getting somewhat more complicated if the type of a function argument is declared within a namespace. Let's first look at a fully qualified name. In this case, the functions within the namespace that have the same name as the called function are added to the set of candidate func­tions. For example:

namespace CLITypes

{    

public ref class C {…};

void takeC( C^ );

}

// …

void f( CLITypes::C^ cobj )

{        

    // ok: calls CLITypes::takeC( C^ )

    takeC( cobj );

}

There is no takeC() function declared within the global scope in which f() is defined. There is, as well, no using declaration opening up a namespace. So, on first glance, this appears to be an illegal invocation: the candidate set appears to be empty.

However, because the argument is qualified to occur within the CLITypes namespace, the functions declared within that namespace are considered as well. That is, the full set of candidate functions under this circumstance represents the union of the functions visible at the point of call and the functions declared within the namespaces of the argument types.

There are three general cases in which functions with the same name do not overload – at least currently. (There is some activity within the ECMA committee that hasn't jelled as yet one way or another – at least as far as I'm aware.)

1.      A derived class function that reuses the name of a base class virtual function overrides rather than overloads the base class instance. Except when the new slot modifier is applied, the derived class instance must conform to the signature of the base class function. It substitutes for the base class instance within the derived class virtual table.

2.      A derived class function that reuses the name of a non-virtual base class function hides rather than overloads the base class instance. The signatures of the base and derived class instance are not considered. This is because the overload candidate set for a function does not extend across scope boundaries. (This is the guy currently under siege, I believe.)

3.      A function declared within a local block hides rather than overloads all named instances of that function within the enclosing scopes for the extent of that block. This is the most esoteric of the three cases, so let me provide a quick example,

String^ Marshall( int ); // (1)

String^ g() {

{

    // these puppies hide global instance …

    String^ Marshall( double ); // (2)

    String^ Marshall( char* );  // (3)

    return Marshall( 1024 ); // resolves to (2)

}

In this example, the global instance of Marshall() is not visible within g(); the candidate functions are limited to the two declarations within g() itself. The char* instance is not a viable candidate function for an actual argument of 1024. This leaves us with instance (2) match the formal parameter of type double through a standard conversion although the global instance, if considered, represents an exact match.

The candidate functions also depend on the visibility of using declarations at the call point. This is because a using declaration opens up a namespace. For example,

namespace libs_R_us {

    int max( int, int );

    double max( double, double );

}

char max( char, char );

void func()

{

    // namespace functions not visible

    // the three calls resolve to global max( char, char )

    max( 4096, 8192 );

    max( 35.1, 35.9 );

    max( 'J', 'L' );

}

In this case, the only function visible is the function declared in global scope. It is therefore the only candidate function, and is the instance invoked by all three calls within func(). This results the loss of precision in both arithmetic invocations. We have two choices for correcting this, both of which make use of a using directive to open the namespace. The question is where we should place it.

One possibility is to place using declaration in global scope. For example,

char max( char, char );

using libs_R_us::max; // using declaration

All three instances of max() are now visible within the global scope and are placed in the set of candidate functions. The three invocations are now each an exact match to a separate instance, as follows,

void func()

{

    max( 4096, 8192 ); // libs_R_us::max(int,int);

    max( 35.1, 35.9);  // libs_R_us::max(double,double);

    max( 'J', 'L' );   // ::max( char, char );

}

Alternatively, we might choose to place the using declaration within the local scope of func(). Why would we do that? Primarily to limit the extent of the changes in our program due to the larger set of candidate functions. By adding to the candidate function set at global scope within an existing program, we are potentially changing the function invoked at each call point that does not involve an exact match. This may be a more invasive change than what we are ready to support. The alternative declaration looks as follows,

void func()

{

    // local using declaration

    using libs_R_us::max;

    // same function calls as above

}

Surprisingly, we get a different the set of candidate functions now. This is because using declara­tions nest.[1] With the using declaration in local scope, the global function is now hidden. The only visible functions at the call points are the two declared within the namespace, and so our character comparison resolves to the namespace instance max(int,int) through a promotion of the two character arguments.

There are two possible solutions to getting the three functions into the candidate set. We originally choose a nested using declaration in order to localize the inclusion of the functions to just the call points within func(). One solution, of course, is to move it back to global scope. But this opens the entire assembly to potential change. Alternatively, we can add the global instance to our nested set of declarations,

void func()

{

    // now we have all three in the candidate set

    using libs_R_us::max;

    extern char max( char, char );

    // same function calls as above

}

The set of candidate functions are therefore the union of the functions visible at the point of the call — including the functions introduced by using declarations and using directives — and the member functions declared in the namespaces associated with the types of the arguments. For example,

namespace basicLib {

      void print( String^ );

      void print( Object^ );

}

namespace matrixLib {

    public ref class Matrix { /* ... */ };

    void print( Matrix^ );

}

void display()

{

    using basicLib::print;

    matrixLib::Matrix ^mObj;

    print( mObj );      // matrixLib::print( Matrix^ )

    print( "literal" ); // basicLib::print( String^ )

    print( 1024 );      // basicLib::print( Object^ )

}

Which functions are the candidate functions for the call print(mObj)? The two basicLib functions introduced by the local using declaration are candidate functions because they are visible at the point of the call. Because the function call argument is of type matrixLib::Matrix, the print() function declared within the namespace matrixLib is also a candidate func­tion.

Once the candidate functions are identified, the next step – which begins to involve type checking – is to determine the viable functions within the candidate set. That topic is a candidate for a subsequent blog.

Sender: Slawomir Lisznianski
=====================================
1) Lack of support for SMFs makes value classes unnatural to use. An example in the C++/CLI spec at page 33 is incorrect, as it uses constructors with value classes. In fact, quite a few value class examples in the specification contradict with paragraph 21.4.1.

SMF, for the uninitiated, means special member functions, and in this case refers to the constraint on a value class that it cannot declare a default constructor, copy constructor, copy assignment operator, or destructor.

Mechanically, the reason these special member functions are not supported, I am told, is because there exists conditions during run-time in which it is not possible for the compiler to insert the appropriate invocations, and thus it is not possible to guarantee the semantics associated with these member functions. And so their support has been withdrawn completely. I suspect that the examples were written before the withdrawal of the default constructor, and the authors of the spec simply overlooked removing them.

There are a number of negative responses one can have to this: Disbelief, disgust, savage anger are a few that come to mind.

Another way of looking at this is to consider the why and when these special member functions are not required.  We do not need a copy constructor nor a copy operator when the aggregate type supports bitwise copy. Similarly, we do not need a destructor when the state of the aggregate type exhibits value semantics. Finally, if the runtime zeros out all state by default, then we do not require a default constructor. (In C++, primitive data types are not automatically zeroed out, and so most of our default constructor use – but granted, not all – is used to put the object in an uninitialized state.)

That is, a value type in the philosophy of the CLI unified type system is a blitable entity with no internal plumbing, so to speak. That is all it naturally supports.

You put a pointer in it, you got troubles – there are no special member functions to provide deep copy semantics or to free the resource addressed prior to the end of its lifetime. Let's not even consider attempting to declare complex member types. That's not what you do with value classes.

I will claim that they are not unnatural. What is unnatural, but understandable presuming that you have a C++ background, are the sophisticated uses you think to put these rather unsophisticated types. When you think value class, think integer. Then things will begin to click for you.

I will address your second question in a subsequent blog: So what's the rationale for trackable references ... ?

Sender: Jack

re: String Literals are now a Trivial Conversion to String

Won't it break most of existing libraries who will try to port to C++/CLI? One override for String^ will break a lot of user code and make calls for the overriden function with string literals look much uglier. Maybe it is better to make two types of string literals differ by, say literal prefix (i.e. old string literals would look like "this" and new ones like c"this")?

As Adam Merz noted in his response to Jack's question of a literal modifier,

That is exactly what Managed Extensions for C++ did with the S prefix, and what they are trying to avoid at this point (I would think)...

Adam is correct. Here is how I described the change in an internal translation guide between the Managed Extensions for C++ and the revised C++/CLI language – this will give you the historical context for why we made the original change.

In the original language design, a managed string literal was indicated by prefacing the string literal with an S. For example,

            String *ps1 = "hello";

      String *ps2 = S"goodbye";

The performance overhead between the two initializations turns out to be non-trivial, as the following MSIL representation demonstrates as seen through ildasm:

// String *ps1 = "hello";

ldsflda    valuetype $ArrayType$0xd61117dd

     modopt([Microsoft.VisualC]Microsoft.VisualC.IsConstModifier)

     '?A0xbdde7aca.unnamed-global-0'

newobj instance void [mscorlib]System.String::.ctor(int8*)

stloc.0

// String *ps2 = S"goodbye";

ldstr      "goodbye"

stloc.0

That’s a pretty remarkable savings for just remembering [or learning] to prefix a literal string with an S. In the revised V2 language, the handling of string literals is made transparent, determined by the context of use. The S no longer needs to be specified.

What about cases in which we need to explicitly direct the compiler to one interpretation or another, as in the case of an overloaded pair of functions?

void f(char*);

void f(String^);

f("ABC");           // by default calls f(char*)

In the revised language, an explicit cast is used rather than the prefix S. For example,

f(( String^ )"ABC"); // ok: invoked f( String^ )    

As you can see, the revised language originally sought merely to correct a failing in the original design – the surprisingly performance penalty for a user misstep in the declaration of a CLI string literal.

This subsequent refinement during the standardization of the language under ECMA represents imo a rebalancing of the CLI and native type systems -- an acknowledgement of the need for the design to be Janus-faced (an image I introduced in one of the three introductory blogs) – that is, to look equally on the needs of the CLI and native programmer.

Which brings us back to Jack's original question: isn't this going to blow existing code out of the water? Or, to put it more crudely, isn't this a disaster?

Well, I don't believe so, although I wasn't part of the decision-making process and since the change is currently undocumented as far as I am aware, I have not seen any analysis of the effect of the language change. So, let me give you my take on the effect, and give my reasoning as to why I don't see it as being quite as dire as does Jack.

1. The addition of a trivial conversion of a string literal to String^ is equivalent to that of const char* rather than taking precedence. The determination of a best viable function, therefore, results in the introduction of an ambiguity rather than to silently change the resolution (and therefore behavior) of the program. The user would then explicitly cast the invocation to the intended type; admittedly, this could be burdensome, but it is not dangerous.

Under C#, a change in the access level of a class member silently changes the resolution of a named reference in an existing program – which may be completely unknown to the person making the change. We are not talking here of that level of semantic rupture, but merely the difficulty of accommodating the mechanical importation of native code into the CLI program space.

2. So, let us try to address the issue of burden, which is what I suspect this all reduces to. I don't believe it is really all that extensive because the C++ overload mechanism operates by scope rather than signature, and so the set of candidate functions is constrained – unlike a language like C#, for example, where a change like this would be, I suspect, more severe and difficult to manage. (Again, I am not part of the design process currently and so I haven't drilled down on this as deeply as I otherwise might.)

1. Candidate functions are limited by scope. Therefore, the extent of the effect of adding an f(String^) to an existing set of f() is limited to the scope in which it is introduced.

To be exhaustive, we would break this down into the possible scope scenarios – local function, independent class, class hierarchy, namespace, and global scope – and analyze the extent of impact within each. I have not done that, but I suspect that it is really only the global and namespace introductions that are potentially disruptive and burdensome.

Class hierarchies are not burdensome because names do not overload across base/derived class boundaries in C++ since they maintain their own scope. Namespaces are potentially burdensome because of using declarations, and the global namespace is burdensome just because it is the global namespace.

2. the introduction of an f(String^) within a class or class hierarchy is not truly burdensome in its potential introduction of an ambiguity. While it may cause a cascade of ambiguities with the introduction of f(String^) at global scope, or within a heavily-used namespace, the real questions then is a design question, imo. What is the purpose of introducing the f(String^) in a space in which const char* is still heavily used? Perhaps in migrating the existing native code base, we should exercise some design refactoring of the interface?  What is the benefit of supporting both const char* and String in a CLI environment? and so on.

So, I think the spirit of the change is in the right direction. The solution isn't perfect, however, since this represents the only potentially truncating trivial conversion – this is what I mean when I say that imo it is not strictly ISO-C++ conforming: there are no other trivial conversions that suffer a loss of precision – those are all more costly conversions. Of course, on the other hand, String^ is not ISO-C++, but I am not being that literal here. The problem is that if I place a wide-character in the string literal while it exactly matches String^ in the abstract, in practice, it is first parsed as a const char*, and so the second byte is discarded.  (Thank you, Dave Waggoner, for pointing out that problem.)