Object Instantiation

Part of the ObjectBasedProgramming Pattern discussion.

This section is intended as a discussion area for issues in instantiation: e.g.

• How to allocate memory required for instance data (Heap, Static, Stack, Buffer)?
• What does a constructor function looks like?
• Should the constructor be coupled with memory allocation?

-- StephenCheng

---

The whole notion of instantiating an object raises a whole host of questions and issues about the class hierarchy it comes from. When you decide to instantiate an object when doing ObjectBasedProgramming, you may have already decided whether that object is from a class within a class hierarchy, so does it have PolymorphicFunctions or not? And what about those methods?

If it does, are those links to the functions that it needs to use made at runtime or have they been resolved by the linker?

-- ScottWalsh

If I am reading you right, you are trying to perform special optimization if you know in advance which class out of the entire class hierarchy you are instantiating.

One PolymorphicFunction serves the entire class hierarchy. (That's why it is called a polymorphic function - because it does different thing to objects of different classes). To perform the kind of optimization suggested, macros would be the choice - to skip the generalized polymorphic function and go straight to the class-specific function.

So far, I have not tried this kind of optimization. Although technically possible, the resulting maintenance headache is probably not worth it.

-- StephenCheng

---

What Scott is referring to here stems from the fact that we have no dynamic memory ability. We're running in 16K ROM, 512 bytes RAM. We know exactly how many instances of most classes will be created - usually just one.

We may have quite a wide class hierarchy, for example an NVRAM. Here we have numerous types of NVRAM, but a standard interface. Here's an elided example (in CeePlusPlus)

  class Nvram
  {
  public:
    Nvram();
    virtual void WriteByte ( int address, char value ) = 0;
    virtual char ReadByte ( int address ) = 0;

    void WriteString ( int address, char *data, int len )
    {
      int i;
      for (i = 0; i < len; i++)
        WriteByte ( address++, *data++ );
    }
    // Similarly for WriteWord, WriteLong, ReadString, and so on
  };

Now, we have various subclasses for different types of NVRAM ... but our eventual implementation will use only one of them. We have a version which is accessed through a parallel interface [ParallelInterfacing?]; one which uses a serial bus; one which - for debugging purposes - uses emulator memory. Each subclass is in a separate source file.

For each, all we have to write is the specialize constructor, and the ReadByte and WriteByte routines. We can then choose which version we instantiate as our sole NVRAM object, and link in the appropriate object file. For example (in CeeLanguage)

  struct EmulatorNvram NvStore;

  NvStore_Constructor( /*this */ &NvStore, /*base*/ 0x8000, /*size*/ 128 );
  ...
  NvRam_WriteString(&NvStore, 20, "test data", 9);

We actually have some hierarchies which are several levels deep, and reasonably wide. But eventually we may only actually instantiate a few of the classes.

Given the highly fluid nature of the hardware design we're working with, this architecture has enabled us to repsond quickly to changes. These changes have been implemented relatively painlessly, and have rarely introduced any new bugs.

It's difficult to give concrete examples due to the commercially sensitive nature of our project. So occasionally our comments may seem cryptic.

-- KeithDerrick