Почему драйверы и прочую системщину пишут, в основном, на C, а не на C++?

Сишное ООП ООПом не является: нет основных принципов (наследования и т.п.).

struct Parent {
    int a;
    int b;
};

struct Child {
    struct Parent _p;
    int c;
};

Не выдумывай. Это — не ООПщина. Ты не сможешь из Child вызвать метод Parent без указания члена _p.

А виртуальные функции? А шаблоны?

Чем кресты не подходят?

libstdc++, libunwind и прочую хрень в ядро тащить западло.

std можно обрезать.

Обрезай. Тебе за это памятник при жизни поставят.

Потому что ООП в системщине особо и не нужно.

Драйверы пишутся на том, на чем написано ядро, чаще всего. Ну и потому что в драйверах чаще всего тупой код.

Почему драйверы и прочую системщину пишут, в основном, на C, а не на C++?

Кто такое сказал? Под офтопиком уже давно используют плюсы в драйврах. Ну а онтопик просто очень древен.

А в какой такой ООПщине я смогу вызвать метод производного объекта, имея только базовый?

виртуальные функции

struct vtable_Child *vtable;

шаблоны

Это не ООП

А в какой такой ООПщине я смогу вызвать метод производного объекта, имея только базовый?

Разве в плюсерах не так? Если ты создал класс, наследующий другой класс, то из этого класса ты можешь напрямую вызывать public методы родителя. Не?

Не выдумывай. Это — не ООПщина. Ты не сможешь из Child вызвать метод Parent без указания члена _p.

А это не принципиально. В C++ ты не можешь вызвать метод без ".", "::" или "->" - аргументация того же уровня. Это просто синтаксический сахар, который к ООП никакого отношения не имеет.

А виртуальные функции?

Так же, как под капотом C++ - указателями.

А шаблоны?

А это к ООП вообще не относится никаким образом.

По моему скромному мнению, просто фичи C++ будут оверхедом.

Короче, вы с intelfx меня не переубедите. нет никакой ООПщины в сях. Даже glibc — не ООПщина (хотя гадость редкостная, не скрываю). ООП — это С++, жабка и прочие говноязычки для создания гуеинтерфейсов. Во всех остальных случаях хватает нормального С.

Имея производный объект, можно вызвать базовый метод. C++:

struct Parent
{
    void function_in_parent();
};

struct Child : Parent
{
    void function_in_child()
    {
        function_in_parent();
    }
};

C:

struct Parent
{
};

struct Child
{
    struct Parent _p;
};

void function_in_parent (Parent *p);

void function_in_child (Child *c);
{
    function_in_parent (&c->_p);
}

А обратно нельзя ни там, ни там, ни вообще в принципе.

glibc

glibc?

вы <...> меня не переубедите

Спору нет, не переубедим. Вот только ты всё равно не прав.

ООП — это С++, жабка и прочие говноязычки

Нет. ООП — это всё, что отвечает трём формальным критериям. Язык реализации не важен.

В С ООП это подход к разработке, а не инструменты языка http://lwn.net/Articles/444910/

ООП — это всё, что отвечает трём формальным критериям

Каким?

А то у меня тоже чуть ли не в каждом втором велосипеде уйма структур, связанных структур, структур с указателями на функции (чтобы менять методы в зависимости от типа переменной) и т.п. Но я это ООП не считаю.

Пардон, четырём.

dynamic dispatch, abstraction, subtype polymorphism, and inheritance

Вот в сях нет наследования, т.к. вызов метода из члена-структуры какой-то структуры ничем не отличается от вызова этого метода напрямую.

Про остальное тоже не могу согласиться.

Я только что показал, как наследование делается в C. Наличие или отсутствие в языке синтаксического сахара для этого совершенно не играет роли.

Если твоя программа делает что-то подобное — то она уже написана в стиле ООП.

Любой придуманный человеком ЯП убог и ужасен, а значит разницы нет.

нет никакой ООПщины в сях

https://developer.gnome.org/gobject/stable/chapter-gobject.html

Начни вот примерно отсюда.

Еще раз: вызвать a.b->c — это тебе не вызывать a.c. Вот если бы ты мог вызвать a.c, то это было бы наследованием. А так — никакой разницы, напишешь ты a.b->c или напрямую g->c, где g = a.b

Золотые слова. Да и там от неё только путаница.

Я про glibc уже ниже писал

Наследование — это то, как организованы структуры данных и алгоритмы, а не тот или иной синтаксис в языке.

glibc

glibc это http://www.gnu.org/software/libc/

Ещё раз: glibc?

Тьфу, glib же!

Потому что Торвальдс не одобрит.

Ну и потому что в драйверах чаще всего тупой код.

Тупой или нет, а параметризованные типы пригодились бы.

&c->_p

В сишечке же есть особая уличная магия (с первым членом структуры) и можно писать просто c

Хороший, годный вброс. Подписался.

Да и там от неё только путаница.

Ну не знаю. Лично мне гуйню на C++/C#/Java etc. распарсить намного легче, чем лапшевидный C-листинг с callback'ами мимикрирующий под ООП на несколько тысяч строк:

https://git.gnome.org/browse/gnome-builder/tree/src/editor/gb-editor-frame.c

ООПщина нужна лишь в гуйне.

ООПщина не нужна даже в гуйне, потому что умные люди придумали такую вещь, как функциональное реактивное программирование.

Она стандартизирована или как обычно «ну, эээ, все компиляторы так делают, потому что это логично»?

нет

потому что умеют. Ваш КО.

class task {
public:
  virtual void exec() = 0;
};
class specialTask : public task {
  virtual void exec() {
    // do something
  }
};

void f() {
  vector<task*> tasks;
  ...
  for(task* t : tasks)
    t->exec();
}

А такое на сях изобразить?

Not this overhyped shit again. Покажи хоть один серьёзный gui-проект на этом. (Примеры реактивного банана я видел и читал, если что).

А type-safety не нужно? Не?

http://stackoverflow.com/questions/7312555/in-c-does-a-pointer-to-a-structure...

Что это?

Даже glibc — не ООПщина

Потому что это реализация стандартной библиотеки C, дебил

void f(FILE *f) {
}

f("blah blah"); // c++ - error

на плюсах такой код не скомпилируется, на си - запросто.

Ну вы сравнили одну особенность против целой пачки.

Реативщину сейчас в основном для веба используют. Десктопный GUI до этого не созрел, к сожалению.

Быть такого не может!

Вот тебе доказательство:

15.01.22 19:56 /tmp
cat 1.c
#include <stdio.h>
#include <stdio.h>

void f(__attribute__((__unused__)) FILE *f) {
}

int main(int c, char **v){
    int i;
    f("blah blah"); 
    if(c>1){
        printf("%d arguments:\n", c-1);
        for(i = 1; i < c; i++)
            printf("%d: %s\n", i, v[i]);
    }
    return 0;
}
15.01.22 19:57 /tmp
gcc -Wall -Werror -Wextra 1.c 
1.c: В функции <<main>>:
1.c:9:5: ошибка: в передаче аргумента 1 <<f>>: несовместимый тип указателя [-Werror]
     f("blah blah"); 
     ^
1.c:4:6: замечание: expected <<struct FILE *>> but argument is of type <<char *>>
 void f(__attribute__((__unused__)) FILE *f) {
      ^
cc1: all warnings being treated as errors

Что это?

Эдик, ты - упёртый дебил. Разоплотнись отсюда подальше.

А вот так — нормально:

15.01.22 20:02 /tmp
cat 1.c
#include <stdio.h>
#include <stdlib.h>

void f(FILE *f) {
    if(!f) return;
    char *line = NULL;
    size_t len = 0;
    ssize_t read;
    while ((read = getline(&line, &len, f)) != -1) {
       printf("%s", line);
    }
    free(line);
    fclose(f);
}

int main(int c, char **v){
    int i;
    FILE *fl = fopen("1.c", "r");
    f(fl); 
    if(c>1){
        printf("%d arguments:\n", c-1);
        for(i = 1; i < c; i++)
            printf("%d: %s\n", i, v[i]);
    }
    return 0;
}
15.01.22 20:02 /tmp
gcc -Wall -Werror -Wextra 1.c -o test && ./test
#include <stdio.h>
#include <stdlib.h>

void f(FILE *f) {
    if(!f) return;
    char *line = NULL;
    size_t len = 0;
    ssize_t read;
    while ((read = getline(&line, &len, f)) != -1) {
       printf("%s", line);
    }
    free(line);
    fclose(f);
}

int main(int c, char **v){
    int i;
    FILE *fl = fopen("1.c", "r");
    f(fl); 
    if(c>1){
        printf("%d arguments:\n", c-1);
        for(i = 1; i < c; i++)
            printf("%d: %s\n", i, v[i]);
    }
    return 0;
}