C vs. C++

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

Драйвер pci написать?

Ибо это просто набор байт, а не строка.

Странное мнение. А что не набор байт?

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

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

я могу создать файл false_object.c, в нем описать static int hidden_var, описать int public_var и то же самое с функциями. на основе этого файла я могу создать child_false_object.c и дополнить его полями и функциями. как реализовать RAII я уже тоже писал.

В чем разница-то?

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

говорят в ядре линукса > 10M строк кода. И как-то без классов не запутались. Разбивай задачу на дерево подзадач. Как там можно запутаться — ума не приложу.

Hello World.
Многоэтажку или поезд тоже построишь? Огромное количество деталей, которые делаются __разными__ людьми. Блок оказался на 10см выше и на 2м короче - похрен, пляшем, сбоку припаяем? Двигатель не влезает, колёса разного размера и разными дырками отверстиями для гаек, похрен, приваришь, да?

Жирнеешь с каждым комментом, кстати.

Перегрузка операторов — офигенная вещь. Например, сложение и умножение определено для матриц и векторов, гораздо естественнее написать res = A*x+ B*y + C*z

Че вы меня этой естественностью тыкаете? А еще естественнее писать x = ab, вместо x = a*b; , = вместо == и так далее по списку. Си — язык программирования, а не поэма. Естественность тут вторична, по отношению к программированию.

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

В Си:

x = a + b; // оператор
x = sum(a, b); // функция
x = SUM(a, b); // макрос

ИМХО, перегрузка операторов — такая же пакость как маскировка макроса под функцию и аргумент что это красиво — так себе. это подло )

Код проще и нагляднее, а значит — меньше ошибок

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

а как ты структуры будешь наследовать?

struct some_struct {
  int x;
  int y;
}

^C ^V

struct child_struct {
  int x;
  int y;

  int z;
}

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

включение и наследование - это разные формы отношений

Почему? Дочерняя структура несет в себе все поля, которые были в материнской. Все функции, которые могли работать с материнской структурой, смогут и с дочерней.

Шаблоны никто не использует? Really?

Относительно, понятно. Читай как почти никто не использует.

потому что есть понятия которые именно включают в себя несколько объектов - и для этого как раз нужны вложенные структуры

нет в си понятия дочерняя структура

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

В вашей псевдо-логике есть один существенный изъян - вы всё время говорите только про себя («а я вот не вижу», «я все то же самое могу», ...). Если кроме вас с вашим исходным кодом никому другому не придется работать и сопровождать его - да ради бога, пишите хоть на Ассемблере ). Ну вот в некоторые другие проекты вам с вашей «логикой» попасть не светит - просто там такие на хрен никому не нужны. Вам только туда, где требуются именно Си-шники )

Ну и уж больно тупой вброс - неинтересно )

4 строчки с применением GLib.

он — известный мастер, изваял уже десятки статуй без маски и не забил себе зубило в глаз

Он - это ты? Сомневаюсь.

Пример можно?

А что ты умеешь такого, чего не умеет моль?

Вот строят дома из твоего бетона. А затем кто-то подаёт идею что заливать его на железный каркас - в пару раз (Не разбираюсь, на деле число другое) будет прочнее, но ты упёрт и продолжаешь использовать бетон, несмотря на его _объективно_ худшие качества.

Соглашусь, но только в том случае, если докажешь ОБЪЕКТИВНОСТЬ факта «C++ лучше C». Тут есть разные мнения. После выхода Си, языки предшественники умерли, ибо си был объективно лучше. Плюсы написали когда? А си до сих пор жив и развивается. Если звезды зажигают — значит это кому-нибудь нужно. Если кто-то развивает си не смотря на наличие плюсов и растов, значит кто-то считает что си лучше.

Я не уперт. И на плюсах я попишу и на всяком новом. Грех не попробовать: у Бога дней много. Просто на данном этапе моего развития мне видется что Си вполне достаточно, а остальное, как мне видется, только усложняет процесс.

используя C там, где можно обойтись без него ты только тормозишь прогресс

прогресс не затормозить. если бы си ему мешал, он бы его (си) перемолол

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

Я когда познакомился с ПК, дефолтной ОС был 95-й оффтопик. И казалось что по-другому быть не может. Потом вышел 98-й и прогресс был налицо: все везде усовершенствовалось. Потом 2000-я - то же самое, только лучше. Потому XP — взлет ракетой. Потом 7ка — спорный момент, а потом прогрессировать стало некуда, и стали «усовершенствования» высасывать из пальца. Добавлять обраную несовместимость и прочее. Ну ты в курсе.

Это я к чему: прогресс в отдельно взятой области конечен. По крайней мере на масштабе времени сравнимым с человеческим веком. Молоток видел? Когда его изобрели? Совершенствования были? Несомненно, даже на нашем веку молоток значительно улучшился. И материал самого молота и материал/эргономика ручки. Но это все тот же молоток, а не молоток 2.0. Разумно ли изобретать новые концепции, если старая отлично работает и гвозди все еще все забивают? (есть ведь шуруп+шуруповерт, они уделывают молоток+гвоздь по всем статьям)

Сильно многословно я. Ну думаю мысль ясна. Компьютеры не изменились. Хороший инструмент есть. Нужно его совершенствовать, без сомнений, но не заменять на нано-молот из иридия. Исследования в нано-молотной области вести надо, но пользоваться разумно молотком, который везде, а не наномолотом, который прогрессивней и никто про него не в курсе.

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

А в каком еще стиле там писать? В функциональном?

Очевидно, в объектно-ориентированном. Или ты хотел почувствовать разницу между языками, используя одни и те же синтаксические конструкции?

Под рукой нет IDE, но в общих чертах: читаем файл с помощью g_file_get_contents(), переворачиваем g_utf8_strreverse(), нормализуем g_utf8_normalize(), записываем в файл g_file_set_contents(). Ах да, ещё освобождаем саму строку, ок, не 4, 5 строчек.

Ты на каждый случай будешь писать обёртку?

Все уже украдено до нас. А так — да. Это ничем не сложнее, чем управлять исключениями в плюсах. (я, если честно, не помню как оно там) Но давай сравним: вот задача — наша программа открывает файл и работает с ним. Нужно реализовать контролируемое поведение в этом случае, в соответствии с настройкой из конфига. Либо программма выводит ошибку и завершается, либо программа пишет лог и продолжает работать. Чтение конфига и запись лога оставим за скобками, я напишу на Си, а ты обработай исключение на плюсах

int need_exit_at_fileerror = 1; // читается за скобками из конфига

// можно спрятать в отдельный файл обработки "исключений"
FILE * Fopen(char *filename, char *mode) {
  // обертка для обработки "исключения" при чтении файла
  FILE *f = fopen(filename, mode);
  
  if (f != NULL) return f;

  if (need_exit_at_fileerror) {
    perror("Ошибка чтения файла. Выход.\n");
    exit(1);
  } else {
    write_log("Ошибка чтения файла.\n");
  }
  return f;
}

int main(void) {
  FILE *f = Fopen("tux.bmp", "rb");

  // далее работа
}

А ещё создашь по новому типу результата для проталкивания ошибки по стеку?

Не нужно, как видишь. Ошибку обработали на месте.

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

А если входной/выходной файл не открылся, строка не прочиталась/записалась?
Так то уже не 4 строчки будет, но ок вариант засчитан, всё равно достаточно коротко.

Напиши код для:
.Сделать NFC нормализацию.

Кто все эти люди?

Экий ты ловкач: берешь высокоуровневую задачу и показываешь что на высокоуровневом языке ее решить проще, чем на низкоуровневом.

Парирую: напиши прошивку для AVR-программатора на си и не на си и поймешь что не на си ты ее вообще не напишешь.

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

Что ты не можешь контролировать в C++/Rust, удиви же нас!

Раст не видел ни разу. На плюсах — все то же, что и на си. Там я говорил про C\C++ vs высокоуровневые ЯП

let mut file = File::open("tux.bmp").expect("Failed to open file");
// Дела делать

Не нужно, как видишь. Ошибку обработали на месте.

В твоём синтетическом Hello World примере не нужно, про полиморфизм то хоть слышал?

Для обработки ошибок в GLib есть GError. Конечно, не плюсовые исключения, но всяко сильно удобнее, чем городить кучу if-ов. Ну и та же g_file_get_contents() вернёт FALSE, если что-то пойдёт не так.

Экий ты ловкач: берешь высокоуровневую задачу и показываешь что на высокоуровневом языке ее решить проще, чем на низкоуровневом.

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

Многоэтажку или поезд тоже построишь? Огромное количество деталей, которые делаются __разными__ людьми.

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

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

Жирнеешь с каждым комментом, кстати.

Не знаю. Тут вообще нормальных не бывает? Все обязательно приходят над вами поиздеваться. Моя цель не такая.

Кто все эти люди?

Экий ты ловкач: берешь высокоуровневую задачу и показываешь что на высокоуровневом языке ее решить проще, чем на низкоуровневом.

Да, UTF-8 строки - высокоуровневая задача? Экий ты лжец, говорил что в C есть нормальная работа со строками.

Парирую: напиши прошивку для AVR-программатора на си и не на си и поймешь что не на си ты ее вообще не напишешь.

Ты даже в собственной области умудрился обкежиться. Библиотеки Arduino написаны на подмножестве C++, проверяй. У Rust есть (пока) неофициальный порт под AVR и куча крейтов с поддержкой #[no_std](Без компонентов требующих кучи, если обобщить), проверяй. Наверняка этими двумя дело не ограничивается.

Если речь идёт только об AVR и прочем Bare Metal, то пока что C доминирует, с этим согласен. Пока что.

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

Да, но ты в их число не входишь.

потому что есть понятия которые именно включают в себя несколько объектов - и для этого как раз нужны вложенные структуры

Я понимаю, что технически наследование и вложение структур — разные вещи.

Тебе предложен МЕХАНИЗМ в си с помощью которого можно реализовать наследование (не в академическом смысле, а в программистком) и никакой разницы не будет (кроме косметической)

Я сказал: что объект+методы, что структура+набор функций для обработки

Ты: А как вы будете наследовать?

Мы: вот так вот, через включение материнской структуры в дочернюю

Ты: это не наследование

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

нет в си понятия дочерняя структура

нет и слава богу

чем дочерняя структура (тм) у вас отличается от скопипащщеной с добавлением члена у нас?

В вашей псевдо-логике есть один существенный изъян - вы всё время говорите только про себя («а я вот не вижу», «я все то же самое могу», ...)

Ну я могу только за себя говорить, я, знаете ли, вижу мир через призму СВОЕГО сознания. Не знаю как там у высших существ

Если кроме вас с вашим исходным кодом никому другому не придется работать и сопровождать его - да ради бога, пишите хоть на Ассемблере )

Спасибо за разрешение

Ну вот в некоторые другие проекты вам с вашей «логикой» попасть не светит - просто там такие на хрен никому не нужны

А если руководителем проекта буду я, я себя тоже не возьму? Где я заявлял, что приду в плюсовый проект и начну там всем объяснять что классы не нужны? Это ж кем надо быть? Еще у меня псевдо-логика..

он — известный мастер, изваял уже десятки статуй без маски и не забил себе зубило в глаз

Он - это ты? Сомневаюсь.

Не. Тут не было намека на меня, не настолько я себялюбив как вам видится.

Он — это разумный человек. Пост про то, что не нужно людям без причины руки связывать. Детям — да. Срочникам с автоматами — да. А обычные люди разумны и не опасны.

Заявление: С++ лучше тем, что тебе не дадут выстрелить себе в ногу, на мой взгляд звучит не лучше, чем «в тюрьме хорошо: не дадут заблудиться в лесу»

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

А что ты умеешь такого, чего не умеет моль?

Это оскорбление такое? Умею быть не хитиновым. Че сказать-то хотел?

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

Честно — не знаю. Надо почитать. Про виртуальные функции в целом. ЛОР образовательный.

Нет, это был намёк на глупость вопроса. Хотя... Да, наверное это оскорбление.

Умею быть не хитиновым.

Все так говорят. Доказать-то можешь?

Очевидно, в объектно-ориентированном. Или ты хотел почувствовать разницу между языками, используя одни и те же синтаксические конструкции?

Да я понял что в ООП.

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

Нет, разумеется. Я хотел сказать, что ООП — это не синтаксические конструкции языка, ООП — это принцип построения программы. А программу по принципам ООП можно написать и на си, без всяких костылей. А еще я хотел сказать, что ООП — далеко не всегда нужен: класс работы со сокетами ничем не лучше библиотеки функций и структур работы с сокетами.

А че в паскале не так? Каждый же модуль компилируется, потом, на основании интерфейсной информации модуля, линкуется в бинарь

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

Зато есть возможность всеми этими процессами управлять

Управление тут нужно далеко не всегда. В тех же случаях, когда оно действительно нужно (сильно платформозависимый код и др.) - в современном паскале точно так же есть макроопределения, условная компиляция и инклуды. Такая кувалда для сложных случаев.

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

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

А оно мне надо, тебе что-то там доказывать?

То-то ты ниче не доказываешь целый день. Слова расходятся с делом. Попахивает пустозвоном.

Хочешь 

жирнить, // где? может ты это себе придумал?
упорствовать, // упорство -- благодетель, упертость -- может и нет
игнорировать вопросы, // где?
отказываться разобраться во всём и понять зачем изобрели ограничения // вовсе я не отказываюсь, не глупее тебя -- не льсти себе

закручивай шурупы отвёрткой, а не шуруповёртом

намеренно переврал смысл моих слов, фу

мне то какое дело.

Три строчки кода не захотел написать чтоб доказать свою правоту, хотя до усрачки кричал что это проще, чем на сях? Не вызывает доверия.

мне то какое дело.

на том и закончим

Тебе ограничения в глаз попали. Типы не ограничивают. Смысл ограничивает множество операций, натурально, а типы просто явно выпячивают смысл. Предохранитель, маска - все мимо. Оно не для того задумано и не так работает.

Это не защита от дураков. Дураки пусть пишут на js. Наоборот же - это новые возможности для тех, кто понимает. Я могу другую аналогию привести: поет, который знает 200 слов и не хочет учиться, потому что новые слова его ограничивают. Да, зная много слов нужно больше думать как *правильно* составить предложение, но зачем ему это? Его и так с горем пополам понимали.

Я думаю, без примеров это просто твое слово против моего. Если хочешь, давай пример где ты ограничен, посмотрим.

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

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

Бесполезно такому чудаку что-то доказывать, ты то соглашаешься, то снова отказываешься, игнорируешь вопросы, игнорируешь факты, приводишь портянки в 20 раз длиннее и говоришь что это норма, не знаешь банальных способов обработки ошибок в C (О да, goto имеет применение, внезапно!), не знаешь вообще нихрена и при этом ещё в наглой форме высказываешь своё мнение и т.д. Если бы все эти фичи других языков не были нужны, то кроме C бы ничего не было. В общем тебе - лоботомия, не моможет - в морг, на том и закончим.

Вот это, кстати, миф. Драйвер прекрасно можно написать на чем угодно. Си выбирали просто потому, что никто не хочет рантайм высокоуровневого языка тащить в ядро. В написании драйверов системная задача одна - сериализация. Это все элементарно велосипедится на хоть на хаскеле, хоть на го.

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

Чего такого умеют кресты, что не умеет Си?

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

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

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

Когда-то в далекие времена C++ был препроцессором для C (назывался Cfront), но они там уперлись в какую-то фигню, кажется что-то с реализацией исключений.