Future C: OOP

The Internet bypassed one interesting piece of news : it became known that, probably, OOP tools, namely classes, will be added to the next C programming language standard. At the same time, it is 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 implement this came back in 1995 by a certain Robert Jervis, but was accepted at WG14 only now.

Let's try to share 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 OOP it is almost impossible to do anything wisely. So, GTK + uses OOP simulation through GObject.

Hello world!
#include 
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 see a classic picture for C - data management on the stack through pointers. This requires additional attention to the declaration of these same pointers. It will also significantly affect the maintenance of the code.

Instead, one could use the “native” development approach, as implemented in GTKMM (C ++).

Hello world!
//HelloWorldWindow.h
#ifndef HELLOWORLDWINDOW_H
#define HELLOWORLDWINDOW_H
#include 
#include 
// 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 
#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 
#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, no doubt, looks more verbose, but the problems inherent in pointers disappear, such as memory leaks, dereferencing errors, deletion of NULL pointers. We also immediately get the benefits of OOP, such as encapsulation, polymorphism, and inheritance. This clearly finds application in this area, especially inheritance.

Low level programming


One of the main niches that this notorious language occupies. You can solve a similar problem in C in different ways, but the most common is direct access to the machine registers.

PORTD = 0xff;

But this contains obvious disadvantages: the ease of making a typo, generates a repeating code, unreadability and complexity of maintenance.

It would be more convenient to implement a simple class.

class led {
public:
	led: port {*s}{/*..*/}
	ledOn(number) {/*...*/};
//...	
};

And further create an object for each port. You can also add additional parameters to the constructor that determine the port settings, not to mention a huge variety of all kinds of methods for complex manipulations, for example, all port bits.

Problematic issue


In any case, the scope of this tool is obvious. They expand 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 that many even when reading the title had internal dissonance, because for this there is C ++. But will this limit C itself? Who should it hurt? The language is not so young anymore, I managed to create a lot of stable stereotypes, but the time is passing, the time has come to change, and take the need for granted.

Also popular now: