LETTERS

  String v = "abcd";
  v +=1;           //result "bdce"

the action of the += operator is not intuitive. In the example

  String v = "1234567890";
  v << = 1;              //result "2345678901"

the << = operator is being used to rotate the string left when the intuitive use would be to shift the string left.

I have also found the assignment operators to be very powerful for increasing efficiency because you don't need to create a temporary variable to hold the results. In the String class the use of += to concatenate to a string is a good example.

Where this breaks down is operations that cannot be intuitively expressed using symbolic operators. For vector classes, if you used the ~ operator to express the computation of the unit vector, it is then easy and consistent to define ~= as the computation of the unit vector in place, which is more efficient. This does not work for operations defined using member functions. If unit vector was implemented as the uvec() member function, there is no direct translation to an assignment member function. A possible implementation would be to create a uvecAssign() member function that returns a reference to the object.

In Steve's proposed standard he suggests the implementation of member functions upper() and lower(). These are implemented as copying the original string and then converting it to upper case or lower case characters, and then returning the copy. This is good and this is necessary, but not always efficient. I would propose two additional member functions: upperAssign() and lowerAssign() to convert the case of the string in place.

My use of the Assign suffix is just an example, and I feel it is a little too verbose, but I would like to see a proposal for a standard naming convention that takes additional assignment functions into account.

Many of the operators were declared as being friends of the String class, as shown in Example 1. Example 2 shows how the first two operators could have been implemented as member operators of class String. I was wondering at the reasoning behind Steve's choice.

Example 1

  friend int operator+
      (const String&, const String&)
  friend int operator+
         (const String&, const char*)
  friend in operator+
         (const char*, const String&)

Example 2

  int operator+ (const String&)
  int operator+ (const char*

The National Institute of Health class library (see Data Abstraction and Object-oriented Programming in C++, by Gorlen, Orlow, and Plexico) includes the definition of a SubString class. I have not looked closely at their implementation and possible uses, but if we are going to define a standard string class, and a substring class is useful, then they should be defined at the same time.

I would like to thank Steve for an excellent article and bringing out proposed standards into a public forum.

Carey Brown

Denver, Colorado

Getting Embed With C++

Dear DDJ,

I was happy to see the article "C++ for Embedded Systems," by Stuart Phillips and Kevin Rowett in the October 1991 issue. I have been working on a similar embedded project using C for sometime now and was just starting to think about how it might be implemented in C++. Since our system is not currently running under DOS, we share many of the problems mentioned in the article, such as having to modify the startup module, not being able to use any library routines which call DOS, converting EXE files, and so on. The article and the source listings were informative and helpful, with one glaring exception. All of the software relating to the article which I downloaded was in C, not C++.

There are still some major unanswered questions which I have with regards to moving to C++ for embedded software. One thing I would really like to know is how to deal with dynamic memory because any calls to standard library functions like malloc() and free() require DOS. In C we can get around this by using only static memory. In C++, dynamic memory seems to be a necessity since objects are created and destroyed at runtime. I eagerly anticipate any future articles on C++ for embedded systems which might address this question.

Will Knight

Los Gatos, California

Stuart and Kevin respond: Thank you for the idea for a future article! You raise an excellent point regarding C++ and its dependence on dynamic memory allocation. Allocation requests are made whenever objects are created, with corresponding release of memory being made when objects are deleted or fall out of scope. In our article we recommended careful review before using any of the standard library routines, by either inspection of their object code, using the debugger, or purchasing the library source code from Borland.

Borland C++, Version 2.0 allocates dynamic memory from the heap. Heap initialization is performed by the start up code contained in C.ASM and does not require DOS support; we modified the start up code to set the heap for our communications processor. You will need to adapt this for your environment.

Both malloc() and free() use memory from the heap in processing dynamic allocation requests. The C++ operators 'new' and 'delete' call malloc() and free(), respectively. The library versions of malloc() and free() may need to be replaced for embedded system work if there is any possibility of interrupt service routines creating objects or needing to allocate memory. Memory allocation requests generally cause manipulation of linked lists or chained memory blocks. Interrupts that require memory allocation requests should be disabled while the linked lists are searched or altered. Failure to disable interrupts in this scenario will result in memory leaks or worse!

Replacing malloc() and free() is not an overwhelming task; there are many examples of memory management routines in books on C and C++. Many of these routines can be adapted for embedded system use by examining their source code for critical sections which must be protected from interruption. You must exercise caution when deciding in which areas to disable interrupts since the performance of embedded systems is generally dependent on interrupt latency. We'll certainly address this issue in any future articles we write.