A reader writes

Sender: Brian Braatz

=====================================

I posted the following to the boost email group and receieved the following response. I was wondering if you had any comments or thoughts on this. I am personally concerned that MS will eventually ditch C++ or take away my ability to use ALL the features of the C++ lanuaguage (not now, but I feel it is coming.. someday I will have C# or VB.net as my only "choice" on the ms platforms)

There is no question that the original Managed Extensions for C++ was a severe body blow to the credibility of a viable future for C++ on the Microsoft platform. In fact, when I originally interviewed here, I said pretty much the same thing as Brian to the folks here, and it felt, anyway, that I spent much of the first half year here battling people’s perceptions that the managed exceptions while not perfect were pretty much ok. In some ways, the original release infuriated me; and that made me a less effective force for change than I might have been. It was clear to me from the outset that we had to either radically reengage our C++.NET vision or else pack up our tent and become a historical curiosity to an increasingly dynamic programming environment – something I would characterize as a tragically hopeful monster. Eventually, the whole department became mobilized; although it wasn’t until Herb Sutter took a leading role that we turned the corner, in my opinion. And I believe we have. The problem now is overturning nearly two years of being the .NET whipping boy and getting people to take us seriously – well, not us but the language, which is now called C++/CLI, and is both an ongoing ECMA standard and in liaison with the new ISO-C++ committee work. I personally guarantee that anyone that feels passionate about C++ will be both delighted by and engaged with the C++/CLI language that will be shipped with Visual Studio 2005, and should be available as a first peek in an upcoming Beta program. (I’ll engage more on the details in subsequent blogs – really J)

A reader comments

Sender: Joe Pacheco

=====================================

re: Integrating Dispose and Finalize into the Language

What about destructors for value classes?  Was it considered when you did the language design?

To become truly usable they are still missing couple of things, copy constructors being one of them.  It's possible that it has some implementation difficulties but if we abstract from them for a moment, the question is if such value classes with copy constructors and destructors are of any value.

Possible applications could be containers for native objects or managed equivalent of smart pointers.  I was also thinking about something similar to gcroot<> implemented with value classes that doesn't need to "root" the managed object.

I’ve forwarded the question to Brandon Bray who is one of the language design leaders of the emerging C++/CLI ECMA standard, and of Microsoft’s C++/CLR implementation of that standard in Visual Studio 2005 (there, I think I’ve mastered that nomenclature). He can detail the design thinking that lead to the original inclusion of a destructor and default constructor for a value type and the implementation obstacle(s) that subsequently led to the removal of these special member functions (delicately referred to as SMFs). The fundamental obstacle is the inability of the compiler to guarantee access to the object at creation and destruction points to invoke the appropriate method.

Both the question and the inevitable detailing of frustrated design intentions end up portraying the CLR as an obstacle to the realization of an at least more perfect C++/CLI language. That is certainly one perspective. I thought I would offer a counter perspective, and … well, then duck.

The fundamental nature of a value type it that it is blitable – that is, we can completely reproduce it with integrity by copying a fixed-size, contiguous segment of memory.  All we need to implement this is the address of its first byte, and its total size in bytes. For a value type to be blitable, there are two necessary characteristics. One, it needs to maintain all its state information within itself (yes, this implies that pointers can screw up blitability). Two, it must not not contain auxiliary state that, if corrupted, leaves it undefined – for example, a virtual function table pointer. The canonical value type is an integer. This is the litmus test of every type system.

An entity is not blitable under the following conditions (because this is a blog and not a text, I invoke the right of not being exhaustive):

1. It contains a copy constructor or copy assignment operator. Copying now is a semantic rather than physical operation.
2. It contains either a member object or base class subobject that is not blitable. This requires memberwise rather than bitwise copy.
3. It contains an auxiliary state member that supports implementation and which can be compromised by physical copying. The canonical example is the assignment of a derived class object (not pointer or reference) to a base class object. Except in the trivial case of an identical active set of virtual functions between the base and derived class, the bitwise copying of the derived object to the base class object corrupts the base class object’s internal virtual table pointer. Therefore, a form of memberwise copy is required.
4. It contains one or more pointer or reference members that exhibit shallow copy, address a dynamic memory address, and the type itself defines a destructor that reclaims that memory. This is an implementation issue at the user level – a milder form of 3 – but one which has been a pitfall of C++.

That is, the ideal value type is pure state – think of a point with two or more coordinate values. It does not need a copy constructor or copy assignment operator because state is blitable. It does not need a destructor because the extent of state is its lifetime, and it is independent of all other state in other entities of this or any other type. A default constructor is not necessary because there is only state, not infrastructure to set up, and at best an object with a default initialization is in a safe but meaningless state – that is, it can be recognized as requiring initial values. So, an optimal value type – a pure value type – is one without these four SMFs. This is what the CLR provides.

Yes, there are conceptual extensions that we would like to provide. The obvious one, which you mention explicitly and which I discuss in an earlier blog, is to wrap pointers to native types. To do this without massive memory leaks, one needs a destructor. Unfortunately, the compiler is unable to guarantee that it can in all cases intervene before object destruction in order to invoke the method, and therefore it is not really possible to support a destructor for a value type. Is this terrible? Well, it is a real disappointment in the case of wrapping a native pointer in which we create massive numbers of instances since wrapping it in a reference type doubles the number of heap allocations (one for the reference, and one for the native).

How likely a scenario is this? Personally, I’m not sure. I spent a few days more than a year ago walking through a number of graded scenarios using a vector and matrix pair of classes that I had implemented in my days as a graphics programmer. I compiled and timed a program exercising these folks natively, then simply compiled and timed it using IJW. Then I wrapped the folks first in a value type – it leaked – and then a sealed reference, then reimplemented the folks in turn as value and reference types. (Of course, reference types in the original managed extensions don’t support operator overloading so that was kind of useless.) I also wrapped a nonsense query application I had written for the third edition of my C++ Primer. My sense from this exercise is that those things which would gain in performance by a value wrapper are those things that in practice are best ported directly into the CLI. But I have no practical data. Back in the late 1970s and early 1980s when the wrapper pattern became wide-spread in the C++ community, wrapping proved primarily of benefit over complex systems, such as sockets or X windows – or to shield an application from a specific api such as a database in case one had to for whatever reason replace it.

The CLI separates reference and value types in a way that is unnatural to the C++ programmer; that is, it constrains what each type is permitted in the body of its definition. C++ does not separate value and reference semantics in the definition of its types but, rather, in the declaration of its objects. This allows us a continuum rather than the ... oh, discrete quantum types of the CLI. This permits a great deal more flexibility, but at the cost of sometimes spectacular complexity in the understanding of our programs. The exemplar of this is probably best captured in the difference between the C++ template facility and the CLI generic mechanism.

In the original language design, a class destructor was permitted within a reference class but not within a value class. This has not changed in the revised V2 language design. However, the semantics of the class destructor have changed considerably. The what and why of that change (and how it impacts the translation of existing V1 code) is the topic of this section. This is probably the most complicated section of the text, so we'll try to go slowly.

Before an object is deleted by the garbage collector, an associated Finalize() method, if present, is invoked. We refer to this as finalization. The timing of just when or whether a Finalize() method is invoke is undefined. This is what is meant when we say that garbage collection exhibits non-deterministic finalization.

When an object maintains a critical resource, perhaps a database connection or a lock, the freeing of this resource cannot depend on the invocation of a finalizer. The canonical solution is to implement the Dispose() method of the System::IDisposable interface. The problem with Dispose() is that it requires an explicit invocation by the user. In the revised language design, the class destructor is used to automate invocation of the Dispose() method.

In the original language, the destructor of a reference class is implemented through the following two steps:

1.      The user supplied destructor is renamed internally to Finalize(). If the class has a base class (remember, under the CLR Object Model, only single inheritance is supported), the compiler injects a call of its finalizer following execution of the user-supplied code. For example, given the following trivial hierarchy taken from the V1 language specification,

__gc class A {

public:

   ~A() { Console::WriteLine(S"in ~A"); }

};

__gc class B : public A {

public:

   ~B() { Console::WriteLine(S"in ~B");  }

};

both destructors are renamed Finalize(). B's Finalize() has an invocation of A's Finalize() method added following the invocation of WriteLine(). This is what the garbage collector will by default invoke during finalization. Here is what that might look like:

// internal transformation of destructor under V1

__gc class A {

public:

   void Finalize() { Console::WriteLine(S"in ~A"); }

};

__gc class B : public A {

public:

   void Finalize() {

Console::WriteLine(S"in ~B"); 

A::Finalize();

   }

};

2.      In the second step, the compiler synthesizes an virtual destructor. This destructor is what our V1 user programs invoke either directly or through an application of the delete expression. It is never invoked by the garbage collector.

What is placed within this synthesized destructor? Two statements. One is a call to GC::SuppressFinalize() to make sure there are no further invocations of Finalize(). The second is the actual invocation of Finalize(). This, recall, represents the user-supplied destructor for that class. Here is what that might look like:

__gc class A {

public:

      virtual ~A()

{

            System::GC::SuppressFinalize(this);

            A::Finalize();

      }

};

__gc class B : public A {

public:

      virtual ~B()

{

            System::GC:SuppressFinalize(this);

            B::Finalize();

      }

};

While this implementation allows the user to explicitly invoke the class Finalize() method now rather than whenever, it does not really tie in with the Dispose() method solution. This is changed in the revised language design.

In the revised language design, the destructor is renamed internally to the Dispose() method and the reference class is automatically extended to implement the IDispose interface. That is, under V2, our pair of classes are transformed as followed:

// internal transformation of destructor under V2

__gc class A : IDisposable {

public:

   void Dispose() {

      System::GC::SuppressFinalize(this);

Console::WriteLine( "in ~A"); }

   }

};

__gc class B : public A {

public:

   void Dispose() {

      System::GC::SuppressFinalize(this);

Console::WriteLine( "in ~B"); 

A::Dispose();

   }

};

When either a destructor is invoked explicitly under V2, or when delete is applied to a tracking handle, the underlying Dispose() method is invoked automatically. But what if it is not? Then the garbage collector has no access to the destructor because it is not transformed into Finalize().

To accommodate this possibility, the revised language design provides a revised syntax using the bang (!) to support the explicit definition of a finalizer. For example, one might write

            public ref class R {

      public:

            !R() {  Console::WriteLine( "I am the R::finalizer()!" ); }

      };

The !R() method is renamed internally as Finalize(). It is this method, if present, that is invoked by the garbage collector during finalization if the destructor has not been previously invoked. Here is what the transformation might look like:

            // internal transformation under V2

public ref class R {

      public:

          void Finalize()

{  Console::WriteLine( "I am the R::finalizer()!" ); }

      };

This has a number of gnarly consequences for V1 code. Essentially what should happen is that an explicit Dispose() method should be transformed into the class destructor. If a destructor is present, it should be transformed into a (!) finalizer. The translation tool currently doesn't do this, but is on the worklist.

I’d like to thank Yves Dolce for responding to Wesner Moise who writes:

Sender: Wesner Moise

re: Value Type Representation Between the Original and Revised C++

I am not sure that I understand you when you say v.ToString() results in an error, because v needs to be boxed in order to access an inherited method. V does not need to be boxed; indeed, valuetypes are not boxed in VB.NET or C#, when ToString() is called.

Yves dug a bit and wrote the following:

Sender: Yves Dolce

re: Value Type Representation Between the Original and Revised C++

I just tried with C#:

struct Complex

{

   public Complex( double r, double i )

   {

      this.r = r ;

      this.i = i ;

   }

   private double r, i ;

}

...

   Complex c = new Complex( 1, 2 ) ;

   c.ToString() ;

And the IL shows c IS boxed:

IL_000d:  ldloca.s   c

IL_000f:  ldc.r8     1.

IL_0018:  ldc.r8     2.

IL_0021:  call       instance void NeedToBox.Complex::.ctor(float64, float64)

IL_0026:  ldloc.0

IL_0027:  box        NeedToBox.Complex

IL_002c:  callvirt   instance string [mscorlib]System.ValueType::ToString()

In fact, if memory serves, this particular problem with value types and the contextual need to box them or not was at one time a problem with generics in C#, but I don’t recall the issue. As Yves further documents, in the original C++ with Managed Extensions release,

Sender: Yves Dolce

re: Value Type Representation Between the Original and Revised C++

Wesner,

Try calling ToString() on an instance of:

_value class Complex

{

   public:

      Complex( double r, double i ) : m_r(r), m_i(i) {}

   public:

      //virtual String * ToString() { return String::Format( S"{0} + {1} i", m_r.ToString(), m_i.ToString() ) ; }

   private:

      double m_r,

             m_i ;

} ;

I will fail with:

error C3610: 'Complex': value type must be 'boxed' before method 'ToString' can be called

As I wrote in my original blog entry,

The primary motive behind this design was pedagogical: it wished to make the underlying mechanism visible to the programmer so that she would understand the `cost’ of not providing an instance within her value type. Were V to contain an instance of ToString, the implicit boxing would not be necessary.

In thing2 [yes, referring to the two languages in this way is annoying, isn’t it?], the implicit boxing is carried out transparently:

            v.ToString(); // thing2

but at the cost of possibly encouraging the class designer to introduce an instance of ToString within V. The reason the implicit boxing is preferred is because while there is usually one class designer, there are an unlimited number of users, none of whom would have the freedom to modify V to eliminate the possibly onerous explicit box.

The other reason not to require the explicit boxing is that it requires the programmer to understand what is going on under the hood, and the C# and VB.NET design philosophy is not to burden the user with that level of complexity: not just the boxing that is required, but the use of a virtual table, and the need to locate the pointer for that table for value classes that do not provide an explicit instance, etc. That is a lot of baggage to ask the user to carry for a seemingly simple ToString() invocation!

This kind of dialogue is actually quite refreshing, and something that book-writing does not give rise to. Once again, let me thank Yves!

Program efficiency at the programmer level is something of a complicated issue – in part because it is contextual. That is, it is hard to say something that holds true in all cases. [This is why having a good profiler is essential.] For example, the same implementation may be adequate, if embarrassing (should anyone actually look), under some circumstances and the cause of a crippling bottleneck under others. Consider the following constructor definition:

foobar::foobar( const bar b, const foo f )

{

      m_b = b;

      m_f = f;

}

This is a terribly naïve implementation:

·         The class parameters b and f are passed by value rather than by reference. This results in unnecessary temporaries being created and destructed.

·         The member class objects m_b and m_f are assigned to rather than initialized, resulting in their unnecessary default construction.

·         The constructor itself is a good candidate for inlining.

·         (And yes, the naming conventions leave something to be desired J)

An absolutely better implementation is the following:

inline foobar::

foobar( const bar &b, const foo &f )

    : m_b( b ), m_f( f )

{}

but … well, does it matter in terms of the project? For argument’s sake, let’s say a summer intern wrote this.The bottom line: It runs correctly and there is no security breach. Let’s fantasize and say the project is under severe schedule pressure. So, on the one hand, we just feel an immense relief that the foobar component is functional and checked in. (Hey, it demos!)

If bar and foo are large, complex classes with costly copy semantics, and if there are lots of foobar objects generated in our application, then this is likely to be a significant performance gain. On the other hand, if foobar class objects are only rarely created, then the improvements to the code are not significant, and the code is no big deal. That is, the code is better but, overall, nothing has really changed. At what point do we stop making code better?

So, my point is: making rules in itself isn’t enough. Knowing where to rigorously apply those rules matters as well. As conventional wisdom has it: profile!

Sometimes, there is no real software solution, and anything coded at the application level is mostly just trying not to get in the way. For example, I was technical lead on the ToonShooter project at DreamWorks Feature Animation. It intended to replace a very old Objective-C Macintosh-based [at least 4 years old!] pencil-test playback system for animators with a spanking brand new C++ implementation under Linux. The goal was two-fold: (1) to deliver an actual system either for Spirit [already in production] or, if that proved unfeasible, for Sinbad, at that point in artistic development, and (2) to componentized the class hierarchies for subsequent reuse in other applications – playback, compositing, file-format, math and geometry, etc.  

At the heart of the system is a playback engine that must display the images at a minimum rate of 24 frames per second. If it can’t do that, then there is no system. The actual display of the images was done using an OpenGL command, glDrawPixels. Under SGI, it just hummed. Our initial test under Linux with a promised high-performance X Server and OpenGL implementation was a mind-boggling 2 seconds per frame. Turns out the OpenGL implementation was not making use of the underlying hardware, but doing hardware emulation in software.That’s like trying to play point guard without being able to dribble with your left hand.

This was before we even wrote a line of code. Although our project was to be implemented in C++, its success ultimately rested on finding direct hardware support of image blitting [that was not glamorous enough to get proper attention back then]. Until that was solved, our application couldn’t actually be deployed – at least not under Linux. Solving the display issue was a management issue. The point was, it blindsided everyone; we had jumped before confirming that the pool contained water.  

[Having access to the Linux OS source code was a mixed bag. When Andrew discovered a flaw in the clock in his work on synchronization, no one seemed ready to delve in and try their hand at fixing it. On the other hand, Andrew studied the sound drivers and found a number of bugs, so the source code in this case did benefit from his superior expertise, and we were able to quickly overcome a faulty implementation. We originally hoped for a digital image solution for bringing the artists’ drawing to the computer, but there was no implementation of a sufficiently fast protocol [that is probably the wrong word [this was my first task as a technical lead in which many facets of the project were beyond my technical competence, and I owe Ed Leonard a great deal of gratitude for his overcoming my reluctance to take on such a position] and we could not get any commitment as to when I think it is called firewire would come to the OS. Since no one in-house was in a position to do the implementation itself, we ended up with a analog video solution.]  

[HP rode in on a white horse, as it happened, up ending various other vendors challenged to come in and provide a solution [unfortunately, Microsoft was not an active player back then]. It felt truly heroic at the time, and HP have justly flourished within that domain space since. We delivered a componentized system in time for it to be successfully used by Spirit, saving them millions of dollars in animators’ time. It was probably my most satisfying experience as a developer. Unfortunately, the movie did not do well at the box office, and the company has since stopped doing traditional 2D animation so I guess the ToonShooter’s shelf life is over.]

Compositing proved a fertile ground for optimization, but a somewhat humbling one, as it turned out. In ToonShooter, once the pencil drawings are captured and the sound file imported, the animator plays back the scene, checking image flow and correct lip-synching. Levels are turned on and off as the different elements are added to or removed from viewing. Compositing is done on the fly as it delivers frames to the playback engine.

Even when we got the playback at speed, we had to insure that the compositing was able to deliver the image. Obviously, in part the success of this depends on the number of levels requiring compositing. For example, one level worked without a hitch [J]. Actually, we supported – I think we tried up to 3 levels without dropping frames in the prototype – hey, that’s as far as we pushed it! [We only had to demo it at that point!]. But we knew this was something critical we need to get a handle on before it became an issue. [Some animators we talked to in effects were talking of 30-50 levels – I mean, we’re talking glints of sunshine the size of a thumbnail, or the march of wavy lines across water, but still. It would have fallen on my watch if we couldn’t handle it.

For a grey-scale rough animation pencil drawing captured at 8 bits, compositing can be reduced to choosing the minimum of two values. That is, for each pixel, which is an unsigned char, retain the lower value (black is 0, white is 255). However, for a 640x480 image, that’s still 3K * n-1 levels traversals comparing pixel values. 16 levels would probably be stretching the just in-time delivery of frames. We kept poking at the code to see how we might further tweak it.

What I had forgotten is that sometimes the answer to optimizing code is finding a way to actually not execute it.

Part of the problem was my unfamiliarity with the domain. When our current head of technology looked at the code, he had an obvious answer: Rather than doing the arithmetic, do an index into a table of the 255 values. At first I didn’t get it, because I didn’t realize there is a fixed set of constant values that each pixel could represent. Once I got it, the solution was obvious.  (It always is. I’m just not used to being the one with my mouth hanging open.) In fact, it’s a canonical solution anecdotally related in Jon Bentley’s excellent text, Writing Efficient Programs, published by Prentice-Hall.

There is actually a trick to doing this in C++. What you don’t want to do is build up the table in a constructor – even an inline constructor. Why? Well, a constructor is a run-time entity. The look-up table has to be independent of any class object, and so it is made a class static member. This is, under any kind of constructor scheme, the table gets `statically initialized’ prior to the beginning of main(). So even if you hard-coded each value, setting up the table is a run-time activity.  It is significantly more efficient to code a program to write out the table as a built-in array of constant expressions into a program text file and then compile that as part of your build.

// Fill the min table

      int min_lut[size][size];

      for ( int i = 0; i < size; i++ ) {

            for ( int j = i; j < size; j++ )

                    min_lut[i][j] = min_lut[j][i] = i;

}

      // Write out the tables

      ofstream text_file( "Compositor_LUT.cc" );

      text_file << "// This file is created by …";

      text_file << "#include <Compositor.h>\n\n";

      // this is a static member of Compositor ...

      text_file << "unsigned char Compositor::minLUT[256][256] = {\n" );

      for ( int i = 0; i < size; i++ ) {

            text_file << "{ " ;

            for ( int j = 0; j < size; j++ ) {

                    text_file << min_lut[i][j] << ", " ;

      // etc.

So. We can speed up/optimize image compositing up to a point. After that point, it levels out. Once we reach that point, the only workable solution is to avoid doing any compositing at all – or at least reduce it to a subset of the required compositing. [Actually, an even better solution is to move the operations to hardware with cool and nifty video cards, etc.]

The first step in achieving this is to cache composited images. Before we invoke the compositor, we check that the resulting image is not already available in the cache. Failing an exact match, we look for a best match – perhaps 2 or 3 of the 4 required levels have already been composited, and so we only composite the missing level(s). To achieve this in a reasonable fashion, we need to be able to efficiently tag the different composited images (by frame by active levels).

For this caching strategy to be effective, of course, the mechanism must be (considerably) cheaper than the process of compositing itself. The bitset and map classes make image tagging and retrieval reasonably simple. [For some reason, the gcc Linux compiler at that time didn’t support bitsets – apparently there was some contention about whether they warranted inclusion in the ISO standard under development. Back then, you could not use Linux for serious development without using gcc so I ended up having to incorporate the free SGI implementation of bitsets. ]

When an image is about to be composited, a bit is turned on for each level that is active. That value can then be turned into an unsigned long, which can be used as a unique key in a map:

  map<unsigned long, Image*>;

  int main()

  {

    bitset< 16 > mbit;

    CManager pcomp;

    Image *pim = 10000;

    unsigned long search_key;

    for ( int frame = 1; frame < 12; ++frame ){

        mbit.reset();

        for ( int ix = 0; ix < 16; ++ix ) {

            if ( ix % 2 ) {

               mbit.set( ix );

              unsigned long key = mbit.to_ulong();

                pcomp.add_to_cache( frame, key, pim );

             }

        }

    }

    // …

}

CManager::add_to_cache() frame: 11 key: 2     addr: 0x2710

CManager::add_to_cache() frame: 11 key: 10    addr: 0x2710

CManager::add_to_cache() frame: 11 key: 42    addr: 0x2710

CManager::add_to_cache() frame: 11 key: 170   addr: 0x2710

CManager::add_to_cache() frame: 11 key: 682   addr: 0x2710

CManager::add_to_cache() frame: 11 key: 2730  addr: 0x2710

CManager::add_to_cache() frame: 11 key: 10922 addr: 0x2710

CManager::add_to_cache() frame: 11 key: 43690 addr: 0x2710

frame # 11

        0000000000000010 :: 0x2710

        0000000000001010 :: 0x2710

        0000000000101010 :: 0x2710

        0000000010101010 :: 0x2710

        0000001010101010 :: 0x2710

        0000101010101010 :: 0x2710

        0010101010101010 :: 0x2710

        1010101010101010 :: 0x2710

I never actually deployed this. I had simply been asked to come up with a possible strategy for speeding up compositing on a software level just in case [I was moving on after the initial deployment of the system]. As it happened, moving the compositing to hardware was the optimal solution.

The two most effective optimization techniques, I suspect, are procrastination and cheating. For example, Martin Davis, in his text The Universal Computer, mentions a Pascal [!] program to compute Leibniz’s series for pi/4. Running on a 486 33MHz PC, summing 1 million terms took 50 seconds, 10 million took 8 minutes. Two years later, the same program was run on a Pentium 200 MHz machine, and “the times were reduced to 4 seconds and 40 seconds respectively.”

A compelling example of cheating is the original Doom game engine. Rather than calculate the hallway lighting for various hallways in real time, they simply pre-generated bitmaps. Level of detail is always a wildly-used cheat: things that are beyond a certain level of nearness do not need to be rendered with the same level of detail. My favorite example is detecting when one object intercepts with another [I can’t thing of the formal description of it off hand]. In a game like Mario Kart, there is none – the key element of the game is speed, and the audience [mostly children] find the occlusion [if that is the right word] of a truck or tree with Mario’s kart quite amusing, so why bother eating up cycles preventing it? During the making of the Hunchback of Notre Dame, Kiran Joshi developed crowd software that represented different individuals in cycles of movement in order to fill up the streets of Paris. Edge detection was necessary to the degree that having the hand of one entity piercing the face or body of a neighbor would spoil the illusion of reality necessary for the cartoon. This was managed by simple bounding boxes that marked a coarse-rectangle separating one character from another. It required considerably more work than did Mario Kart, but was not a significant amount of work overall. Not so in the case of the lovely Fantasia Segment, Toy Soldier, in which Dave Tonnesen’s work with simulating the physics of the movement of cloth was coupled with the separately generated movement of the ballerina. The required verisimilitude was labor intensive, but anything short of that would have been insufficient. Without knowing up front what the performance characteristics of a piece of software are required to be, it is very difficult to quantify that you have met them, and to know where to allocate precious programming resources.

A reader, Yves Dolce, writes:

Related to your last blog entry: The Astonishing S"Literal" String Type

I was surprised that sometimes, boxing is conceptually implicit...

That any Object method can be called directly without any explicit boxing.

And of course, explicit boxing is valid but seems less efficient as a real object ends up being created on the managed heap instead of just taking the address of the double (ldloca.s) ...

Console::WriteLine( S"2 cubed is {0}", result.ToString() ) ;

Console::WriteLine( S"2 cubed is {0}", __box(result) ) ;

gives

IL_0008:  ldstr      "2 cubed is {0}"

IL_000d:  ldloca.s   result

IL_000f:  call       instance string  [mscorlib]System.Double::ToString()

IL_0014:  call       void [mscorlib]System.Console::WriteLine(string, object)

IL_002a:  ldstr      "2 cubed is {0}"

IL_002f:  ldloc.0

IL_0030:  box        [mscorlib]System.Double

IL_0035:  call       void [mscorlib]System.Console::WriteLine(string, object)

Yes, the need to box occurs only when the source of the assignment to an Object^ is a value type. A Value type, recall, maintains its state within each associated object [what in C++ is created when we write T t]. A Reference type is a duple in which the named instance is a handle holding either null or the address of an unnamed object allocated on the managed heap. When we initialize the Object^ second parameter of Console::WriteLine with a Value type, there is a hiccup in the unified type system because there is no way to represent the Value type directly within the handle of a Reference type. The solution is to create a shadowed Reference to the Value type on the managed heap and pass in the address of that object. By invoking the ToString() method associated with the Value type, the need for boxing is elided because a String^ is a sealed Reference type.

I personally never bother to write ival.ToString() rather than ival when passing a value type to Console::WriteLine because generally speaking the overhead associated with a write operation is going to overwhelm the cost of the boxing itself, and any print operation is not going to be in a hot spot within an application. In general, why bother optimizing something for which the performance gain is negligible – particularly if it obfuscates the code, however slightly? [I know, one wants a steel discipline …]

In any case, this brings me to a second usage of the __box keyword that can provide performance gain by providing a direct handle to the boxed value type allocated within the managed heap. For example,

int main()

{

double result = 3.14159;

__box double * br = __box( result );

result = 2.7;

*br = 2.17;   

Object * o = br;

Console::WriteLine( S"result :: {0}", result.ToString() ) ;

Console::WriteLine( S"result :: {0}", __box(result) ) ;

Console::WriteLine( S"result :: {0}", br );

}

Passing the boxed value type directly to Console::WriteLine eliminates both the boxing and the need to invoke ToString. [Of course, there is the earlier boxing to result to initialize br, so of course we don’t really gain anything unless we really put br to work.]

  IL_0052:  ldstr      "result :: {0}"

  IL_0057:  ldloc.0

  IL_0058:  call       void [mscorlib]System.Console::WriteLine(string, object)

In the revised language, the support for boxed value types is, in my opinion, considerably more elegant and integrated within the type system. Here is a translation of the function main() into C++/CLI [it’s machine generated; that’s why the spacing is different]:

using namespace stdcli::language;

int main()

{

      double result = 3.14159;

      double^ br = result;

      result = 2.7;

      *br = 2.17;

      Object^ o = br;

      Console::WriteLine( S"result :: {0}", result.ToString() );

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

      Console::WriteLine( S"result :: {0}", br );

}

I’ll talk about boxed value types some more in a future entry, or answer any questions. …

One of the astonishing infelicities of the original language design was the unflagged overhead of the seemingly trivial failing of placing an S in front of a string literal targeted to a managed reference object. For example, given the following two System::String declarations,  

            String *ps1 = "hello";

      String *ps2 = S"goodbye";

here is the MSIL representation as seen through ildasm of the following two String declarations. Notice the astonishing performance difference.

// 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; or, to look at it another way, that’s a durn stern penalty for not doing so. [In addition, if S”goodbye” occurs 5 times, they are collapsed into a single shared instance.] And ignorance is not a mitigating defense! Using the default Visual Studio settings for a project, this compiles without any warning, as the following illustrates:

nettest - 0 error(s), 0 warning(s)

What’s perhaps equally remarkable is that in another common corner of the language, implicit value type boxing was explicitly not supported because it was felt that it would result in a false sense of security for the programmer who would not realize its run-time overhead.  For example,

            int ival;

      Object *po = ival;          // error

Object *po = __box( ival ); // ok

Of course, these two design corners are not really at all the same – in fact, they seem to illustrate opposite design philosophies. In the one case, a trivial detail that is context sensitive silently causes a truly astonishing inflation of the run-time program. In the other case, there is no underlying gain or loss in the behavior of the program by having the explicit __box operator – only in the behavior of the programmer. It is a pedagogical design intended to teach the programmer about the nature of the CLR’s unified type system.

The solution in both cases is to make the behavior transparent. A reference type assigned with or initialized to a value type results in a boxing operation. This is as fundamental to the unified type system of the CLR as the copy constructor and copy assignment operator are to native C++. Ignore them at your peril. If you assign a literal string in a context where an S should be, the S is implicitly present.

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");           // calls f(char*)

The decision of the language design team is to drop the S and rather require the user to explicitly cast the literal string, as in

f(( String^ )"ABC");