Выбор ЯП для системного программирования.

Начать с изучения архитектуры компьютеров. Потом учить ассемблер и Си (не умеешь читать выхлоп objdump и коррелировать увиденное с местом в сишном исходнике - не системщик).

Можно начать с чего-то попроще современного x86 и Линукса, тут главное принцип понять. Какой-нибудь голый эмбед и примитивнейшая ось. Даже Ардуино пойдёт.

Написал 100 строк кода на C за всю жизнь и не изучал его никогда. И раст не планирую.

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

Си. Предлагаю тред закрыть.

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

Си не является подмножеством С++, не позорься.

Строго говоря - не является.

Но если убрать мелочи, типа restrict и dynarray на стеке (которые и так дефакто доступны если сильно надо) - то ничего того, что нельзя сделать в C++, этот ваш «портабельный ассемблер» сделать не позволяет. Только, имея мозг, на плюсах можно много всяческой хрени контролируемо автоматизировать, а сишные утята продолжают жевать кактус ручного и небезопасного перекладывания байтов макросами и прочей мутью типа printf.

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

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

Как вспомню в публичном коде char name[20] - так сразу радуюсь за убогих любителей сишечки.

Вариантов не так уж много на самом деле:

1. C89
2. C99
3. C11

Я бы рекомендовал C99.

C:

for(int i=0;i!=666*666;i++)
    char name[20] = "01234567890123456789";

C++:

for(int i=0;i!=666*666;i++)
    std::string str="01234567890123456789";

Вопросы?)

Вот так любители плюсов заюзают vector,map,string и время уже будет побольше

Тонкие любители сишечки сфонтанировали от избытка чувств.

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

И да - std::string использовать никто не заставляет.

Любители плюсов - не знаю таких.

А нормальный программист знает про buffer overflow и не будет создавать такие переменные, ещё и глобальные.

Но оголтелого сишника ты узнаешь по таким переменным.

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

Вопросы?)

Да, по крайней мере один: какие таинственные причины могут побудить программиста создавать одну и ту же строку 443556 раз?

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

Но сишникам типа тебя это непонятно и сразу же возникают анальные боли от предстоящей возни с malloc/free и кучкой strcpy/strlen/srncpy/strtok и прочим говном.

А корректность программы - да пофиг. Это же сишка!!!

char name[max_len];? Какой смысл юзать кучу для такого?Может еще для int i; будешь юзать кучу?

Какая же боль!!!) char* name = malloc(max_len+1);

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

Что такое max_len? макрос #define max_len 20?

Очень смешно от того, что я такое в творениях сишников вижу постоянно. Ну и не поверишь - C++ не обязывает использовать кучу. Но если она понадобиться, то можно использовать её относительно безгеморно (уж как фантазия позволит).

А ты забыл проверить name на NULL и ещё будешь потребять сразу же максимальный объём памяти. А если нужно будет сжать несколько строк в один непрерывный кусок памяти для оптимизации мемори футпринта, то умрёшь раньше, чем это сделаешь.

Подсказываю - и первый пример и второй являются фрагментами кода на языке C++.

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

int c99_detka;
scanf("%d",&c99_detka);
int arr[c99_detka]; /* А плюсы так не могут) */

Лол,если NULL то пусть программа падает.Что ты можешь сделать когда память кончилась?

Подсказываю,это твои слова про name[20];,да и я демонстрировал C-style vs C++-style

и ещё будешь потребять сразу же максимальный объём памяти.

почитай о фрагментации кучи

Я много чего могу сделать, когда окончилась память. И даже оверкоммит могу обработать. А ты продолжаешь демонстрировать убогость мышления типичного программиста на C.

Ну и c restrict пример кода выдай. А это говно scanf(«%d»... засунь туда, откуда достал.

Почитал лет 14 назад. Сишник всегда найдёт оправдание тому, почему он написал следующее

first_name[20] last_name[20] full_name[30]

void* my_malloc(size_t s)
{
if malloc NULL
{
msg("память мне запили");
wait_memory();
} 
}

Как будто это так сложно

Выбор ЯП для системного программирования

plain old C

Да, обработка ошибок от сишников - это та ещё эпопея.

Не то что у С++ где эсепшены не работают нормально,и еще имеют оверхед)

Ты так и не можешь понять своими сишными нейронами, что C++ позволяет это делать как и в твоём уютном «платформонезависимом ассемблере».

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

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

Эта разница довольно бессмысленная, так как никто не инициализирует строки 443556 раз в цикле.

Юзать компилятор плюсов,а код писать на Си.Лол,главное не забывать кастовать void*,и чем то заменять те массивы выше)

Да там и без инициализации так же,я про то что,пару std::string,std::vector еще пол std,boost делают программу уже медленней

Классический сишник - можно в палату мер и весов вносить как эталон.

Ты так и не понял, что C++ позволяет освежить твой чудесный в своей кривизне код типобезопасными бесплатными в рантайме, созданными в строгой дозировке тобой же, инструментами. Но можешь и дальше сканэфить свой name[20], разбавляя это шедеврами API творчества типа atoi и наяривать на массивы на стеке динамической длины, которые и так доступны в плюсах для любого доступного на данный момент компилятора.

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

Да там и без инициализации так же

Сомнительно: операции с уже выделенной памятью дёшевы.

0.004 vs 0.027

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

Типичному сишнику сия мудрость недоступна. Ему и char double_as_string[100] нормально. Проскакивало тут на этом форуме не так давно такое.

Ты так и не понял

Это у тебя просто ЧСВ,я все понимаю.Я не вижу плюсов у плюсов))

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

ООП оверхед,иключения оверхед.Да и то ненужно они.Типобезопасными?))Лол

0.004 vs 0.004 и 0.027 vs 0.027

это если сравнивать C & C++. Но на плюсах потом можно оптимизировать для уменьшения аллокаций без изменения апи. А на C - обсеришься.

А если сравнивать убогость сишного мышления с кодом нормального программиста - то это buffer overflow vs 0.027 (worst case)

Ему и char double_as_string[100] нормально.

Если кто то так пишет,то это признак того что он пишет в стиле плюсов.Ему просто нравится Си,и пофиг на его плюсы.А типичный С++ берет std::stringstream а там 16Гб кучи забирается)

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

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

Но на плюсах потом можно оптимизировать для уменьшения аллокаций без изменения апи. А на C - обсеришься.

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

0.004 vs 0.004 и 0.027 vs 0.027

malloc работает быстрее new,это как минимум.Там то еще ООП

Сишник, узнай сначала максимальную длину double числа в строком представлении

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

Ты уже продемонстрировал фрагменты кода типичного проекта на C. Хороший код на C (= хотя бы без формально доказуемых багов) - очень большая редкость.

Осознай сначала, что такое типобезопасность и почему scanf её не обеспечивает.

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

К примеру, 128 байт не хватит.

И глобальный буфер - это зачёт. Пользователи pthreads будут рады глобальным буферам, которых и так море, от стандартной библиотеки C до разномастных «хороших проектов» на том же C.

Т.е. про типобезопасность ты что-то краем уха слышал. Это уже хорошо. Осталось только осознать, почему scanf не типобезопасен, каким бы ни был компилятор.

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

std::string realy = "0";
realy[1000] = '?';

Из того же разряда

Ты не догоняешь, что такое хороший код. И почему «к примеру, 128 байт» - это убожество.

И скажу сразу и напоследок - к ООП и прочей хрени «хороший код» не имеет никакого отношения. Как и к си и к плюсам.

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