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." [1] 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. [2]
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. [3]
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. [4]
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.
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