Future C: OOP
The Internet has bypassed one interesting news : it has become known that it is likely that OOP resources will be added to the next C programming language standard, namely, classes. At the same time, it is still too early to judge whether this will be implemented, since this document was not finally adopted and was not added to the draft version of the next standard. The proposal to realize this came back in 1995 by some Robert Jervis, but it was accepted at WG14 just now.
Let's try to divide the skin of an unkilled bear and see what it threatens and what it will give us.
To do this, consider a couple of areas of this tool:
Many people know that in this case, without the PLO, it is almost impossible to do anything with the mind. So, GTK + uses imitation of OOP using GObject.
')
We are seeing a classic C picture - managing data on the stack via pointers. This requires additional attention to the declaration of these very pointers. It will also noticeably affect the code maintenance.
Instead, one could use a “native” approach to development, as implemented in GTKMM (C ++).
This, undoubtedly, looks more verbose, but the problems inherent in pointers, such as memory leaks, dereferencing errors, removal of NULL-pointers, disappear. We also immediately get the benefits of OOP, such as encapsulation, polymorphism and inheritance. This clearly finds application in this field, especially inheritance.
One of the main niches that occupies this notorious language. Solving a similar problem in C can be done in different ways, but the most common is direct access to the registers of the machine.
But it contains obvious drawbacks: the ease to make a typo, generates a repeating code, inconsistency and maintenance complexity.
It would be more convenient to implement a simple class.
And in the future to create an object for each port. You can also add to the constructor additional parameters that determine the configuration of the ports, not to mention the huge variety of all sorts of methods for complex manipulations, for example, all port bits.
In any case, the scope of this tool is obvious. They extend the functionality of the language, making it not only effective, but also more convenient. From an objective point of view, this is quite necessary, but ... I think many still have an internal dissonance when reading the title, because there is C ++ for this. But does this limit C itself? Who should this harm? The language is no longer young, it has managed to create a mass of stable stereotypes, but as time goes on, the time has come to change, and to accept the need for granted.
Let's try to divide the skin of an unkilled bear and see what it threatens and what it will give us.
To do this, consider a couple of areas of this tool:
GUI
Many people know that in this case, without the PLO, it is almost impossible to do anything with the mind. So, GTK + uses imitation of OOP using GObject.
')
Hello, world!
#include <gtk/gtk.h> int main (int argc, char *argv[]) { GtkWidget *window; GtkWidget *label; gtk_init(&argc, &argv); /* Create the main, top level window */ window = gtk_window_new(GTK_WINDOW_TOPLEVEL); /* Give it the title */ gtk_window_set_title(GTK_WINDOW(window), "Hello, world!"); /* Center the window */ gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER); /* Set the window's default size */ gtk_window_set_default_size(GTK_WINDOW(window), 200, 100); /* ** Map the destroy signal of the window to gtk_main_quit; ** When the window is about to be destroyed, we get a notification and ** stop the main GTK+ loop by returning 0 */ g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL); /* ** Assign the variable "label" to a new GTK label, ** with the text "Hello, world!" */ label = gtk_label_new("Hello, world!"); /* Plot the label onto the main window */ gtk_container_add(GTK_CONTAINER(window), label); /* Make sure that everything, window and label, are visible */ gtk_widget_show_all(window); /* ** Start the main loop, and do nothing (block) until ** the application is closed */ gtk_main(); return 0; } We are seeing a classic C picture - managing data on the stack via pointers. This requires additional attention to the declaration of these very pointers. It will also noticeably affect the code maintenance.
Instead, one could use a “native” approach to development, as implemented in GTKMM (C ++).
Hello, world!
//HelloWorldWindow.h #ifndef HELLOWORLDWINDOW_H #define HELLOWORLDWINDOW_H #include <gtkmm/window.h> #include <gtkmm/button.h> // Derive a new window widget from an existing one. // This window will only contain a button labelled "Hello World" class HelloWorldWindow : public Gtk::Window { public: HelloWorldWindow(); protected: void on_button_clicked(); //event handler Gtk::Button hello_world; }; #endif //HelloWorldWindow.cc #include <iostream> #include "HelloWorldWindow.h" HelloWorldWindow::HelloWorldWindow() : hello_world("Hello World") { // Set the title of the window. set_title("Hello World"); // Add the member button to the window, add(hello_world); // Handle the 'click' event. hello_world.signal_clicked().connect( sigc::mem_fun(*this, &HelloWorldWindow::on_button_clicked)); // Display all the child widgets of the window. show_all_children(); } void HelloWorldWindow::on_button_clicked() { std::cout << "Hello world" << std::endl; } //main.cc #include <gtkmm/main.h> #include "HelloWorldWindow.h" int main(int argc, char *argv[]) { // Initialization Gtk::Main kit(argc, argv); // Create a hello world window object HelloWorldWindow example; // gtkmm main loop Gtk::Main::run(example); return 0; } This, undoubtedly, looks more verbose, but the problems inherent in pointers, such as memory leaks, dereferencing errors, removal of NULL-pointers, disappear. We also immediately get the benefits of OOP, such as encapsulation, polymorphism and inheritance. This clearly finds application in this field, especially inheritance.
Low level programming
One of the main niches that occupies this notorious language. Solving a similar problem in C can be done in different ways, but the most common is direct access to the registers of the machine.
PORTD = 0xff; But it contains obvious drawbacks: the ease to make a typo, generates a repeating code, inconsistency and maintenance complexity.
It would be more convenient to implement a simple class.
class led { public: led: port {*s}{/*..*/} ledOn(number) {/*...*/}; //... }; And in the future to create an object for each port. You can also add to the constructor additional parameters that determine the configuration of the ports, not to mention the huge variety of all sorts of methods for complex manipulations, for example, all port bits.
Problematic issue
In any case, the scope of this tool is obvious. They extend the functionality of the language, making it not only effective, but also more convenient. From an objective point of view, this is quite necessary, but ... I think many still have an internal dissonance when reading the title, because there is C ++ for this. But does this limit C itself? Who should this harm? The language is no longer young, it has managed to create a mass of stable stereotypes, but as time goes on, the time has come to change, and to accept the need for granted.
Source: https://habr.com/ru/post/253274/
All Articles