Z++ Unique Features:

Z++ makes it even easier to develop high quality mobile and enterprise software applications that are capable of running on multiple Operating Systems without all the confusing 3rd Party Libraries, Emulators, or multiple SDK's (Software Development Toolkits).

Highlights are:

• Macros – Can be debugged just like Functions.
• Tell and Hear – Communication signaling for Concurrent Communicating Processes, Web Services and Asynchronous Function Calls.
• Task Threads – Can specify handlers for Tell and Hear communication signals, as well as other types of signals including entire signals.
• Mutex – As a built-in type and independent of the underlying operating system.
• Collection Shared Method - A collection object invokes a shared method on all of its (class) object values.
• Task Idler - An instance of task (threaded) will execute its special method idler when there are no requests to service.
• Task Signal Handler - A task object automatically responds to signals generated by any thread.
• Atomic block (Mutual Exclusion) - A thread executes an atomic block of statements without interference by any other thread.
• Debug block and break (Assert) - A debug block is only executed in a debug compiled executable. In addition, break (boolean) will act as a break point when the boolean expression fails (in debug mode).

Unlike C++, in Z++ macros are debugged just like functions. During a debug session nested C++ macros act like a black box. One advice is to avoid the use of macros altogether. However, macros have many legitimate uses in code reuse without the overhead of function calls. On the other hand, the inline mechanism is a request to the compiler, which may not be honored.

Tell and Hear signaling is a unique form of communication among distributed components of a process, as well as among applications running on a heterogeneous system of nodes. For a discussion and illustration of notions of Asynchronous Function Calls and Concurrent Communicating Processes with regard to Tell and Hear signaling please see the Z++ Language Reference (Download Reference Manual).

Tasks, object-oriented threads, can now specify handlers for all kinds of Z++ signals, including Tell and Hear communication signals. The task handler mechanism includes automated mechanisms that require implementation for global threads.

In certain situations the use of mutex is indispensable. Relying on the Z47 Distributed Operating System, the Z++ language provides the notion of mutex as a built-in type, for all platforms

In many solutions, classes modeling are not necessarily related through inheritance hierarchy. Collection type is an extension of enumeration type, which takes classes for its values. Among many useful features, collections introduce the notion of a shared method. A shared method, as its name indicates, is shared among all classes of a collection. When a shared method is called on a collection object, the call invokes the method on each of the values of the collections.

The compiler generates the body of a shared method for a collection. This eliminates the possibility of obscure errors and the need for debugging such errors. Since collections can be derived from other collections, the compiler ensures the correct invocation of shared methods at each level of derivation.

Z++ tasks provide an object-oriented abstraction for modeling multi-threaded solutions. An instance of a task runs in its own thread, queuing requests for invoking its public methods. When a task object does not have any outstanding requests it simply gives up its execution time slice.

Frequently, a solution requires periodic checking or updating activities. The notion of Z++ task idler provides an intuitive mechanism for accomplishing these activities without resorting to critical sections.

A task idler is a private method that is automatically invoked by a task object. Each time a task object receives its time slice, and does not have other outstanding tasks, it invokes its idler method before giving up its time slice.

Z++ provides extensive intuitive support for signaling as an inter-thread communication model. A task signal handler is yet another versatile mechanism for inter-thread communication.

A task signal handler is a private method of a task that has been designated to respond to a particular signal. A task can have any number of signal handlers. A task object checks for the arrival of signals, and, if one of its signals has been generated, it will invoke the corresponding handler to respond to the signal.

Task signal handlers provide an excellent model for inter-thread signal handling mechanisms. Since the compiler enforces the abstraction many obscure defects are avoided. In particular, debugging such defects in a multi-threaded program is excessively time consuming.

Z++ abstractions of threading and inter-thread communication alleviate the need for coding and testing complex cases of mutual exclusion. Some solution models, however, may require a thread to complete an entire sequence of statements before any other thread gains access to the Z47 Virtual Processor.

When a thread enters an atomic block, the Z47 Virtual Processor guarantees uninterrupted execution until the thread completes all the statements within the atomic scope. An atomic block also models critical section, as well as mutual exclusion.

The Z++ break (boolean) is the equivalent of assert in other languages. When the break expression fails, program execution stops at the break statement as if the user had put a break point there.

More often than not, a simple break statement is not adequate for debugging a complex program. A Z++ debug block can contain any number of statements that will only execute in debug mode. A debug block allows writing expensive code that is not needed for the release version of the program. In a debug session one can step through the code and find the problem points, while in release mode those statements will not execute.