C vs. C++

По коду сразу не видно плюс это или пререгруженный плюс

Если тип примитивный — плюс простой, если user defined, то перегруженный.

Да это просто библиотеки, возведенные(?) в стандарт

Не спорю.

Этак (с натяжкой) я могу сказать, что в сях есть SDL. Кроссплатформенно, офигенно — все дела.

Но не унифицированно. Ты используешь SDL, а я Qt5, а Вася Пупкин кроме чистого egl не признаёт способов инициализации контекста.

А это при чём тут?

ну так он мне всю дорогу объясняет что си — говно, потому что писать на нем сложно и непонятно.

я говорю что си не про то, и что есть более понятные языки, но им не тягаться с сями на низкоуровневых задачах

От библиотек, которые были написаны для языка, зависит гораздо больше, чем от самого языка.

Я всю дорогу про это и толдычу: для сей написано ВСЕ. Решительно все.

Покажи хоть один язык, где нормализация юникода вшита прямо в синтакис.

ты неправильно меня понял

у кого нас?

У тебя и разделяющих твою точку зрения. про наследование структур

я не программист. а так книжки смотрел просто.

Программист, по определению, — человек, написавший программу. Если после просмотра книжек хоть одну написал — программист. Возмножно, не профессионал, но убивший хоть раз — убийца, а написавший хоть одну программу — программист.

К моменту линковки в случае паскаля однозначно ясно, из какого модуля брать разрешаемую зависимость. В случае си же она начинает искаться по всему зоопарку библиотек - нет никакой логической связи между *.h (которые обработал ещё препроцессор) и *.a (которые обрабатывает уже линкер).

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

C/C++ же заставляют махать кувалдой всякий раз, когда хватило бы лёгенькой киянки.

Ну. На мой взгляд инклуды и дефайны простой и понятный инструмент. То есть я бы не назвал это кувалдой.

в современном паскале точно так же есть макроопределения, условная компиляция и инклуды.

А я знаком, да.

Так вот, у хорошего мастера в инструментарии вполне может быть сильно больше одного молотка.

А кто ж спорит.

Кстати, вспомнил. Вродь у китайцев есть пословица: когда в руке молоток, любая проблема кажется гвоздем.

Тебе ограничения в глаз попали. Типы не ограничивают.

Ты просто с конца начал читать, похоже. Я и не считаю что типы ограничивают. Тут мне наприписывали уже дьявольских ярлыков.

Разговор начался с того что в Си слабая типизация, я не согласился, мол это фича такая. Ну и скатилось все к тому что я против типизации, так это выставлено. Ниче я не против. Я против когда мне не дают данные по битам разобрать и сделать как мне нужно. Этот (не будем показывать пальцем) видимо думает, что я вообще без типов живу. Не знаю как он себе это представляет.

давай пример где ты ограничен, посмотрим.

не совсем про типизацию, но про высокоуровневые языки vs си

Однажды нужно было мне на PHP обработать на сайте большой текст за раз, обработать несколько хитро, так, что если попытаться описать обработку на регулярках, то получалось слишком жирно по памяти и веб сервер выдавал ошибку на больших текстах. Тогда я пошел в лоб: решил разобрать по буквам и обработать текст прямо на php. ну реализовать логику обработки, так, как если бы я делал это на языке с жесткой типизацией. и обломился, ибо массив букв в php весит в сотни раз больше, чем в си.

Но я не жалуюсь: в php есть ассоциативные массивы, они очень удобны. Но за удобство приходится платить — это логично

Странный аргумент: везде можно написать комментарий в котором русским по белому можно объяснить просмотрщику исходников что ты тут тваришь, что с типами, что без

Хорошо что есть русский язык. Когда язык программирования ограничен, ты предлагаешь дополнить его русским, браво. А компилятор у тебя тоже по русски может? Деградация же. Распространяй тогда бинарь и файл с русским, зачем си? В машинных кодах ничего лишнего.

эээ... а ты предлагаешь не писать комментарии? Писать код настолько выразительно, чтоб комментарии были не нужны?

А компилятор у тебя тоже по русски может? Деградация же. Распространяй тогда бинарь и файл с русским, зачем си? В машинных кодах ничего лишнего.

ЯННП: я написал, что когда код недостаточно ясен для прочтения человеком, нужно писать комментарии. Для людей. При чем тут компилятор?

при этом ещё в наглой форме высказываешь своё мнение и т.д

О как распетушился-то! Я правильно понимаю, что это ты будешь определять можно мне тут свое мнение высказывать или нет? Ты ничего не перепутал? Ты тут кто? Чем-то лучше меня? Давай расскажи.

В общем тебе - лоботомия, не моможет - в морг, на том и закончим.

Иди с мамой своей так разговаривай. Шибко высокого ты о себе мнения, я смотрю. Будешь тут еще мне определять кому лоботомия, а кому в морг.

Я сразу написал, что не сишник ни разу. А ты всю дорогу корчишь из себя эксперта. Я свой нубский код вывалил, а ты свой божественный не смог сочинить, объяснив это тем, что я не достоин твоего времени.

Бесполезно «такому чудаку» что-то доказывать? Ну и проходи мимо. Тебя сюда силой тянут рассказывать какой ты умный?

Вот это, кстати, миф. Драйвер прекрасно можно написать на чем угодно

Расскажи подробнее. Не могу представить как можно pci-драйвер для linux написать на высокоуровневом языке. Нужно же, чтоб сишные указатели понимал и при этом был откомпилирован (не транслировался на ходу)

Это неправда. Питон может драйвер.

Драйвер, эта та штука, которая байты из ОЗУ в память пользователького pci-устройства перекладывает и прерывания отрабатывает?

Питон так может?

Да ничего особенного. Классы какие-то, наследования, шаблоны, констэкспры, RTTI, move-семантика. Нинужно!

Без иронии. Я не говорил что нинужно, я хотел выслушать почему нужно.

И Си тоже нинужно, можно на ассемблере писать.

Этого довода ждал на первой странице ) он логичный )

Какой-то унылый вброс

Я не веселиться вбрасывал.

Намного интереснее было бы что-то вроде «Зачем кто-то пишет на этом устаревшем Си, когда есть C++? Ведь C++ это почти надмножество Си, но в замечательных плюсах есть еще фича№1, фича№2, фича№3 ...»

Ну я-то как раз понимаю зачем люди пишут на плюсах. Но и тех кто пишет на си понимаю тоже.

Ну вот и у меня приблизительно такое мнение. На фоне того, что ты сказал, возвращение к истокам не кажется таким уж безумием.

// что на аве? что-то общеизвестное? Какая-нибудь культовая советская микруха?

По коду сразу не видно плюс это или пререгруженный плюс

Если тип примитивный — плюс простой, если user defined, то перегруженный.

Спасибо, товарищ Капитан )

Этак (с натяжкой) я могу сказать, что в сях есть SDL. Кроссплатформенно, офигенно — все дела.

Но не унифицированно. Ты используешь SDL, а я Qt5, а Вася Пупкин кроме чистого egl не признаёт способов инициализации контекста.

Ну в этом случае я не вижу ничего дурного. Кто что хочет, тот то и использует. И SDL и Qt вещи довольно популярные. Все их знают, все умеют, считай что стандарт.

Это, как раз, одна из самых сильных частей C\C++ — библиотеки. Тем более часто совместимые. Я лично SDL использовал и на си и на плюсах.

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

У меня в институте был доставляющий случай в сишке. Дело было под ДОСом. Я использовал функцию, кажется, fabs(), но подключил неправильный заголовочник (в справочнике была ошибка, кажется, я написал #include <sddlib.h> вместо math.h). Компилятор (турбо си начала 90-х), не найдя прототип функции, сгенерировал прототип по умолчанию, с интовым аргументом и интовым же результатом. Потом линкер эту функцию в библиотеке, естественно, нашёл, и она вызывалась, но из-за несоответствия параметров портился стек.

Вишенкой на торте было то, что функция использовалась исключительно в условии цикла do-while в критерии сходимости итерационного алгоритма. Т.е. функция запускалась, бодро считала, причём промежуточные результаты были абсолютно правильные, но по мере порчи стека всё начинало тормозить, и в конце концов программа вешалась (кажется, вместе с ДОСом). Я НЕДЕЛЮ искал, где ошибка. При том, что прототип на паскале был написан и отлажен за вечер.

А, ещё вот такая дивная хаутушка по одному очень популярному и пугающему новичков сообщений об ошибке. Там, правда, на тараканов C++ накладываются ещё тараканы Qt, но корни проблемы схожие.

Отсюда же совет принимать живительный ребилдол при непонятно откуда взявшихся ошибках сборки. (И ведь помогает!)

Я не против #include там, где он действительно нужен. Но расходовать его как изоленту для костылей отсутствующей модульности в 2018 году слегка подбешивает.

На мой взгляд инклуды и дефайны простой и понятный инструмент.

Он простой по своей сути. Но вот описанное применение его приводит к далеко не простым и неоднозначным последствиям.

Вродь у китайцев есть пословица: когда в руке молоток, любая проблема кажется гвоздем.

Угу, это использовалось в те же 90-е в рекламе не то у сана, не то у силикон графикса.

убивший хоть раз — убийца, а написавший хоть одну программу — программист.

А вот это хорошо сказано, прямо хоть в квотезы вешай.

О как распетушился-то! Я правильно понимаю, что это ты будешь определять можно мне тут свое мнение высказывать или нет? Ты ничего не перепутал? Ты тут кто? Чем-то лучше меня? Давай расскажи.

Тем что имел опыт не только с C и паскалем и не только в шараге. Тем что не привожу абсурдные аргументы. Тем что знаю то, чего ты не знаешь. Тем что не объявляю ненужным то, чего не понимаю. Можно продолжить, но зачем? Тебе же без разницы, ты же у мамки наверняка знаешь что всё плохо, кроме постной сишки.

Иди с мамой своей так разговаривай.

С твоей пообщаюсь, нечего детей в интернеты пускать :D

Я сразу написал, что не сишник ни разу. А ты всю дорогу корчишь из себя эксперта. Я свой нубский код вывалил, а ты свой божественный не смог сочинить, объяснив это тем, что я не достоин твоего времени.

А ты не спрашивал. Но впрочем эквивалент твоего враппера был, на расте в одну строчку. Не долбись в глаза.

Бесполезно «такому чудаку» что-то доказывать? Ну и проходи мимо. Тебя сюда силой тянут рассказывать какой ты умный?

Да, действительно, я просто не смог мимо такой годной столовой пройти, пойду дальше.

Наличием таблицы виртуальных методов (Если таковые имеются)/Полиморфизмом.

class Foo {
public:
    virtual void do_something() const = 0;
    virtual ~Foo() = default;
};

class Bar : public Foo {
public:
    virtual void do_something() const override {
         printf("Quack!");
    }
}

class Baz : public Foo {
private:
    int m_some_number;

public:
    virtual void do_something() const override {
        printf("I contain this number: %d", this->m_some_number); 
    }
}

void make_it_do_something(const Foo *foo) {
    if(foo != nullptr)
        foo->do_something();
}

int main() {
    Foo * bar = new Bar();
    Foo * baz = new Baz();
    delete baz;
    delete bar;
}

А то что ты называешь наследованием - это агрегация/композиция, а не наследование.

Если я правильно понял, то RAII — не механизм языка, а — концепция программирования, которую кресты позволяют реализовать

Примерно.

само-собой оно так не работает, так нужно написать конструктор.

Конструктор тут не при чём, при чём скорее деструктор и его автоматический вызов при уничтожении временного объекта. Но это не единственный способ.

Пишу функцию освобождения памяти (обертку над free), пишу и «конструктор» в котором вызываю alexit(имя_моего_деструктора). Все.

Нет, не всё. Речь о локальных объектах которые должны освободиться сразу и гарантированно после того как перестанут быть нужны. Глобальных объектов в нормальных программах нет вовсе.

Ну давай код своей обёртки, которая позволит написать так:

void copy(char* inpath, char* outpath) {
  int fin = open(inpath);
  int fout = open(outpath);
  char* buf = malloc(bufsize);
  ssize_t s;
  while ((s = read(fin, buf, bufsize) > 0) {
    write(fout, bug, s);
  }
}

при этом после выхода из функции по любой причине fin и fout должны быть закрыты, а buf освобождён.

Что там — объект строка и методы к ней, а тут char* и набор функций для работы с ним?

А этого мало? Это позволяет, на минуту, написать

  string message = "Привет, " + username + ", у тебя " + to_string(num_apples) + " яблок";

для чего эквивалентный код на C будет занимать страницу и включать рассчёт размера буфера, его выделение, обработку ошибки при этом и пачку strcat, и не дай бог тебе хотя бы в одной из них ошибиться и получить переполнение. sprintf я тут намеренно не учитываю, потому что обсуждается общий подход, справедливый и для строк, и для хэшей содержажих двумерные массивы длинных комплексных чисел.

нафиг тебе вообще плюсы? Пиши на высокоуровневых, там и к человеческому поближе и запар поменьше

C++ как раз и есть такой высокоуровневый язык.

Мне же нравится чтоб был максимальный контроль, что Я мог все решать, всем управлять и все контролировать

Во-первых, это пройдёт когда ты напишешь первую полноценную программу. Во-вторых, C++ у тебя ничего не отнимает - выделяй вручную память, используй strcat, препроцессор и ассемблерные вставки если тебе хочется пердолиться.

И сейчас даже не обсуждаю сферы, где близость к железу критична (ядра, драйверы, микроконтроллеры), тут преимущества Си над человечным языком неоспоримы

Чушь собачья. Под AVR я пишу исключительно на плюсах, поскольку только шаблоны позволяют получать эффективный, переносимый и при этом безопасный машинный код.

Мне нравится все контролировать, поэтому Си

Повторюсь, это проходит.

читабельность не пострадала

Читабельность убита полностью. И ещё не забудь что каждую из временных переменных ты должен выделить и освободить.

Однажды нужно было мне на PHP

Мы по разному понимаем высокоуровневость, от этого разногласия. PHP, конечно же, гораздо слабее чем даже си, хотя на нем и есть что-то удобное, но имхо, лучше питон.

эээ... а ты предлагаешь не писать комментарии? Писать код настолько выразительно, чтоб комментарии были не нужны?

Комментарии - костыль. Ими можно заменить невыразительность языка, но от этого невыразительность языка не перестанет быть проблемой.

ЯННП: я написал, что когда код недостаточно ясен для прочтения человеком, нужно писать комментарии. Для людей. При чем тут компилятор?

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

Я уже согласился с аргументом что «не понятно чего ожидать от a+b» == «не понятно чего ожидать от sum(a, b)»

Не было такого аргумента. Чего ожидать от +, sum и MIN кристально ясно. Только вот MIN, реализованный макросом, на деле имеет все шансы повести себя не так как ты ожидаешь. А в C без него никак, потому что обобщённого программирования он не умеет ни в каком виде.

Я там писал о сериализации, может на питоне и не выйдет 100%, но 99% (если драйвер достаточно сложен) можно и на питоне.

На самом деле в драйвере перекладывание байтов - это только на границе (ввод-вывод). Большинство логики - это вполне себе привычная прикладная логика. Если драйвер - хелоуворд, то он будет почти полностью состоять из сериализации/десериализации и это удобно на си. Но чем сложнее драйвер тем меньшую долю там это занимает. В питоне достаточно будет функций write_word(address, word) и read_word(address), но это не точно, не знаком близко с питоном.

Драйвер прекрасно можно написать на чем угодно.

Драйвер можно прекрасно написать на всём, у чего есть биндинги к API ядра, а они есть только у Си. И, кстати, написанный драйвер должен еще нормально работать (как минимум - быстро).

В написании драйверов системная задача одна - сериализация.

Что за глупость.

// что на аве? что-то общеизвестное? Какая-нибудь культовая советская микруха?

Сумматор это. Два бита прибавляет к двум битам.

Драйвер можно прекрасно написать на всём, у чего есть биндинги к API ядра, а они есть только у Си.

Это если линукс.

(как минимум - быстро)

Ну да, на питоне будет медленно. Я не агитировал за питон.

Что за глупость.

Не понял.

Что за глупость.

Сходил в гугл, почитал что такое системное программирование.

whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both

А я почему-то думал что это взаимодействие с внутренностями системы. По общепринятому определению я был не прав.

Офигеть, как понятно, да! Модифицируй теперь пример на A*x + x*y, где A — матрица, x,y,z — вектора. Напоминаю, что сложение скаляра с матрицей определено как добавление скаляра ко всем компонентам вектора.

Естественность тут вторична, по отношению к программированию.

Ты идиот. Программирование ради программирования никому не нужно, поэтому есть DSL, формулирующие и решающие проблемы в терминах предметной области. На C++ можно относительно удобно написать свой DSL, например для матричной или кватернионной алгебры, на C такое гораздо менее удобно.

Только программы получатся жирнее и медленнее,

Скорость — не главное в большинстве задач. Главное, это *получить* решение и *правильное решение*, а не запутаться на этапе выделения памяти для 15-мерного массива.

но это ничего, главное бедного программиста-недотепу от выстрела в ногу уберечь.

Насмешил. Уж куда как легче выстрелить в ногу на C, просто неправильно высчитав смещение для указателя.

C вообще может оказаться нужен только на последней стадии, когда решение получено, отлажено и отполировано. Тогда уж можно подумать, что стоит потратить еще человеко-ресурсов на перепысывание ЭТОГО на C.

Когда кто-то перегружает оператор, он занимается неявным вызовом функции.

Когда не перегружает - то тоже, просто эта функция сразу превращается в вызов соответствующей «функции» процессора. Сейчас компиляторы C и C++ все инлайнят.

Только программы получатся жирнее и медленнее

Перегрузка операторов никак не влияет на производительность. Есть очень много «почти» бесплатных абстракций. Особенно в c++ и rust.

Драйвер можно прекрасно написать на всём, у чего есть биндинги к API ядра, а они есть только у Си.

Это если линукс.

Назови мне ситстему не на Си.

А я почему-то думал что это взаимодействие с внутренностями системы.

А там где сериализация?

А зачем система не на си? Нужны же только биндинги, как ты и написал. Драйверы для macOS пишут на плюсах, например.

Назови мне ситстему не на Си.

А зачем система не на си?

То есть таких систем нет.

Драйверы для macOS пишут на плюсах, например.

На сильно усеченном Си++. В рамках данного топика разницы нет.

Я НЕДЕЛЮ искал, где ошибка. При том, что прототип на паскале был написан и отлажен за вечер.

Меня тоже сначала учили на паскале. И всю дорогу писать на нем было приятно. Особенно, когда вырос fpc и lazarus. Но, начинаешь такой пробовать OpenGL в Delphi и понимаешь, что все pas-файлы — просто перевод того, что было на Си. Или доки к Win32API, которые были с делфи.

Короче, волей-неволей, си изучить приходится, хотя паскаль я очень люблю. (я как-то курсач принес под фриБЗДю сдавать на fpc, так препод на меня такими глазами посмотрел, мол, не знал что паскаль вообще умеет во FreeBSD, а тут еще студент курсовую не на Си)

Я не против #include там, где он действительно нужен. Но расходовать его как изоленту для костылей отсутствующей модульности в 2018 году слегка подбешивает.

Ну это на ПК. Возможно, убедительно. Но это потому что сейчас на ПК ресурсов — хоть жопой жуй. Как только дело касается мест, где оперативки и процессорного времени не вагон — сразу же вспоминуют про си.

Но это потому что сейчас на ПК ресурсов — хоть жопой жуй. Как только дело касается мест, где оперативки и процессорного времени не вагон — сразу же вспоминуют про си.

В смысле? Как раз сишный подход жрёт при сборке то самое процессорное время мама не горюй. Сейчас действительно туда-сюда, а в начале 90-х мы, имея на работе компы с i386, сравнивали время сборки на турбопаскале и на сишных компиляторах — последние отличались просто удручающими тормозами.

Глобальных объектов в нормальных программах нет вовсе.

слишком категорично, на мой взгляд

Ну давай код своей обёртки, которая позволит написать так

По выходу из функции не могу. Признаю. Хотя, может это просто я не умею?

А так, мне прям серпом по яйцам на такой код смотреть: открытие есть — закрытия нет, память выделяется и хрен с ней... БРР!

sprintf я тут намеренно не учитываю, потому что обсуждается общий подход, справедливый и для строк, и для хэшей содержажих двумерные массивы длинных комплексных чисел.

так читерство! sprintf — часть стандартной библиотеки и в такой же степени «не часть языка» как и твой класс string.

А так да, признаю, выглядит ловчей, чем sprintf. Хотя и в последнем нет ничего страшного. Когда привыкнешь, так вообще потом его не хватает в других местах.

Во-первых, это пройдёт когда ты напишешь первую полноценную программу

Не проходит пока, даже напротив. К Си меня жизнь толкнула.

C++ у тебя ничего не отнимает - выделяй вручную память, используй strcat, препроцессор и ассемблерные вставки

А я с этим и не спорил нигде. Тут вон люди предлагают драйвера на питоне писать, мол, даже там можно в низкоуровневоть.

Под AVR я пишу исключительно на плюсах, поскольку только шаблоны позволяют получать эффективный, переносимый и при этом безопасный машинный код.

Делись опытом. Компилятор? Пример программы?

И ещё не забудь что каждую из временных переменных ты должен выделить и освободить.

Не настолько все плохо же:

float get_r(int x1, int y1, int x2, int y2) {
  float dx = x1 - x2;
  float dy = y1 - y2;
  return sqrt(dx*dx + dy*dy);
}

временные выделять и освобождать мне не надо

Комментарии - костыль. Ими можно заменить невыразительность языка, но от этого невыразительность языка не перестанет быть проблемой.

Позволю себе с этим не согласиться.

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

Хоть один проект у тебя есть без комментариев на выразительном языке? Хоть тысячу строчек?

Только вот MIN, реализованный макросом, на деле имеет все шансы повести себя не так как ты ожидаешь. А в C без него никак, потому что обобщённого программирования он не умеет ни в каком виде.

А чего, в плюсах макросы отменили что-ли? Так меня этим тыкаешь, будто сам не такой.

Криво написанный макрос — вина программиста. И функцию криво можно написать и (внимание!) перегрузку оператора

А в C без него никак

Это да

Ты идиот.

Нормальный заход. Дверь сделай мне.

Когда не перегружает - то тоже, просто эта функция сразу превращается в вызов соответствующей «функции» процессора

Вызов функции — отработка определенного механизма. Создаются копии переменных параметров, результат кладется в стек. Там определенных механизм, который нужно знать и уметь использовать. На a+b такого не происходит, просто транслируется в ассемблер

Перегрузка операторов никак не влияет на производительность

Я такого и не говорил

Как раз сишный подход жрёт при сборке

ну так то при сборке. Я имел в виду прожерливость результирующей программы.

То есть таких систем нет.

Есть и гуглятся очень быстро.

На сильно усеченном Си++. В рамках данного топика разницы нет.

На расте можно написать

extern "C" { ... }
extern "rust-call" fn foo() { ... }

А с ядра вызывать, я даже писал такое

extern "C" {
    fn security_add_hooks(hooks: *mut CSecurityHookList, count: usize, lsm: *mut u8);
}

...

impl SecurityModule {
    pub fn add(
        name: &'static str,
        hooks: &[SecurityModuleHook],
        heads: &mut vmalloc::Array<HListHeads>,
    ) -> Result<Self, ()> {
 ...
}

Вполне себе биндинг к апи ядра, все что надо пишется за вечер.

Это не драйвер, но так можно написать драйвер.

Сперва добейся? Есть, но это не аргумент и не относится к разговору.