C vs. C++

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

Капитан. Если оператор перегружен, то такого тоже почти никогда не происходит, потому что инлайн.

мол, даже там можно в низкоуровневоть

Так называемая «низкоуровневость» - это не о задаче, это подход к программированию. На питоне не «можно в низкоуровневость», но все равно можно писать драйвер. Именно питон здесь не практичен, потому что будет медленно и нужен тяжелый рантайм. А на c++ или rust таких проблем нет.

На прожорливость результирующей программы наличие синтаксически контролируемой модульности не влияет никак. От слова «совсем». Она кончается на этапе линковки.

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

Не стоит.

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

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

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

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

...биндинги. Но их можно написать для всего.

fn security_add_hooks(hooks: *mut CSecurityHookList, count: usize, lsm: *mut u8);

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

фейспалм.жпг

Ты попробуй написать на Rust биндинги к device model или PCI DMA API. Да хоть к банальным спинлокам. «За вечер», ага.

но ничего реально используемого

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

...биндинги. Но их можно написать для всего.

Вот именно. Выше ты писал

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

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

Что бы я не назвал, ты [...]

Ты назови сначала, а не вангуй.

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

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

Я это уже говорил. Но еще я говорил, что к практически полезному драйверу предъявляются еще кое-какие требования, кроме «написанности».

Наследование, ссылки, перегрузка. Да, c++ нужен для игр и гуя, там это полезно:

Не нужен. Это всё проще сделать на какой-нибудь скриптоте.

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

Если что, я никогда не писал практически полезный драйвер, хот подозреваю, что на с++ их тоже пишут.

я никогда не писал практически полезный драйвер

После вот такого пассажа:

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

как-то ожидаешь большего.

Ну так, экспериментатор-теоретик же. Пробую разные языки программирования в разных областях. По моему, это как раз можно противопоставить «практическому» программированию.

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

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

Я писал что комментарии костыль, но они нужны. Есть такие комментарии - документация в коде, по документации ide делает подсказки. Вот они точно нужны.

Можно без обычных комментариев, если код реализует спецификацию. Тогда хватит документационных комментариев перед каждой структурой данных, что бы указать чему в спецификации они соответствуют, если это не очевидно. Все остальное в спецификации должно быть.

Похоже ты не понимаешь главного в индустрии, С++ это самый удачный ответ ИТ на сложность систем.
Посмотри и почитай видео докладов с C++Russia 2018 (заметь, целая конференция, посвященная одному ЯП).

http://rsdn.org/Forum/cpp/7206860.1

Начни просмотр с доклада http://rsdn.org/Forum/cpp/7206860.1 (https://youtu.be/QU63wpGBvjE) «C++ Russia 2018: Андрей Карпов, Эффективный C++ (Маерс тут ни при чём :)».

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

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

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

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

Ты не следишь за ходом дискуссии. Речь не о скалярных типах, для которых и операторы работают, и освобождать их не надо, а о сложных - например, матрицах или длинных числах. Каждый такой объект требует выделения памяти из кучи.

никто не пользует

и дальше можно не читать

Обычный avr-g++, а программы, увы, под NDA.

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

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

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

Я ещё раз повторяю, мы обсуждаем общий подход. Для векторов никаких sprintf'ов нет. В C и векторов-то нет.

А так да, признаю, выглядит ловчей, чем sprintf

Вообще-то, если перейти к строкам, то нет. C++'ные потоки и ручная конкатенация строк медленные, неудобные и плохо работают с локализацией. Правильный подход - это типобезопасный аналог sprintf на variadic templates, типа как в fmtlib. И да, если сравнивать его и C'шный sprintf, последний также проиграет с треском, поскольку C++ даёт типобезопасность - нельзя перепутать тип в format string (и его вообще не требуется указывать), или передать не то количество аргументов, также не нужно будет вычислять или угадывать размер буфера и обрабатывать его переполнение, выделять и освобождать его, а также можно передавать произвольные объекты, которые поддерживают приведение к строке, не заботясь, в свою очередь, о промежуточных буферах для их представления.

На самом деле всё просто. Тебе тут уже советовали, напиши программу на Си и С++ для своих нужд и поймёшь разницу. Я бы добавил, что кроме небольшой программы для себя, неплохо попытаться написать библиотеку для для других. Я когда шёл по этому пути понял, что в С++ есть некоторые стредства, которых нехватает в Си. Про RAII не буду писать, это и так понятно. Исключения. Попробую сделать обработку ошибок в программе (а лучше в библиотеке) на Си. Я тут недавно тему создал, легко убедиться, что единого способа нет. А если всё-таки попробавать написать библиотеку(даже небольшую) с обработкой ошибок, станет видно весь этот лишний код, затрудняющий понимание хода нормального исполнения программы. Дальше можно упомянуть пространство имён. Без них придётся городить префиксы. Про шаблоны, вроде писали уже. В общем сама тема «vs» не имеет смысла. В лучшем случае в такой теме надо бы указать область применения. Но, судя по сообщениям в треде, ты хочешь чтобы тебя срочно убедили писать на С++ а не на Си, при чём из аргументов «всё что написано на с++ можно написать на си» и тут вроде с этим даже никто не спорит, от себя же (того кто недавно думал также как ты), предложу — а ты попробуй.

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

Ты только что сравнял с землёй весь Qt.

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

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

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

Про RAII не буду писать, это и так понятно.

Давно реализуем средствами большинства Си-компиляторов. Если у тебя с этим проблемы, проваливай на винфак! встаёт вопрос - на тот ли ресурс ты зашёл с такими предъявами.

Исключения. Попробую сделать обработку ошибок в программе (а лучше в библиотеке) на Си.

Само по себе изобретение сомнительной ценности.

Я тут недавно тему создал, легко убедиться, что единого способа нет.

Из той темы было легко убедиться разве что в сильном засилии троллей в /development.

Дальше можно упомянуть пространство имён. Без них придётся городить префиксы

Их и так городят, посмотри на тот же Qt. Да, кстати, исключения там тоже практически не употребляются, да и шаблоны стоит поискать.

Про RAII не буду писать, это и так понятно.

Давно реализуем средствами большинства Си-компиляторов
Из той темы было легко убедиться разве что в сильном засилии троллей в /development.

Это да.

Давно реализуем средствами большинства Си-компиляторов.

Можно пример?

Не то чтобы я прямо сильно впрягался за какую-либо сторону в ваши петушинные бои.
Если у тебя с этим проблемы, проваливай на винфак! встаёт вопрос - на тот ли ресурс ты зашёл с такими предъявами.

Зачем так сурово, я тоже считаю топик холиварным и бессмысленным, но решил добавить немного осмысленности — поделился своим опытом. Без претензий на истину, само собой. Я нигде не писал, что считаю С++ лучше, чем Си или наоборот. Просто написал про те фичи С++, которых мне сильно не хватало при написании своих поделий.

Можно пример?

#include <glib.h>

int 
main(int argc, char** argv)
{
	{ 
		g_autofree gchar* str = g_new(gchar, 10);
	} /* автоматическое освобождение, утечки нет */
	return 0;
}

Как минимум gcc и clang собирают.

Т.е. на каждой переменной явно указывать «нужно вызвать деструктор»? Офигеть как удобно.

Как будто в цпп у тебя массив байт в куче сам себя освободит, по щучьему велению.

В Си++ для этого не надо каждый раз писать autofree.

В С++ для этого надо каждый раз писать std::unique_ptr<>.

В С++ для этого надо каждый раз писать std::unique_ptr<>.

Тип надо писать и в Си. Только в Си++ невозможно забыть написать autofree.

Т.е. на каждой переменной явно указывать «нужно вызвать деструктор»? Офигеть как удобно.

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

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

на каждой переменной явно указывать «нужно вызвать деструктор»? Офигеть как удобно.

Да, в этом и есть удобство Си.

И удобство заключается в чем именно - ошибки делать удобно?

Язык делает то, что ты его просишь.

Причем любой язык.

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

И можно ли в качестве free вызывать свои обработчики? А то ldap'у, например, нужен свой ldap_free.

И удобство заключается в чем именно - ошибки делать удобно?

Зависит от того, каких. Если сравнивать C vs Rust, то в первом будет больше ошибок работы с памятью, а во втором будет больше логических из-за убогого дизайна языка.

Язык делает то, что ты его просишь.

Причем любой язык.

Где-то уровень абстракции мешает, так что далеко не любой.

И удобство заключается в чем именно - ошибки делать удобно?

Зависит от того, каких

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

Язык делает то, что ты его просишь.

Причем любой язык.

Где-то уровень абстракции мешает

А, вот как. Ну да, некоторые языки просить бесполезно - уровень абстракций не тот.

Еще раз - в чем заключается удобство указания необходимости вызова деструктора на каждой переменной?

В том, что логику программы определяет разработчик. Он чувствует тот код, который пишет. Си ― это open mind программирование.

Обратная сторона, безусловно, тоже есть.

Еще раз - в чем заключается удобство указания необходимости вызова деструктора на каждой переменной?

В том, что логику программы определяет разработчик.

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

Си ― это open mind программирование.

Программирование open mind-ов? Ну ХЗ, никогда не занимался.

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

Ты просто не понял ответ.

Если сравнивать C vs Rust, то в первом будет больше ошибок работы с памятью, а во втором будет больше логических из-за убогого дизайна языка.

будет больше логических из-за убогого дизайна языка

4.2

Будешь отрицать очевидный факт, что переусложненность языка увеличивает вероятность логических ошибок и затрудняет аудит?

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

Будешь отрицать очевидный факт, что переусложненность языка увеличивает вероятность логических ошибок и затрудняет аудит?

Нет. Только вот Rust в сравнении c C/C++ значительно проще, ибо soundness вместо нагорождения костылей.

Можно унаследоваться от GObject, тогда да. В таком случае, все деструкторы GObject (а их может быть несколько) будут вызваны в нужном порядке.

Можно попотеть и вручную прописать, GLib для этого вроде предоставляет какие-то средства. В любом случае, это всё обёртки вокруг расширений gcc и тех компиляторов, которые эту идею утянули себе (clang, например).

Нет. Только вот Rust в сравнении c C/C++ значительно проще, ибо soundness вместо нагорождения костылей.

C/C++

Ты определись для начала с чем ты сравниваешь ― с Си, или с Си++. Это совершенно разные языки.

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

Настало время офигительных историй.

Дальше не читал. Тоньше надо быть, тоньше

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

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

в delphi генерики работают во время выполнения)

И это как раз недостаток C++, что в нем можно только так

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

В них ООПщина проще реализуется. Но оопщина нужна лишь гуеписцам, а в остальном она бесполезна. Поэтому С рулят!