Introduction Cpp Qt Enviroment

Introduction

In GNU environments, C++ compilation is based on a tool called gcc. Within gcc, there are sub-tools such as g++, which is responsible for taking source code files (.c and .h) and automatically linking them to the necessary C++ libraries. Using the g++ command line, you can apply the following command options:

1. -Wall: Enables additional warnings during the construction of objects that may be questionable but still conform to the C++ standard.
2. **-o :** Specifies the name of the executable file. By default, if this option is not defined, gcc creates an output object named a.out.
3. man g++ or info g++: Provides manuals and detailed information about additional commands and options available in g++.

To execute the output object generated by g++, use the command ./a.out in the terminal.

Qmake

As in any project, in Qt it is necessary to have a tool that builds executables through the compilation of source code and linking of any dependencies. This requires a precise specification of inputs, intermediate tools based on use cases for building, and an output target specification. One of the most commonly used utilities for this is make. Make reads all the details of a project from a special file called a makefile, which contains:

1. Rules for building different types of files.
2. A list of all the source files **and **headers needed for the project.
3. The target, specifying which executable, library, or dependency will be built.
4. Dependencies, listing which executables need to be rebuilt when a specific file has been modified.

Qt includes a derivative of make called qmake, which is very similar to make but enables the definition of a project file (.pro) that is easier to use within the Qt environment and framework.

https://github.com/CharlieHdzMx/QtProjects/blob/74228842151dd26094f96d52bb760f8c5b265221/FactDialog/mainApp.pro#L11C1-L21C42

The HEADER section specifies whether the project is an APP, LIB, or SUBDIR:

1. For an APP, the output is an executable file.
2. For a LIB, the output is a library, based on the specified output configuration.
3. For a SUBDIR, it indicates that this is a parent .pro file, which will include sub-project .pro files with their own configurations.

Include headers

Qmake recognizes headers when the project file includes an INCLUDEPATH += dirName directive, allowing new headers or dependencies to be added to the project. Qt, like C++, supports three different ways of including a header in the source code:

1. _#include _: This first searches for the header sequentially in the **"include path,"** where the C++ standard implementation is typically located.
2. #include “headerName”: This attempts to find a header with the name headerName in the include paths and HEADERS specified in the project file.
3. #include “seqPath/headerName”: This searches first in the specified seqPath for a header with the name headerName.

When there is a name conflict with headerName, qmake uses the first header it finds. If it cannot locate any headerName, qmake will fail to produce a new executable and will return an error for the project.

Main Functon Arguments

In C++ and Qt, the main function serves as the entry point for an application, whether it is a command-line tool or a graphical application (e.g., a widget-based app). For command-line applications specifically, arguments can be passed to the program when running the executable with additional parameters. The main function in both standard C++ and Qt applications typically defines two parameters:

1. argc: The argument count, which represents the number of arguments passed from the command line.
2. argv: The argument vector, which is an array of strings (char*) containing the actual arguments separated by spaces.

In Qt applications, it is essential to declare a QCoreApplication or QApplication object as early as possible in the main() function. This is important because it enables the event loop, allowing any events that affect or are of interest to the application to be processed promptly. The QCoreApplication class translates the console argument vector into a QStringList, making it easier to process these arguments using the QString API. In English.

Compiler and Linker

The task of translating high-level code into machine language is performed by the compiler. A code library consists of precompiled code that is ready to be linked with other code for execution, without requiring direct access to the source code. When you reuse code from a library, the linker is responsible for appropriately connecting the base code with all required libraries, thereby creating an executable tailored to a specific configuration. The resulting executable dynamically locates the libraries at runtime without embedding them directly into the executable, allowing the executable to remain small.

Interms of software there are a few reusable componetns such as: Compiled Object Module (.o or .obj): Each .cpp file is compiled into a binary object module as an intermediate step in building an executable or library. Library (.lib or .dll):

Static or dynamic libraries are indexed collections of linked object files. These libraries do not include a main() function as the program’s execution root.

Development Package (.lib + headers): A library bundled with its header files.

To improve compilation times and enhance module reusability, it is crucial to minimize dependencies between classes and/or libraries.

Design Patterns

Design patterns are categorized into three main types:

Creational: Focuses on organizing code that handles object creation. Structural: Specifies how to organize objects and connect them appropriately. Behavioral: Defines how to organize code for managing behavior.

Antipatterns

Antipatterns are inefficient or counterproductive programming practices such as

Software Design Antipatterns

Input Kludge: Failing to specify and implement handling for invalid input values. Interface Bloat: Designing an interface so powerful and complex that it becomes difficult to reuse or implement. Race Hazard: Failing to account for the consequences of concurrently triggered events occurring in different orders.

Object-Oriented Antipatterns

Circular Dependency: Introducing unnecessary mutual dependencies between objects or software modules. God Object: An object that has too many responsibilities or contains excessive information.

Programming Antipatterns

Hard Coding: Embedding static implementation assumptions in the system. Magic Numbers: Including unexplained numerical constants in the code. Magic Strings: Using unexplained string literals directly in the code.

Methodological Antipatterns

Copy-and-Paste Programming: Copying and pasting code without reviewing edge cases or attempting to create more generic solutions. **Reinventing the Square Wheel: ** Failing to adopt an existing, adequate solution in favor of a custom solution that performs worse than the established one.

Observer Pattern

QApplication

A QApplication does not follow a purely sequential execution model but is instead event-driven. Events are QObjects that communicate with each other through an intermediary object. In GUI applications, when an object changes state, it often needs to quickly communicate this change to update data states and reflect current information in real-time. Observers are objects listening for changes in an object’s state; these changes are referred to as state-change events. Enabling this listening mechanism is known as the Observer Pattern or Publish-Subscriber Pattern. Key characteristics of this pattern include:

1. Decoupling dependent classes (observers) from subject classes.
2. Supporting broadcast communication (one-to-many communication).
3. Defining how subjects send information to observers within their base class implementation.

The base class QEvent encapsulates all events between QObjects, serving as a foundation for various event types such as QActionEvent, QFileOpenEvent, QInputEvent, and QMouseEvent. Each event type communicates specific occurrences—for instance, QMouseEvent handles drag actions, key presses, mouse movements, etc. The execution of a QApplication, or any event-driven application, relies on an event loop—a function that dispatches, queues, and prioritizes events. This loop runs until program termination, iteratively checking conditions for triggering event-based functions according to priority. An extension of this event loop mechanism is Qt’s Signals and Slots system, where signals represent events and slots define responses to those events.

Reference

[1] Ezust, A., & Ezust, P. (2006). An Introduction to Design Patterns in C++ with Qt 4. Prentice Hall. ISBN-10: 0131879057, ISBN-13: 978-0131879058.

---