User:Mjwitte/U++ Framework

Ultimate++ (U++) is a C++ cross-platform rapid application development framework that includes several libraries for various functionality and a fully-featured integrated development environment (IDE), TheIDE. It is based on the C/C++ runtime; however, it is designed to be coded more like a scripting language, ensuring an increase in developer productivity.

History

Development of the U++ framework and toolset began in 1998 by authors Mirek Fídler, Koldo Ramirez, Tomáš Rylek, Daniel Kos, and Massimo Del Fedele. It has continued now for 17 years, with the latest stable release version released in March of 2015. Throughout the development cycle, the authors and contributors used their own framework for other professional development to better analyze pitfalls or shortcomings. If they felt even a minor aspect of the framework could be improved upon, they "never hesitated to compromise [their] entire code-base." Because of their willingness to effect massive changes, the development process was slow but precise. After 17 years of development, U++ boasts that is a mature library with most interfaces fine-tuned to be optimal solutions. Though the framework appears to be in a solid state, the authors admit there is work to do in documentation and smoothing out the IDE.

Overview

The entire idea behind this framework is to enhance developer productivity by building on top of the already powerful and ubiquitous C/C++ runtime a layer that abstracts the more complicated aspects of application development, such as memory management and GUI design, and creates a simplified interface for working with these concepts.

Memory Management

The U++ interface binds objects to a logical scope, so once that object leaves its scope, U++ handles the destruction. The implication of this is a reduced need for the new and delete operators. Raw pointers are still valid, but it is recommended to only use them to point to objects as opposed to managing resources. Because the framework manages the resources, it alleviates confusion regarding ownership of those resources. Smart pointers, like boost::shared_ptr are nonexistent in the U++ framework and their use is considered a bad practice.

Container Implementation

A common point of criticism for U++ is its overwhelming lack of the C++ standard library (STL) in its implementation. Their defense is that the STL's requirement that every container implement a copy-constructor is one that is difficult to use in GUI development. To solve this issue, U++ implements two general flavors of containers: vectors and arrays. The vector flavor is a container implementation for elements of a specific type, while the array flavor has no requirements for element types. The looser type restriction on the array flavor comes at a slight performance decrease.

GUI Widgets and Dialog Templates

A powerful consequence of the U++ memory management scheme is that widgets within the GUI are owned by client code as opposed to by the GUI itself. Because of this, the GUI neither creates nor destroys these widgets; it just references them. This implies that widgets are not created on the heap, and therefore do not require any cleanup after the GUI falls out of scope. So instead of

struct MyDialog {
   Option *option;
   EditField *edit;
   Button *ok;
};

we get

struct MyDialog {
   Option option;
   EditField edit;
   Button ok;
};

Because the GUI only has references to the widgets, they persist beyond the creation or destruction of the GUI. Developers could reference the widgets within MyDialog even if MyDialog is closed or not yet open.

The GUI's themselves are defined by layout templates, which can be edited using TheIDE's Layout Designer. The Layout Designer will produce a C++ template that inherits from some other widget-based class complete with member variables and a matching function to spatially set up the GUI (InitLayout). An example template would look similar to:

template <class T>
struct WithMyDialogLayout : public T {
   Option option;
   EditField edit;
   Button ok;
};

template <class T>
void InitLayout(WithMyDialogLayout<T> *layout, ...);
// implementation details omitted

The advantages here are that any widget type can act as a base class and the developer no longer needs to interact with widget IDs or names; they can simply interact with the instance variables.

Value and Null, Display and Convert

U++ defines a polymorphic Value type that can hold the values of any basic types and be queried for that type or value. The default "empty value" is Null, which is also defined for primitive types. This allows for a greater range of behaviors when working with primitive types. It also simplifies common operations on GUI windows, such as clearing widget values, which is as simple as setting all widget Values to Null.

Display and Convert based classes act as a way to extend the behavior of Value. Convert classes perform a bidirectional convert from one Value type to another. Commonly, this conversion takes the form of a logical Value type to it's textual representation. Display classes can be used to define how Values are to be displayed in the widget.

Callbacks

The framework utilizes function-pointer-like entities called Callbacks to define actions that should be performed after some sort of interaction with a widget. The developer simply needs to define the function that should be called when an interaction occurs and associate that function with a widget in the GUI. These functions are completely decoupled from classes; they are free to exist by themselves and can be invoked without constructing any owning class. This example defines a callback for switching the value of the input field to one or two depending on the button pressed.

void MyDlg::SetEditorValue(int x)
{
   editor <<= x;
}

MyDlg::MyDlg()
{
   button1 <<= THISBACK1(SetEditorValue, 1);
   button2 <<= THISBACK1(SetEditorValue, 2);

Write a wiki page that explains its history, what it is about, what purpose it serves, why it is important to learn, how it is relevant, who uses it and current trends, how does it compare with the other development frameworks, why developers prefer it