C++ : The new and delete operators

If you have been accustomed to C, you may encounter the way heap memory is allocated:

char* c = (char*)malloc(sizeof(char) * x);

In C++, due to the existence of classes and constructors/destructors, malloc and free alone won’t suffice; it won’t be able to call the constructor and destructor, respectively. So, the keyword new was made to allocate the memory and call the constructor. The previous item will now look like this:

char* c = new char[x];

Notice that sizeof(char) is gone. Why? Because new will, in order to return the correct pointer type, need to know the type of data you are allocating, and the operator determines the size of an element from the type. The general syntax of the new keyword is:

<data type>* x = new <data type>[y];

where x is the pointer to store the address of the allocated memory, and y is the number of elements. When y = 1, the [y] part can be omitted:

<data type>* x = new <data type>;

Notice new’s two forms: the former, with the square brackets, is called vector new; the one without the brackets is called scalar new.

On the other hand, delete does the reverse: it calls the destructor before putting the memory back to the heap. The delete operator has two forms:

delete – for single-element allocations (scalar)

delete[] – for multi-element (array) allocations (vector)

To avoid being too technical, as I’ve done in some posts, the versions with the square brackets are for array (vector) allocations/deallocations, while the versions without the brackets are for one-element (scalar) allocations/deallocations.

Microcontrollers: Which is the best?

This question arises in many places: circuit design, physical dimensions, and cost, to name a few. For my case (or rather, opinion), here are the important criteria to check for:

• The volume of data going in and out
• Size constraints
• Environment of the embedded-system

A processor handling massive amounts of data per unit time requires more power both computationally and electrically, a faster clock (which also needs more electrical power), and, perhaps, ventilation for applications reaching very high clock rates. Size constraints will always depend where the embedded-system is meant to be placed. A system containing many components in a confined area requires more careful designing and construction. Environmental factors are among the most important: humidity, temperature, and electrical spikes, to name a few. Generally, processors packing more processing power are less forgiving in terms of environmental extremes.

Generally, those processors whose only task is to control equipment through commands issued by a more powerful processor are more rugged in build, since although they have to handle quite large volumes of command/response data, they are spared of the more complex computations such as PIDs that are common in industrial automation, since controlling equipment is their only task. A small program may be added to handle the case that the I/O controller be separated (i.e., the communications link severed) from its controlling station or computer; but that is little.

Linux and Industrial Automation

The well-known Linux operating system is used from desktop computers to high-grade corporate servers, mainly due to reliability, which in turn stems from the large community support base of Linux, since it’s open-source. Personally, I prefer Linux over Windows, although many of my software tools require Windows XP to run.

Linux has also been used in embedded-systems devices because of its stability. For me, I would think of having a normal desktop computer controlling the machinery, through a man-machine interface (MMI.) That is because remote control is always surpassed by local control of a human operator near the machinery – a basic automation rule. And desktops can pack more power and flexibility in terms of processing power than embedded-systems can.

It’s easy to make an interface circuit between the computer and the machinery controls using off-the-shelf components. You can program the microcontroller with just the necessary code for interfacing to the desktop, using the all-classical COM or LPT ports. I like the LPT port, since you can manipulate the 8 bits individually, and they all appear at the hardware port at the same time.

As for the desktop software part, technologies such as remote-procedure calls (RPC), streaming compression and encryption, and even Web servers can be used in tandem. Linux handles networking extremely well, and provides RPC for seamless calling of remote procedures and functions.

Local-operator controls can be designed with cross-platform kits like Qt, or with the native looks of Linux. The graphical UI is left at the discretion of the end-user.

Linux has a lot of uses, indeed. More may be waiting.

.NET Framework runtimes and legacy computers

We may have heard of the .NET runtime in one form or another. Some applications require it in order to run, and many user-interface components out there rely on that framework. But I’ve found out, to my disappointment, that Windows 2000 (or XP) and earlier do not have it pre-installed.

The .NET framework is a significant installation on any machine (a check in the Control Panel applet will easily show how bloated it is, ~100 MB for v2.0), and though speed and performance isn’t much of an issue on newer computers, I tried installing it on an older computer I have at home, and my computer’s slowing to a crawl. Besides, I think v2.0 of the network requires Windows 98 or later – it’s fine, since it’s built with MSVC 2005 and that compiler has a minimum OS requirement of Windows 98, to say the least. The real thing I don’t like is v3.5 . It’s built with MSVC 2008, and, as I’ve said in an earlier post, requires Windows 2000 or later.

One important item to point: in industrial automation, the time used for executing MSIL code often isn’t tolerable.

I guess the v3.5 runtime is bloated more than twofold over v2.0. The latter’s already fine for me, so why install a newer one?

There aren’t any issues with the .NET framework under Vista, since they’re pre-installed. To say, though, I, like many other users, don’t like Vista – it’s bloated on two sides: disk usage and memory usage, and the more important issue is compatibility.

Even with the v2.0 framework installed on my machine, I still stick with developing native C++ code, with a VC2005 compiler (since I recently began hating VC2008), and I can use Adobe Flash for my UI needs.

And I’m making all of my DLLs in my libraries in native x86/x64 code.