Пожалуйста, пользуйтесь https://ideone.com/#, https://wandbox.org/ или https://pastebin.com/ для вставки кода, если он длиной больше нескольких строк или содержит [i] или ∗.
Что читать:
- Brian Kernighan, Dennis Ritchie "The C Programming Language": http://www.cypress.com/file/56651/download
- Stephen Prata "C Primer Plus, 6th Edition" (2014): относительно свежая, знает про C89/C99/C11, описывает различия, объемная (около тысячи страниц), годная, с вопросами, упражнениями и ответами. Читать после K&R или до.
- Zed A. Shaw "Learn C the Hard Way" (2015): годное пособие для гуманитариев для гуманитариев!
- Немного примеров хорошего стиля: http://www.oualline.com/books.free/style/index.html
- ООП, например: http://www.cs.rit.edu/~ats/books/ooc.pdf
- Стандарт ISO/IEC 9899:1999 (C99): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (драфт)
- Стандарт ISO/IEC 9899:2011 (C11): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (драфт)
- Черновик стандарта ISO/IEC 9899:202x (C2x): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2479.pdf (февраль 2020, с диффами)
Чем компилировать:
- Очевидный GCC.
- clang: оче годно, батя рекомендует.
- Intel C++ Compiler: оптимизации, тысячи их.
- Visual Studio Community Edition: внезапно этим стало можно пользоваться, особенно с тулсетом clang/C2. Поддержка C11 на уровне "есть все, что тебе понадобится в реальном проекте плюс кривая библиотека". Анализатор кода в комплекте.
- Pelles C (шиндоуз онли): поучиться, вкатиться в C11 (стандарт полностью реализован, имеются в том числе threads.h и прочие stdatomic.h), но количество багов в оптимизаторе и редкие апдейты напрочь отбивают желание собирать этим что-то сколько-нибудь серьезное.
- TCC: очень маленький компилятор с багами и поддержкой C99. С ключом -run умеет компилировать код в память и запускать его, что позволяет писать скрипты прямо на сишечке.
Что еще почитать:
http://c-faq.com/
FAQ из comp.lang.c. Древний, но все еще актуален.
Samuel P. Harbison, Guy L. Steele Jr. "C: A Reference Manual, 5th Edition" (2002)
Ебаный пересказ стандартов C89 и C99 (включая стандартную библиотеку). Для не осиливающих стандарт в оригинале. Читать в качестве подготовки к собеседованиям (есть задачник с ответами) и для ознакомления с масштабами пиздеца перед написанием своего парсера/компилера.
Peter Van Der Linden "Expert C Programming. Deep C Secrets" (1994)
"Си: грязные истории". Смехуечки, немного объяснений, чем обусловлены особенности языка, всем известные подводные камни кто там ругал косяки в JS? у нас в сишечке их гораздо больше, просто они лучше спрятаны, немного байтоебли и непонятно откуда взявшаяся глава про старинные плюсы. Читать в качестве сказки на ночь (на пару вечеров хватит).
Richard M. Reese "Understanding and Using C Pointers. Core Techniques for Memory Management" (2013) - почитать, вкатиться в указатели.
Ben Klemens "21st Century C: C Tips from the New School" (2012)
Paul Deitel, Harvey Deitel "C for Programmers with an Introduction to C11" (2013)
Stephen G. Koch@n "Programming in C (3rd Edition или 4th Edition, если найдется)" (2014)
MISRA Ltd. "Guidelines for the Use of the C Language in Critical Systems" (2013)
Набор рекомендаций по написанию надежного кода на C (промышленный стандарт). Читать - однозначно, следовать - вдумчиво и без фанатизма. Также можно посмотреть https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard и http://web.archive.org/web/20190213011655/homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf
Еще более длинный список: http://www.iso-9899.info/wiki/Books#Learning_C
https://github.com/kozross/awesome-c
Онлайн-утилиты:
- https://godbolt.org/ - Compiler Explorer позволяет посмотреть выхлоп компиляторов для введенного куска кода (больше полусотни разных версий компиляторов).
- http://cdecl.org/ - С Gibberish ↔ English помогает читать сложные сишные декларации.
Прошлые треды:
- №55: http://arhivach.ng/thread/543511/
- №56: http://arhivach.ng/thread/563333/
- №57: http://arhivach.ng/thread/563334/ >>1680461 (OP)
Я один не использую все эти typedef, #define и прочие операторы которые просто присваивают псевдонимы типам и константам?
Не думаю что эти функции особо нужны в ЯП. Поясните, пожалуйста, прав ли я или нет. Если нет то какое практическое преминение может быть этим typedef и define
> Если нет то какое практическое преминение может быть этим typedef
Вот будешь передавать в функцию указатель на колбек, принимающий и возвращающий указатели, и особенно указатели на массивы - поймешь. Нет, ты, возможно, даже напишешь это правильно с первого раза, но вот читать этот код когда-нибудь потом будет сложно даже тебе самому. Алсо, тайпдефы позволяют абстрагироваться от особенностей системы (например, размера unsigned long), позволяют документировать код, не используя комментарии (unsigned int color vs. rgba color в аргументах), позволяют избавиться от блядского struct.
> define
Это единственный в Си нормальный способ объявления констант, это условная компиляция, это возможность гарантированного инлайна простого кода (inline может игнорироваться, всяческие forceinline - нестандартые), и это кодогенерация, когда ты хочешь что-то типа:
typedef void init_func(int arg);
typedef struct { init_func ∗callback, const char ∗name } initializer;
initializer initializers[] = {
#define ITEM(name) {.callback = name##_init, .name = #name},
ITEM(foo), ITEM(bar), ITEM(baz),
#undef ITEM
};
Очень интересны следующие вопросы:
1) Есть ли способ по заданному целочисленному типу T получить соответствующий беззнаковый тип UT (например, по int32_t получить uint32_t, а по uint32_t - тоже uint32_t)?
Иначе говоря, пытаюсь запилить что-то в духе
__UNSIGNED(T) var;
которое после обработки будет
UT var;
2) Есть ли хотя бы просто способ проверить, что некий T является беззнаковым?
3) В дополнение ко (2): если известны все беззнаковые типы, которые потенциально могут использоваться, можно ли решить данный вопрос без нагромождений #if в каждом месте, где требуется определить знаковость?
>сборник ВСЕХ UB
А ты стандарт-то читал?
Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
У тебя там все деления целочисленные.
Смекаешь?
> сборник ВСЕХ UB
В прошлом тредике что-то постили еще: >>1696945 →
>>1715432
Скобки раскрой, нахуй ты их вообще расставил?
>Скобки раскрой, нахуй ты их вообще расставил?
uint32_t testValue = (1125000 * (N / 1000)) - 1;
где N - изменяющееся число, от 1 до 20.
Для красоты.
Как правильно преобразовать выражение, чтобы, сука, получить результат, как при решении на кулькуляторе?
Пример:
typedef struct { int x, y; } pair;
static void get_distance_to_origin(pair p, *out_buffer){
pair origin;
origin.x = 0; origin.y = 0;
out_buffer->out = dist(p, origin);
//free(origin) ???
}
> нужно ли использовать free() или она удалится из памяти по завершению функции?
Нет, такие переменные называются автоматическими, и они автоматически перестают существовать при выходе из функции. Но проще всего думать по-другому: если ты сам что-то выделил или открыл (с помощью malloc или там fopen), то ты сам и должен вызвать очистку. Тут ты никаких malloc не вызывал, поэтому и free сделать не можешь.
Что не так?
Потому что штеуд запретил навсегда лицензировать хуй86 кому бы то ни было еще кроме лизочки писечки и собственно via.
Если бы штеуд разрешал пилить х86 этим бы не то что МЦСТ этим бы 3/4 производителей чипов бы занимались шутка ли такое-то легаси.
Чем отличается
int c
от int c
Такая непонятная хуйня уже весь мозг себе сломал.
> arm убьёт x86
Не убьет.
> бум мобилок ускоряет заколачивание гроба
Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона.
В то время как бэкенд по прежнему крутится на могучих х86 зивонах и никаким немощным рукам их там не потеснить - когда доходит до дела - нужна честная моща пер коре а не кукуруза с многоядерным потанцевалом и проблемой рожающих бабищ в 99% реальных задач.
> Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать
Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
х86 ассемблер может быть сколь угодно громоздким - микроархитектурка решает и ставит рекорды производительности на ядро.
Дошло до того что зеоны ебут уже который год считавшихся непобедимыми динозавров от IBM (POWER и Z).
Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.
Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)
Новые армы в бенчах уже показывают сравнимый с интелами результат: https://www.macrumors.com/guide/arm-macs/ - и это при в разы меньшем tdp. У интелов же - родовая травма в виде сложного декодера и малого числа именованных регистров, из-за чего им крайне сложно повышать число инструкций на такт. Ты забыл, так я напомню - во времена Haswell интелы росли в однопотоке на 3-5% на поколение. И мы сейчас вполне можем вернуться в это страшное время.
>2020
>хвалить обоссанную ноусофт консоль
Я уже молчу, каким отбитым имбецилом надо быть, чтобы не видеть разницы игрушки от компьютера с набором софта за 40 лет. Ах да, это же пердоля с таким же ноусофтом и пердольными игрушками. Вот откуда рак и деградация лезет, из этого отстойника скама человеческого.
>Не убьет.
Скринь.
>Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона...
Ну а теперь сравни гешефт с продажи одного условного сервака для бекенда и десятков тысяч мобильников, которые этот сервак будут использовать. Сравни число произведённых процов каждой архитектуры для данного наборчика и осознай, что в недалёком будущем камни на x86 будут производить 1.5 фабрики на весь мир. А за количественными переменами последуют и качественные.
>Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
Ага, что вкупе с обратной совместимостью, а также всякими непрозрачными архитектурными перделками превратило типичный проц от, допустим, интела в никому не понятный ОГРОМНЫЙ чёрный ящик с кучей бекдоров, какими-то встроенными микро-ос и прочим хламом. А агрессивные попытки все это заставить быстрее работать оборачиваются очередными уязвимостями.
Ну да, ну да - смартфон нинужон, дубль два. Конец уже сейчас предсказуем - нынешний айпад про станет новым форматом железа, и у жужжащих ящиков пропадет ещё половина рынка. Потом вендоры АРМ и ПОСов подтянутся и интелов станет ещё меньше. Слона съесть несложно, ежели по частям.
#include <libusb/libusb.h> не?)
Вот ее объявление: https://github.com/libusb/libusb/blob/14a302a2f55cb2e619158854f94845f2ca2c8214/libusb/libusb.h#L2084
Если кого-то заинтересовало - пишите в тележку
@twoomer
>Вы нормальные? Он же просил простые игры, ПРОСТЫЕ!
Имплаинг дум - сложная игра
https://github.com/ljbade/wolf4sdl
Если ВО - не варик, то учи сам + пили личные проекты, офк нетривиальные. Это единственный выход.
А вообще - байтослесарям сложно найти работу в странах СНГ. Они больше ценятся забугром, там и embedded software engineer получает не меньше, чем жс-макака. В СНГ, увы, ситуация далеко не такая.
>какие-то небольшие либы
Это конкретно в примере с бытовой микрухой может оказатсья КАКАЯ-ТО НЕБОЛЬШАЯ ЛИБА. И ты забываешь, что именно монструозность сишных фреймворков в прошлом, — вроде того же опенгла, старых директексов, снящихся в страшных снах людям вин32 и прочего, — стала от части причиной появления менее монструозных фреймворков на более современных языках. То что эту хуйню перестали использовать не значит что этого никогда не было. И не значит что не существует до сих пор поддерживаемых на них продуктов
> старых директексов
И давно DirectX, у которого API на COM, стал сишным фреймворком? А вот опенгл нихуя не монструозный, полноценную реализацию OpenGL 1.x с софтварным рендером можно целиком написать в одно рыло, и код, как пользовательский, так и самой либы, будет понятен, в отличие от крестов в том же DirectX.
На самом деле проблема геймдева на Си заключается в менеджменте памяти в основном. Когда большие мальчики обмазываются всякими RAII и автоматическими указателями, когда они даже не знают, сколько раз выделилась память для их строчек, и сколько раз эти строчки при конкатенации скопировались, ты по-прежнему вынужден ебаться с goto cleanup и маллоками на каждый чих. И это слегка демотивирует. Чтобы как-то обойти эту проблему, ты тащишь статические буферы везде, куда сможешь дотянуться, что создает кучу других, еще более веселых проблем.
>>1725165
Кстати, да, вот прост: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
Да, юзать COM еще туда-сюда из сишки можно. Если MS не забыла для тебя кроме варианта class написать в хедере все эти struct и STDMETHOD, обмазав толстым слоем макросов (посмотри, в заголовках директикса отдельный #ifdef для сишки... пока еще есть или уже нету в последних версиях?). С реализацией своих объектов начинается боль, особенно когда у тебя несколько интерфейсов. Да, их тоже можно на си писать, можно хоть на ассемблере писать, но это будет больно, это будет тонна однотипных реализаций QI/AddRef/Release, которые нельзя объединить, потому что офсеты lpVtbl в структуре у разных интерфейсов разные. При этом на крестах вся эта боль почти целиком уходит. Поэтому COM - крестовый.
https://github.com/openssl/openssl/pull/12089
Место для чёрных это backspace.
Кстати, забавляют эти потуги белых людей решать за чёрных людей, что для них оскорбительно, а что нет. Это же вроде расизм, разве нет?
Хочу, чтобы у меня на всех окнах было одинаковое верхнее меню (File, Edit, View, ...), но GTK почему-то не разрешает мне это сделать. Как фиксить?
https://pastebin.com/gRC0UScq
Где я проебался с выравниванием, что atoi падает с сегфолтом?
В omp parallel нельзя выделять выравненную память?
fgets(указатель на массив, кол-во читаемых символов, stdin)
Только он вносит символ перевода строки в строку, а не выкидывает его оттуда. Можешь либо свою функцию написать, либо обёртку для fgets, которая выкидывает символ перевода строки и очищает входной поток.
а за такое ебут в жёпы?
копипастил слегка недописанный код,
вот так лучше - https://pastebin.com/uUy3jV95
>>1729013
>булевоское значение указателя
Куда ходить?
1) у вскякого арифметического типа (указателя, например) есть будевское значение. Если указатель не нулл, он true.
2) ты не проверяешь ошибки выделения памяти. это хуёво.
3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
4) ваще, какое-странное решение отмечать конец массива строк пустой строкой. Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом? в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
>Если указатель не нулл, он true.
Вроде это ебота от платформы зависит. null не всегда равно 0x00.
>2) ты не проверяешь ошибки выделения памяти. это хуёво.
Согласен. Но это нахуй никому не нужный привет_мир на две-три сотни лайнов.
>3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
Что и в п.2
>4) ваще, какое-странное решение отмечать конец массива строк пустой строкой.
Мне так местные посоветовали.
>Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом?
Хорошая идея, пока лучшая.
>в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
Тогда маленький мемори-лик, да. Но строки будут непустыми.
>5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
Внезапно для меня realloc() может вернуть указатель с другим значением. Не знаю с чем это связано, но очевидно не с brk(), так как после фиксированной n строки значение указателя меняется(алсо меняются и указатели на строки). Я потому сюда и закинул эту хуиту, уж больно уродливо вышло.
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
короч, null pointer константа по стандарту - арифметическая константа, имеющая значение 0. или таковая, приведённая к типу (void звёздочка). чёт, я не смог прм точную цитату в стандарте про обратное преобразование лул, но все другие источники говорят, что булевское значение указателя true тогда и только тогда кода он не null pointer.
>>1729201
>realloc() может вернуть указатель с другим значением
ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
> я не смог прм точную цитату в стандарте про обратное преобразование лул
Его нет. if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0. Операторы сравнения != и == сами автомагически умеют сравнивать указатель с нулевым указателем такого же типа, каким бы не было представление. И уже у операторов сравнения на выходе инт.
>>1729355
Не говнокод ни разу. Исключительно вопрос выбранного стиля. Явное сравнение лучше читается, плюс некоторые пишут выражения вида if ((ptr = func()) != NULL), в них без != NULL нельзя - будет варнинг. Из этого выражения явное сравнение ради консистентности растекается и на if (ptr != NULL), и на if (ptr == NULL).
>if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0
по маняопределению.
не видел такого в стандарте. там только написано, что арифметические типы имеют булевское значение true если не равны нулю. Указатели же неявно преобразуются к арифметическому типу. Про нулл поинтер сказано, что он - нулевая арифметическая константа или результат её приведения к типу войд звёздочка. Явно про обратное преобразование не сказано.
>ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
Добра тебе, мелкобуквенный гений. А я просто приучил себя к указателям, как собаку Павлова.
>>1729389
>в них без != NULL нельзя - будет варнинг
Кстати вспомнил, почему так и начал писать, т.к. раньше тоже !ptr юзал. Энивей какой-нибудь -pedantic варнинг родит.
> по маняопределению.
6.5.3.3 (unary !): The expression !E is equivalent to (0==E).
6.8.4.1 (if statement): In both forms, the first substatement is executed if the expression compares unequal to 0.
И никакого bool и true. Их вообще только в C99 притащили.
> Указатели же неявно преобразуются к арифметическому типу.
Неявно не преобразуются вообще никогда, по этому поводу вообще варнинг будет в любом вменяемом комментарии. Явно можно, но это зависит от платформы и самого указателя, может быть как implementation defined, так и UB. Поэтому для указателей есть специальный uintptr_t, в который без UB все влезет. А что касается сравнения:
6.5.9 (equality operators != и ==): Two pointers compare equal if and only if both are null pointers, both are pointers to the same object и там много всего еще. Но заметь, никаких преобразований.
>>1729536
> Писать надо:
> if (NULL == expression)
Толсто.
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
1) колбеки в чяужую библиотеку
2) массив функций, вызов по номеру без свитч-кейс без регистрации
3) реализация опенгл под шинду - там по умолчанию изкаробки только фичи из конца девяностых, за нулевыми и десятыми с их шейдерами нужно добывать как руду у драйвера через указатели на функции..
Я как-то из интереса попытался на асме написать функцию вывода числа типа float. Не получилось, конечно, но я подозреваю, что для этого нужно складывать степени пятерки в какой-нибудь int64. То есть:
0,1101 = (1/2) + (1/4) + (1/16) = 0.5 + 0.25 + 0.0625 = (10005 + 1005^2 + 5^4)*10^(-4)
По сути, останется только вывести целое число, запятую и еще одно целое число. Естественно, частные случаи типа inf, nan и нуля обрабатывать отдельно
Это да, это понятно, но как это сделать без длинной арифметики (число бит для дробной части у меня большое)?
Я помню, что, например, для перевода из восьмеричной системы в десятичную был довольно элегантный и легковесный алгоритм (в то время как перевод в лоб требовал длинную арифметику для деления и умножения).
>>1733607
Ну, тем не менее, это релевантно для чисел с фиксированной точкой, с которыми я и мучаюсь.
Есть ли какие то подводные у:
typedef struct {...} struct_name;
Всегда ли можно писать так?
Единственный подводный - связанные структуры данных (элементы списков, деревьев), для которых ты не сможешь использовать тип, определяемый тайпдефом, внутри этого тайпдефа: typedef struct { ??? ∗next_node; int value; } linked_list_node; ну ты понял. Потому что этот тип на момент использования еще не существует. А вот у typedef struct foo { ... } foo; или typedef struct foo foo; struct foo {}; подводных нет. Второй вариант более многословный, зато позволяет при необходимости быстро отделить интерфейс от реализации: просто оставляешь тайпдеф как есть в .h, а структуру уносишь в .c, и если у тебя все манипуляции идут через указатель на foo, то пользовательский код никогда не узнает, что там внутри.
Ну допустим Я вывел
Таблица
Счёт: ++variable
И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.
Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
Вот скрин консольной таблицы из интернета чтобы анонам понятнее было.
Вот допустим это всё вывод моей программы. И мне нужно только чтобы подчёкнутое красным число 10 изменялось, допустим 9 или 11 12 13. При этом чтобы всё таблица не перевыводилась с нуля. Как это сделать?
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Проблема с таким далёким будущим — мы даже не можем предсказать, не будет ли через 50 лет ассемблер ниже уровнем чем си, лол.
А вообще, сейчас есть тенденция запихать побольше ядер (т.к. частоты наращивать не получается) и единственное что можно гарантировать — будут востребованы языки хорошо умеющие в мультитрединг. И это явно не си, но и аналоговнет, что называется.
>Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст), но переписывать работающий софт который всех и так устраивает — это тупость.
>Есть смысл новый писать не на сях
Не все так однозначно. Много "безопасных" программ юзают туеву хучу сишных либ. Пример, за котором далеко не надо ходить, Дискорд. Написан на джаваскрипте, гуй - Электрон, но если ты откроешь memory layout процесса - ты увидишь кучу so(в случае с Линуксом)/dll(в случае с виндой), которые написаны на Сях. И там может быть дыра, так что даже такое якобы безопасное приложение уязвимо к атакам на память.
Учитывая, что даже в 2к20 продолжают писать на сях, а не только поддерживать тонну легаси, то хз-хз... При моей жизни Си точно не умрёт.
Ну, разница в том, что у тебя вместо 30-ти 0-day CVE будет 15-20, это на самом-то неплохой прогресс как ни крути. А с другой стороны это хорошо так поднимет цены на рынке эксплоитов, хех.
Понятное дело, что они не умрут, на них в конце концов кода куда больше чем на каком нибудь коболе, который все ещё жив спустя 30+ лет умирания, только вот имхо — область точно сузится до переносимого ассемблера. Единственный прогноз, который вообще возможно сделать на эту тему.
А ещё на сях и плюсах написано куча софта, который спокойно можно написать и на чём нибудь другом, приём, вас плохо слышно.
Ядром, кодеками и драйверами всё как бы не ограничивается, всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
Предсказать, что будет через 50 лет, в принципе невозможно. Разве можно было предсказать хоть примерное развитие современного телекома и программирования в 1970 году? Уильям Гейтс со своими 640 кб оперативы и то позже был.
Сейчас тенденции на смены парадигм. Например, развитие супер параллельных процессоров, нейро-процессоров. Пока диковинка, но за 10 лет может стать чем-то обыденным. Изменения в концепциях написание программ, уход в виртуализацию всего и вся, куча всего ещё.
Нет, не думаю, что C/C++ сохранится. Слишком уж динозавр из другого мира.
>Нет, не думаю, что C/C++ сохранится
Лол, даже ссаный кобол уже лет 30 умирает, но никак не сдохнет, хотя кода на нем написано в десятки тысяч раз меньше, чем на С/С++
>развитие супер параллельных процессоров, нейро-процессоров
И подноготная всей этой параши будет как всегда на С/С++
Скорее джаваскрипт сдохнет в вебе (нет), чем С/С++ в системщине и подноготной всея мира ойти технологий
Кобол уже 30 лет назад сдох, просто где-то до сих под используется древний софт на древних компах или их эмуляторах.
Само собой, сишечка полностью не сдохнет. Хотя бы потому, что ядра ОС и кучи системного софта на ней написаны, которые работают хорошо, исправно, и свои задачи прекрасно выполняют.
Но само программирование может драматически измениться с тем, как поменяются парадигмы программирования.
Тупо сишечка и плюсы плохо предназначены для многопоточного программирования. А эволюция очевидно идёт в направлении супер-многопоточного программирования. Потому что возможности одного ядра давно исчерпаны, по мелочам как-то оптимизируют, зато вот возможностей для увеличения количества ядер очень и очень много. Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер (блядь, кто-нибудь в 70-е годы мог предсказать микро-сд карты на сотни гигабайт за копейки?), но для этого надо принципиально менять парадигмы программирования и платформы.
Это неизбежно произойдёт. Но как именно это будет выглядеть невозможно предсказать.
>Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер
Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Отлично приспособлены, ничуть не хуже любого другого языка.
>Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
С гигагерцами ПОКА есть проблемы, количество транзисторов на кристалл до сих пор растёт по экспоненте.
https://youtu.be/c01BlUDIlK4
>будут востребованы языки хорошо умеющие в мультитрединг.
Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело.
>Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст)
Раст не даёт той безопастности, о которой ты говоришь и думаешь.
>но переписывать работающий софт который всех и так устраивает — это тупость.
Всё так, а ещё большая тупость - менять коней на переправе.
>С гигагерцами ПОКА есть проблемы
В середине нулевых был достигнут современный уровень, 3.5 GHz, на процессоре пентиум-4. Дальше он не рос, производительность увеличивалась за счёт качества архитектуры, а не тактовой частоты. Зачастую тактовая частота снижалась, а потом заново увеличивалась.
А вот количество транзисторов до сих пор растёт по экспоненте. Усложняли ядра, добавляли кеш-память, добавляют ядра. AMD уже разродился процом на 64 ядра. На видеокартах тысячи примитивных ядер, есть ai-ускорители на тысячи ядер.
Ничто не мешает в принципе сделать и миллион ядер. Пока немного не хватает технологий для этого. Но развитие идёт к тому, чтобы поддерживать массовую параллельность. А от языка требуется, чтобы он нативно удобно поддерживал массовую параллельность, как в гошечке это есть.
Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART? Мне нужен элементарный flow controi, т.к. апапартной поддержки нет, а софтварный XON/XOFF очевидно не подходит из-за "бинарности" отправляемого файла. Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе если бы не это, то уже давно навасянил бы какое-то кастомное простое говно
> Ничто не мешает в принципе сделать и миллион ядер
А ты видео то смотрел? С увеличением кол-ва ядер увеличивается сложность алгоритмов, затраты на планировку и вообще при таком количестве ядер, все алгоритмы поломаются и просто перестанут работать без должных оптимизаций.
>все алгоритмы поломаются и просто перестанут работать без должных оптимизаций
в треде о том и разговор, что в ситуации, когда рост производительности идёт в многопоточном плане, без роста однопоточной производительности, нужно а) использовать другие алгоритмы б) использовать инструменты, языки и стили программирования которые (лучше) позволяют автоматически параллелизовывать написанное. Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
В том-то и задача языка, чтобы сделать программирование таких алгоритмов и задач лёгким и непринуждённым.
Си слишком дубовый, слишком явный и низкоуровневый. Иногда это хорошо, для каких-то системных задач, но иногда нет.
Возможности для конкурентности сильно ограничены из-за этого.
В Го отдельный тред-поток исполнения запускается просто оперетором "go", удобные каналы и агрегаторы каналов (селекты). Не нужно думать, что там внутри, не нужно детально прорабатывать схему распараллеливания, не нужно всяких #pragma-костылей. Просто запускается отдельный поток. Ты уже просто думаешь на языке потоков и корутин. В си так просто не получится. И сам язык внутри для таких задач не предназначен.
Если язык не предназначен, то значит разработчик будет максимально избегать подобных подходов.
Это просто один из примеров. Го мне не нравится, но эта концепция явно хорошая и удобная, думаю будет заимствована языками следующего поколения.
а за такое выебут?
uint8_t* p_frame = NULL;
func(p_frame);
И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
> p_name = func(p_frame)
Я уже возвращаю длину буфера этой же функцией, просто я упростил для примера
> func(p_frame, &p_name);
Мне нужно именно чтобы p_frame принял значение, вычисленное внутри. Больше мне ничего от функции не надо, только адрес буфера в памяти и длина буфера. В лоб можно было бы конечно передавать указатель на длину буфера как аргумент, а возвращать адрес. Я подумаю над этим.
А в чем опасность? Запутаюсь потом на верхнем уровне в указателях?
>То это говно на списках создает кучу cache miss'ов и прочего говна
нормальный компилятор со статическим анализатором видит, что у тебя список - не список(не нужна динамическая вставка т проч) и переделывает в массив. Плюс, ВНЕЗАПНО, мап может работать и на массивах и вообще на любых коллекциях. Далее, если у тебя на каждый кусок приличное независимое вычисление (вместо последовательности мапов ты сделал мап композиции функциий, кэш мисс твой нивелируется).
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?
Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
Так тут как раз и не 0 абстракции. Если бы типы были привязаны к байтам/словам/dword и прочее, то да. Но вместо этого преподносится лажа какая-то с замысловатыми плавающими ограничениями на размер. В итоге это нихрена не переносимый ассемблер. Но одной платформе int один, на другой - иного размера.
Потому что гладиолус.
Почему в Си нет проверки границ массивов, хотя эта операция ничего не стоит по рантайму и дает защиту от глупых ошибок? Потому что такой язык как Си дает тебе МИНИМАЛЬНУЮ абстракцию над голыми инструкциями, которые исполняет процессор. Читай, язык полностью полагается на программиста, ты сам выбираешь способ отстрелить себе ногу к хуям собачьим обрабатывать данные, выбирать типы переменных, работать с памятью и т.п. Минимум ограничений - кредо этих языков.
Тупо? Бесспорно. Но парадокс - на С/С++ (особеноо на С) держится весь мир компьютерных технологий, вся подноготная 98% технологий крутится на этих языках. Это как рак, который пустил метастазы до того, как его успели убить. Теперь хуй убьют, лол.
>при современных мощностях сравнение - ничтожная операция
И что с чем сравнивать, если у тебя функция принимает указатель неизвестно на который алимент массива?
Если передавать "дескрипторы" вместо указателей, как в Эльбрусах, то это не совсем ничтожные расходы.
Современное железо это компенсирует с лихвой. Сишка нужна в эмбедщине, где жетские ограничения ресурсов - бесспорно. Но в мощнейших махинах это только открывает огромный attack surface.
Хотя альтернатив нет. Мы не живем в мире с розовыми пони, где высирают такое чудо техники, как Раст, и который быренько за 5 лет заменяет все наследние С/С++. Реальность куда более жестока и несправедлива.
С другой стороны, мб это и к лучшему, потому что UB - это весело, хоть и небезопасно. Сама возможность произвольно исполнить код на машине, а тем более удаленной, будоражит меня. И без С/С++ наследия это вряд ли было частью реальности.
>Современное железо это компенсирует с лихвой.
Железо ничего никогда не компенсирует, оно просто может выполнить кое-что параллельно за счет большей стоимости разработки и большей потребляемой мощности.
И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов? Офк они не такие быстрые, как они, порой софт, написанный на них, ползет как дерьмо, но порой и нет. И ничего, юзают. В 80ых такое было нереально и засим вся прикладуха писалась на сях. Даже в 90ых годах это было нередкостью, хотя та же безопасная в плане памяти джава с рождения жестко хайпанула. А все из-за тогдашних мощностей. Сейчас это частично нивелируется современным железом, поэтому каждый второй софт на прикладном уровне высран на скриптопараше вроде жса (привет обрыганскому Электрону)
Мораль басни была в другом - на прикладном уровне всем похуй на сверхпердольные оптимизации. Почему? Да блять потому, что железо 2к20 года != железо 1987 года. Вот и все. В системщине - да, бесспорно, но системщиной мир компьютерных технологий не ограничивается.
>в них нет указателей
В расте есть указатели, но там это проверяется, и при этом это системный ЯП. И только не заводи пластинку про unsafe, это смешно.
> Как использование unsigned long long вместо uint64_t влияет на производительность
Именно это - никак. А вот unsigned long может быть 32 или 64 бита, при этом твой код вполне переносим, потому что меньше 32 бит оно быть не может. А вот если напишешь uint64_t, и твой код на 32-битном проце будет тормозить из-за необходимости обеспечивать ненужную тебе по сути 64-битную арифметику путем ебли двух регистров одновременно. На самом деле в stdint есть int_fast типы и int_least типы, вот они норм, и их стоило запилить изначально. А фиксированные нужны, только если ты структуры упакованные в файл пишешь, или у тебя ограничения по памяти.
С какими значениями -O, -march и/или -mtune нужно компилировать программу, чтобы бинарники работали на всех среднестатестических убунтах?
Я не понял, зачем вам границы массива? Если надо размер, чтобы не пройти итератором за пределы массива, то для вас есть sizeof, если не надо, то с чего бы он был по дефолту? Как программа вообще узнает вышла она за границы массива или не вышла, если она просто читает из памяти подряд? Это типа надо границы массива помечать как-то в памяти что ли? Особой комбинацией нулей и едениц? Как вы вообще себе представляете границы массива в памяти?
> Я не понял, зачем вам границы массива?
На самом деле bounds checking для отладки много где есть. Если писать говнокод или просто на отъебись - очень помогает.
> Как вы вообще себе представляете границы массива в памяти?
fat pointers или таблицы, как для виртуальной памяти в процессорах.
> потому что он такие ошибки позволяет исключать
Так и Си позволяет. Но Си еще много чего позволяет там, где в расте нужно писать заклинание на страницу, чтобы его величество компилятор дозволил.
У любого буфера есть размер при его аллокации. При любом доступе к памяти а-ля буффер + оффсет можно проверять туда ли пишут/оттуда ли читают или нет. Дешевая же операция, камон.
>>1741071
Я не растошизик, но мелкософт очень хвалят раст и хотят на него переписывать винду, например. Максимум за 10 лет управятся. А вот Торвальдс ретроград, Линукс доталого будет на сишечке.
Но зато будет забавно, без дыр в памяти мир сер и скучен, есть в этом некая романтика, которую рано или поздно убьет технологический прогресс (надеюсь, когда я уже буду пенсионером)
Ааа, да ты тот второй растошизик который форсит Rust у Microsoft. Ну так вот любые пруфы то мб будут? А я могу тебе прям сейчас ответить: раста не будет. Почему? Потому что им проще расширить компилятор С++ для фикса общих ошибок и спроектировать новый безопасный апи, чем они собственно и занимаются с огромным успехом. Кроме того, ты хоть осознаешь все масштабы операционной системы? А я тебе скажу, 6млн. исходных файлов. Можешь представить сколько там LOC? Я вот не могу.
надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
Смотри: есть целые числа (инты, например) и дробные (float).
Целые числа всегда делятся нацело, т.е. 100/6=16, а твое 5/1000=0. Дробные числа делятся примерно так же, как в школе, т.е. 100.0f/6=16.666..., ну и для 5f/1000 аналогично.
У тебя в формуле правый множитель будет равен -1 (сам сообразишь почему).
Как избавиться? Внутри формулы юзай флоаты или даблы (в зависимости от требуемой точности), а потом кастуй к своему инту.
Пускай есть некоторый сишный код, который нужно скомпилить и тягать как .so в никсах или как .dll в винде. С никсами все понятно - берешь gcc и компилишь. Слышал по mingw и cygwin, но это костыль костыля, как мне кажется. Как компилять либу на винде?
Когда все проверяется в черном ящике каждый раз без исключения - эта а приори не оптимизированный код. segment-naebnulsa-safe контейнер - не экстрасенс какой-то, чтоб проанализировать вызывающий алгоритм на инвариативность условия, что индекс меньше размера, стало быть говно.
Есть тяжелые структуры данных, вся жизнь которых сводится к хождению по индексам на индексы через индексы, и если всрать в реализацию безопасные массивы, время основных операций в такой системе вырастет не на какую-то там
>дешевая же операция, камон
а пропорционально, то есть в разы
Я не имел в виду только аллокацию памяти на куче, в мире микроконтроллеров это, в большинстве своем, непозволительная роскошь, ибо ресурсов маловато даже для обрыганского аллокатора памяти и менеджера кучи.
Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
Произошла аллокация статического 16-ти байтового буфера на стэке.
>>Нет, нельзя, производительности придет конец.
Как тогда раст позиционируется как системный яп и проникает потихоньку в эмбеддед? У него ведь не только тяжелый статический анализатор кода, а еще и рантайм проверки (в случае с МК могут быть нерелевантны, ибо там, как правило, не имеют дело с кучей)
>>Ну так вот любые пруфы то мб будут?
https://www.youtube.com/watch?v=NQBVUjdkLAA
Скорее всего у него там обосновано почему.
Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
Из каких-то таких соображений и появляются ограничения на поддержку памяти компьютерами. Вроде бы у тебя безграничная 64-х битная память, но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами. Во многие серверные платы ты тоже сколько угодно не вставишь.
В общем там недостаточно просто уметь адресовать.
> но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами
Совершенно не по этой причине, не из-за быстродействия. Просто чем больше бит, тем больше площадь адресной шины, а место на кристалле дорогое. К тому же разводить широкую шину сложнее. Поэтому адрес 64 бита, а реально бит в адресной шине меньше.
>Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
>
Бля, чем ей "сложнее управлять"? у тебя кэшлайны такие же, развелось дебилов. менеджеры памяти тоже нормальнве люди пишут, и количество имеющейся памяти не влияет на скорость элементарных операций.
кринж
Хочу вкатиться в Natural Language Processing, Data Visualisation и всякий статический анализ. Для себя, для будущего диплома. Знаю, придется переписывать половину pandas на Си и творить ебанутые вещи.
Хочу выучить C11. Есть время для этого хобби, два года, есть мрачная решимость не подходить ко гвидопыху даже с десятифутовым копьем.
Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Я, конечно, добаеб и земля мне пухом, но если анонс подскажет полезных библиотек/книжек, буду рад.
Ну, тащемта, это даже не ты ебанат, а эта тема вообще не имеет никакого развития, даже вкат в NLP И так далее сомнителен. Вкат в визулизацию — это вообще кекус, там задачи — написать скрипт чтобы разобрать массив данных, причём в большинстве случаев это разовая акция на порисерчить.
>C11
Чел, во-первых это не плюсы, и 11 от 99 отличаются на 1,5 фичи в языке и 3 новых хидера в стдлибе, а во вторых С11 не то, чтобы что то нужное и везде используется в лучшем случае 99.
> Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Тащемта даже хачкель для анализа данных подходит лучше, на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область (которая вообще не то, чтобы сидьно про программирование, оно там вообще вторично).
А про ненависть к ооп — а что для тебя вообще ооп?
. спецом, шоб писать охуительно качественный человекочитаемый код хоть под распечатку на чб принтере
. на то и есть домашние проекты, чтоб доверять самому себе и не обмазываться бест практиками
. в чем космический смысл писать константы КАПСОМ, если можно просто с Капса?
. write писал еще когда nlSendStr не было, ща оберну
Спасибо за мнение.
>на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область
Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
>А про ненависть к ооп — а что для тебя вообще ооп?
ООП для меня просто школьная травма.
Бесконечные классы за гранью нормального, всякие get/set, и -1 балл на контрольной за printf вместо cout с охуительным объяснением "ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно". Пять лет прошло, а я злой как собака как вспомню.
>Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Ты же понимаешь, что это _абсолютно_ write-only подход, который практически невозможно поддерживать и развивать? Ты же сам 2 месяца не разберёшься в коде без полного погружения в это. Это даже хуже типичного говнокода от датасатанистов.
>всякие get/set
А при чём тут ООП-то? Когда тебе понадобится присобачить минимальную логику, начиная от отладочной информации или просто ассертов просто ради приблежиния к уровню self documenting code, и заканчивая серьёзными изменениями (например, строка превратилась в бинарный формат, который надо печатать форматированно), то ты и на ассемблере всё на гет/сет все публичные интерфейсы перепишешь, лол.
>ООП для меня просто школьная травма.
Таки да, всё нормально, порефакторишь то же, что сам понаписал и начнёшь спокойно юзать ооп, реальных производственных травм у тебя нет.
>>1742634
Со стороны нормального программного дизайна это как раз таки нормальное замечание. На уровне лабы3 конечно похуй, но с практической стороны лучше иметь возможность тюнить даже такой функционал не меняя саму логику программы.
inb4: Ух, чую как злая шкила меня сейчас говном закидает, лол.
А что такое ООП, чел? В С вот реализация инкапсулируется от интерфейса с помощью хидеров, инкапсуляция — 1 из 3 принципов ООП, С — ООП язык на 1/3?
>>1742723
Я же и не говорил обратного, но это хоть какая-то инкапсуляция. Ебашь на здоровье массивы байтов напрямую, кто же запрещает-то. Просто через пару лет догонишь что это хуйня а не подход.
Ну смотри, есть C++ а есть Obj-C. И там и там есть "сахарок", только реализует он всё примерно диаметрально противоположно. Кто из них ООП?
ООП — это, блядь, концепция. Ясен хуй, что никому не нравятся всякие там паттерны итд, но паттерны — это костыли для конкретного языка, а не ООП. ООП — это 3 ебучих принципа, ничего лучше которых никто не придумал (разве что про наследование можно поспорить).
>А что такое ООП, чел
Это когда оперируешь объектами классов их иерархией. И все это говно сильно зависит от контекста, плюс поддерживание инкапсуляции, один васян решил скрыть доступ, а второй городит огород чтобы нормально считать значение переменной или избавится от оверхеда проверки значения. Короче оч на любителя, как разведенки с прицепами. Но Qt для мордочек юзаю, да. Философия Перл/С здесь ближе, написал в документашке не лезь и все этого достаточно.
>Нет. Только один: объекты обмениваются сообщениями.
В понимании примерно всего коммьюнити — 3, и почти весь софт на планете пишется с их применением, поэтому Алан Кей идёт нахуй.
Даже в Objective-C завезли __attribute__((objc_direct)) что как бы намекает, что этот подход мертв.
>>1742757
Читать умеешь?
>>1742728
>Я же и не говорил обратного
>>1742759
А аналоги-то какие? Как в новомодных фп архитектурах просто использовать композицию вместо наследования и копипастить код из редюсера в редюсер стейта и создавать заново весь стейт (а лучше и контекст) при каджом изменении а потом гнать по скомпозированному дереву функций?
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.
Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
Ага, если учитывать все кодировки и системы письма, то твой класс улетит в ебеня. Но обычно получается ни то ни се и все работают с байтовым буфером по своим потребностям.
> надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s
То компилятор скажет, что ты ошибся. Да, это работает только для printf-like функций, а если у тебя свой собственный формат спецификаторов или вообще его нет, тогда тебе никто не поможет.
Т.е. я объявляю прототип типа
void func(int a, int b);
И если в коде по ошибке вызываю так
funс(1, 2 , 3);
то компиль молчит как партизан
"-Wall" не помогает
Вижуал студио сказал что не хочет работать без обновления,
а чтобы обновиться нужно залогиниться в учетку майкрософт, от которой я забыл пароль. Сбросил пароль - ввожу и тут он мне говорит что это старый пароль, хотя он не подходил. Видимо я уже менял пароль, и это старый старый пароль и он почему-то больше не подходит им. Вот нахуя программисты майкрософт создают такую еблю для пользователя?
>Или тупо в вижуал студио на виндоусе для начала сойдет?
На форточках я бы посоветовал использовать Code::Blocks + MinGW. Со студией хоть и проще начать работать, но в сравнении с CB её функционал для новичка является overkill, поэтому освоить её сложнее.
А вообще, учить человека программированию начиная с C - издевательство, так можно его превратить в Си-дебила. Типичный Си-дебил ничего, кроме императивных языков с Си-подобным синтаксисом освоить практически неспособен.
>Ставить себе линух?
Попробуй. Еще захочешь, базарю. На самом деле не нужно, используй удобную для себя систему.
>Или тупо в вижуал студио на виндоусе для начала сойдет?
Сойдет и для продолжения. Хотя лично я предпочитаю Clion, но на винде он обычно поверх студии ставится, лол. Не спрашивай.
>Для чего нужно ставить clang?
С - компилируемый язык, так что для превращения твоих буквочек в программу нужен компилятор.
Дефолтный выбор для винды - msvc(visual studio сама его поставит), для линуксов\макоси - gcc.
Clang - это тоже компилятор, можно поставить в качестве альтернативы тем что выше и все будт заебца.
>что это вообще такое?
Не стоит вскрывать эту тему, но вы все равно будете спрашивать..
Clang - часть проекта llvm.org
Если коротко, то clang отвечает за фронтенд компилятора, за счет опен-соусности и хорошего api эту хуеверть используют в разных IDE для подсветочки кода, функций рефакторинга, пиздатых сообщений об ошибках и прочих кодоанализов. В связке с llvm превращается в черную магию, способную работать с кодом на любом этапе компиляции, сожрать твой разум, сделать новый язык программирования или даже перевести код с одного языка на другой, попутно забрав твою душу.
Ты был предубежден.
мимо-крестодебич, зашел в тред случайно.
>а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
Это субъективно, но не стану спорить.
Как минимум какой-нибудь Scheme или Standard ML очень в тему, если приспичило углубиться в Computer Science. У редкого адепта K&R не выносят мозг рекурсивные алгоритмы, обычно используемые в ФП (бинарные деревья из книги они осилили с горем пополам).
Да я не совсем нулевой, в университете вроде бы сдал курс программирования, и даже численные методы на паскале на самом деле не помню чё там было, вроде C++, было похуй сдал и забыл так что сейчас думаю научиться хоть чему-то полезному, не важно какой синтаксис учить сначала мне кажется. Я не из тех кабанчиков которые через 1 месяц хотят устраиваться погромистами.
>>1743264
Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
>На форточках я бы посоветовал использовать Code::Blocks + MinGW
>MinGW
Может лучше wsl или уже линукс?
>>1743268
>Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду?
Тебе как обычному посону достаточно нажать кнопочку compile в ide или как ты там предпочитаешь.
Всю еблю и танцы с разными железками, преобразованием говнокода чтоб анубыстроблядь работало и прочие заботы берет на себя компилятор(тот же clang).
В 99% случаев думать о том что там под капотом происходит вообще не надо.
>жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Можешь попробовать Code block портабельную сборку, на сайте у какогото инфоцыгана что ли видел, тредов 20 назад про неё спрашивал обосрали конечно но работает только вроде пути к компиляторам если не в С копируешь вручную надо поменять.
Расположение битовых полей в памяти.
Имеется некий пакет передачи, который нужно заполнить в правильной последовательности, например:
5 битов - адрес
3 бита - номер функции
10 битов - данные
7 битов - контрольная сумма
Ну и решил для удобства всё это сделать структурой с битовыми полями. На байтах всё выходило как надо(потому что биты в байтах, переменных и элементы в массиве всегда размещаются одним и тем же образом). Но когда я стал тоже делать битовыми полями, всё вышло через жопу. Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
> Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Какой опытный путь, гуглить ты не пробовал?
В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
> Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Да. Ни обычные структуры, ни структуры с битфилдами нельзя отправлять через сеть в сыром виде, их можно только писать в файл, если этот файл будет прочитан той же программой на той же платформе. Для обмена данными надо писать (де)сериализатор, который возьмет байтики (или битики) из принятого буфера, распарсит их и запишет в поля структуры: myshit.smth = read_uint(&src); myshit.some_bitfield = bitstream_read(&bs, 5), ну типа того.
Да, многие пренебрегают этим, надеясь на то, что big endian их не коснется, и что исключения у флоатов выключены, и что что выраванивания у членов структуры и буфера с полученными данными правильные, и что -fms-bitfields их спасет. Но лучше не стоит.
>Битовые поля хуёво стандартизированы.
Они стандартизированы, просто каждый компилятор располагает их по разному в памяти.
>Поэтому лучше воздержаться от их использования.
Не все так однозначно.
Если ты работаешь с битовыми полями только в программе, то их можно использовать, они намного удобнее.
А если собираешься куда-то пересылать, то лучше тогда биты распределять в пакете передачи вручную с помощью битовых операций.
Тот же MISRA C не запрещает битовые поля, хотя как бы этот стандарт во всем придерживается, чтобы код не зависил от компилятора.
>Какой опытный путь
Изменял биты в полученном пакете передачи, а потом на бумажке отмечал, где находится то или иное битовое поле.
>, гуглить ты не пробовал?
Потом, когда увидел такое говно, загуглил, оказалось, что расположение битовых полей в памяти отличается от компилятора к компилятору.
>В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
Да это я знаю, порядок байтов в массивах и структурах всегда одинаков - элементы в начале структуры/массива имеют младшие адреса. А биты в байте располагаются от старшего к младшему.
Речь про битовые поля, а они могут быть не кратны байту, и как расположит компилятор их в структуре это всегда загадка.
Блин, а это говно:
>- Brian Kernighan, Dennis Ritchie "The C Programming Language":
разве обязательно читать?
Просто я прочёл справочник Шильдта(и иногда заглядываю в его при работе) и мне этого с головой хватает для проганья, не вижу смысла что-то ещё читать дополнительно.
Тем, что дефайн - это find & replace ДО начала компиляции. При абузе дефайнов ты охуеешь дебажить это говно, так как переменной как таковой нет, до процесса компиляции просто идет замена x на y, если макрос: #define x y
А константа - переменная, под которую выделяется место в read-only сегменте памяти. И при дебаге, в отличие от дефайнов, у тебя будет не много веселых магических чисел, а переменная с конкретным адресом в памяти.
http://www.learntosolveit.com/cprogramming/Ex_1.8_count_blanks_etc.html
Мой код:
https://ideone.com/9nfk4I
Почему первый вариант работает как надо а мой не считает нихуя?
> func((const char zvezda) buf)
это означает, что он продублируется в ридонли дейта регион? он же не может в соответствующую секцию в бинаре прописаться?
Надо передать фрейм через веб-сокет.
Бяда в том, что передающая функция принимает структуру вида пик1, а ws-клиент на другом конце ждёт объект JSON.
Как мне в Си сеариализовать в JSON объект? Либа - cJSON.
Надо отправить что-то вроде ({"isStagotip":"true"})
Он пишет про процессорный кеш. В его лучшие года он был 8-16 килобайт, сейчас он даже в 10 поколении топ L1 512кб L2 18 L3 24.75 мб соответственно. Очевидно что процессор при считывании чего-то большого в памяти будет прогонять часть через L1 разбивая на кусочки меньше 512 килобайт. А это в свою очередь отдельные. Очевидно что в таком случае 4 гига прогнать проще и быстрее чем 128 гигов.
Но это лишь моё предположение, надо смотреть в каком контексте он это говорил.
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
>ридонли дейта регион
Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё. Вообще, нахуя тебе явный каст? Конверсия указателя в указатель на константу происходит неявно и вообще абсолютно легальна (то, что функция принимает указатель на константу, обычно означает, что она не будет менять передаваемые таким образом данные). Система типов в си - достаточно мудра и держит тебя в узде.
Куча детских болезней.
Есть профит по сравнению с каким-нибудь JS, Java, Kotlin или PHP. Когда речь заходит о сравнениис C - все профиты пропадают.
В основном растошизики орут что раст круче при работе с памятью и что сложнее выстрелить себе в ногу при этом умалчивая факт того что это профиты перед стандартом C 1997 года!
Попробовал вот так: https://pastebin.com/08anHKqu
Но memcpy не корректно скопировало массивы.
_Server: Got packet with message: "isStagotip" // запрос от клиента
_Server: Packet type: 1
{
"isStagotip": "false" // содержимое *json
}
_Server: Buf: {isStagotip" // результат работы memcpy c массивом buf
:(
А что сейчас поменялось? Сишка так и продолжает невозбранно срать в память, ub на ub и ub погоняет. В крестахс этим проще, там контейнеры и умные указатели, этот язык на 90% избавился от проблем 80ых, в отличие от Сишки.
А в расте так вообще срать в память можно только в ансейф блоках, и то со своими нюансами. При этом пристальное внимание при тестах можно сосредоточить именно там и поэтому вероятность критических багов в целом снижается чуть ли не к 0.
Сразу видно смузихлеба, который пишет на своем языке хеллоу ворлды, а не нормальные проекты. Раст не защищает от утечек, он предоставляет RAII.
http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/
https://doc.rust-lang.org/nomicon/leaking.html
Я вообще мимо другой анон. Моя единственная претензия к расту это раздутость. У меня один проект занимает что то около 1.3 Гб (target) и еще 400 метров rls-овских файлов, ну и небольшое примечание: это хеллоу ворлд, для отрисовки одного единственного треугольника с градиентом. Как я понимаю это все скомпилированные зависимости, то есть дальше размер проекта будет расти только от моих собственных файлов. Но если я захочу сделать еще один проект, который рисует квадраты, то у меня будет два проекта по ~1.7 Гб, и так далее....
Ага, только вот утечка памяти сама по себе не эксплуатабельна. Ты не можешь дойти до состояния исполнения произвольного кода имея лишь мемори лик, в отличие от переполнений и мисменеджмента работы с указателями, что раст элиминирует накорню (не считая ансейф, но я уже высказался по этому поводу).
Да, attack surface меньше, тем не менее, раст не такой идеальный каким его многие описывают. Мне кажется, если не было фанатичной рекламы раста из всех щелей, то не было бы хейта в сторону раста и относились бы к нему спокойнее. Ну а так, мне кажется, что уже стоит начинать изучать раст, тем кто хочет в системщину, не обязательно писать, но уже даже мелкомягкие и мейнтейнеры линукса уже начинают работать с растом. Хотя, кмк, сишка все также незаменима на микроконтроллерах и embedded.
>>1749220
Небольшое дополнение.
Есть функция вывода JSON объекта без форматирования - cJSON_PrintUnformatted.
_Server: Got packet with message: "isStagotip"
_Server: Packet type: 1
{"isStagotip":"false"} // сформировано
_Server: Buf: {"isStagotip":"false"} // отправлено
Но ошибка та же - неожиданный конец JSON сообщения.
Не пойму пока, что не нравится парсеру.
Жисон сообщение чем-то оканчивается?
На сишной стороне подобный пакет был без труда распарсен:
{"ssid":"test_ssid","pwd":"test_pwd"}
Да, дело было в этом параметре.
Спасибо. Пойду дальше биться об стену.
Вот няша.
>А что сейчас поменялось?
Язык обновили, баги исправили. Ты же тоже не пишешь на первой версии раста. Вот и C скакнул вперёд. А вы со своими спорами напоминаете мне кукареки смузихлёбов против PHP, вроде и дельная критика, а на деле выясняется что относится она к первым детским стандартам, а на том языке к которому критика относится уже никто не пишет много лет. В итоге слышу звон, да не знаю где он.
>>1749114
Ну тут никаких утечек памяти ненужно. 1,3 гига - видимо предполагает что она уже везде где только можно протекла.
>Как я понимаю это все скомпилированные зависимости
У раста нет нормального компилятора который берёт только то что используется кодом? Такая штука даже в делфях была, даже в паскале. Мол используешь мат функцию дискриминанта, в своём коде. Вот эти 16 строк и берёшь. В итоге даже жирные проекты не превышали 1.2 мегабайта. Неужели это какие-то забытые техники? Или там какое-то другое устройство бинарников?
Нет, братан, это ты иди кури матчасть.
Пикрил:
константная целочисленная переменная sosatb, равная числу 1337, находится по адресу 0x7fffffffdf7c. При инспектировании адреса видно:
а) Этот адрес лежит в пределах лэйаута стэка - команда vmmap stack дает ренж адресов стэка, как видишь, адрес константной переменной лежит в этом ренже.
б) При обращении по адресу 0x7fffffffdf7c, видно значение 0x539 на стэке, что равно 1337 в десятичной системе исчисления.
Вывод - константная переменная находится непосредственно на стэке (нет никакого указателя на .rodata сегмент, как видишь), засим семантика языка С хэндлит такие ситуации, но никак не перемещение константных переменных в .rodata
Если тебе интересно что хранится в .rodata, могу дать пример - строковые литералы. То бишь, условный char* literal = "yayayoyo"; улетает в .rodata
На будущее, советую проверять подобные утверждения в отладчике, дабы не вводить в заблуждение маслят. Бобра!
#define это по сути find & replace
До начала компиляции при условном макросе #define a b все а в текущем файле заменяются на b, ДО начала компиляции. Это не является переменной, скорее как магическое число (именно поэтому абьюз дефайнов превращает отладку в ад).
В случае с const, все происходит не ДО начала компиляции, а непосредственно ВО ВРЕМЯ компиляции, под переменную выделяется память, соответственно, у нее есть адрес.
>Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё.
Для полной ясности. Глобальные константы
char yoba[] = "yoba";
const float pi = 4;
будут размещены компилятором/компоновщиком в секции ro data, если таковая поддерживается.
Эта секция при исполнении помещается/отобращается в память read only, при наличии поддержки в ядре.
Ты не знаешь что такое magic values?
#define MACRO 1337
...
int var = MACRO;
MACRO просто заменяется на 1337 во всех местах в текущем файле. Если макрос привязан к числу, то MACRO - магическое число без адреса в памяти, так как не является переменной. В чем проблема?
>char yoba[] = "yoba";
Это не константа, это обычная строка, не литерал. И если эта строка вне стэкового фрейма какой-либо из функций (то бишь глобальная), то такая строка улетит в .data сегмент, куда можно, разумеется, писать. Литерал же в любом случае улетает в .rodata, неважно глобальный он или же находится в стэковом фрейме одной из функций, которая его объявила.
>const float pi = 4;
Да, тут ты прав. Если эта константа глобальная, она улетит в .rodata. Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент, так как она не там в таком случае.
Вы заебали выдавать детали реализации за истину.
> Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент
Все зависит от компилятора, от флагов оптимизации, а в случае с float еще и от использования fpu или sse для плавающей точки. Алсо, .rodata - это линуксы. В винде оно может улететь в конец .text, в .rdata, да и в .data даже с какими-то компиляторами. В каком-нибудь ARM-коде оно может лежать в виде литерала прямо после функции, а функция, естественно, в .text.
Непонятно, для каких конкретных жизненных задач может понадобиться непременно СПИСОК ВСЕХ UB БЕЗ РЕГИСТРАЦИИ И SMS. Сдается мне, у тебя какой-то реферат, сам смысл которого в том, чтоб ты, как раз таки, сам выколупывал крупицы знаний, и ты пришел с этим на двач. Аноны?
Сосунок, ты думаешь я не знаю, что такое строка в Си? Что это нуль-терминированный массив символов? Камон, я писал драйвера и кастомный кернел с половиной кода на асме еще до того, как твой батя твою мамку тобою запузырил, не пытайся маняврировать, ты выглядишь нелепо. Единственное, что ты пытался сделать, это доебаться до слов, чтобы выйти из нелепой для себя ситуации.
Маня, у тебя этот конст находится в стэковом фрейме функции и при обращении по адресу нет никакого адреса ни в какую секцию, а есть просто голое значение инта, че ты несешь? У тебя перед глазами вывод отладчика, а ты маняврируешь.
Более того, в .text секции хранится код, там пермишены read & execute, причем здесь переменные, ебалай? Они там не хранятся.
Если ты, уебок тупой, перепутал это с .data/rodata, то тоже нет, для этого переменная на пикриле должна быть глобальной, а не локальной. Проверь в отладчике.
Нихуя не знаешь и еще пытаешься выебываться. Пиздуй учить матчасть, щенок.
Ребёнок, ну прекрати проецировать и копипастить. Ты ведь даже 2/3 из написанного не понимаешь. Каждая твоя строчка пропитана жалким негативом, что выдаёт в тебе закомплексованного юношу. Нельзя так себя вести, не красиво. Соблюдай нормы приличия, ты всё-таки не в подворотне или /b.
Я предоставил факты, вывод отладчика не врет. Спор против доказанных фактов - признак долбоеба и слабохарактерного червяка. С моей стороны пока были только факты и доказательства, вы пытаетесь здесь маняврировать и троллить тупостью, камон. Раскройте глаза/откройте сами отладчик и проверьте, это не так сложно. Гораздо проще, чем пытаться кого-то задеть на анонимной борде (лол) и спорить в лоб с доказательствами, не имея своих.
К сожалению, это наследие для обратной совместимости. Древние реализации имели другой синтаксис объявлений, а при отстутсвии объявления компилятор молча предполагал, что все аргументы int, и возвращаемое значение тоже int. Такие ошибки мега трудно дебажить, особенно если один из аргументов/возвращаемого значения является укащателем, который обрежется компилятором до 32битного инта (особенно на 64битной системе).
И да, -Wall, как ни парадоксально, ловит не все. Попробуй добавить во флаги компиляции явное указание стандарта не ниже C99 (а лучше сразу C18, хуле), либо попробуй явно включить предупреждения - Wimplicit-declaration
Обсуждение этой проблемы есть здесь
https://stackoverflow.com/questions/434763/are-prototypes-required-for-all-functions-in-c89-c90-or-c99
А что это за забугор такой ты мне скажи а то я хз. Вот я в Финке живу це забугор уже или ещё нет? Знаю типа из россиюшки который катает 1 неделю в месяц по всем кокотельным своего города, редачит там что-то на сишке пару часов и получает за это 200к в месяц.
Ты или тралль-абсрактушок-пиздабол или что-то перепутал.
По котельным катаются вот эти ребята:
https://2ch.hk/wrk/res/1998066.html
И прогают там не на С, а на диалекте паскаля (ST), а то и вовсе мышкой (LD, FBD).
Ну, если цель - попасть в железячный интырпрайз вроде телекома или прочих нвидий или на худой конец - прошивки для индезита писать в конторе-подрядчике - то да.
Если разрабатывать аналоговнет в засаленной ниишке с тащмайором за спиной и подпиской о невыезде - то нет
В юзерленде это разработка демонов, какие-нибудь движки баз данных, что-то для виртуализации/эмуляции. Плотют за такое хорошо (100-200), если компания крупная, в других хз. На шишечке самое то писать ядрышки и демоны, а в проекте покрупнее быстро вляпаешься в плюсы.
>А как обстоят дела с временем вката?
Если ты нуб и тебе интересно низкоуровневое программирование/системщина, то надо самообучаться лет пять (в т.ч. копать чужой код), чтобы нахуячить приличный код для резюме и ответить на каверзные вопросы. Дальше еще 5-10 лет настоящих задач, чтобы стать профи. Повышение зряплаты при этом зависит от галеры.
>Прата
Не читал.
>>1753606
Простите, сегодня перечитал свой вопрос, никакой дополнительной информации не предоставил.
Итак:
Win10
Code::Blocks + очевидный MinGW (шел вместе с CodeBlocks, должен быть последний).
* Из чтения разной документации пришел к выводу что больше всего мне подходит SDL2.
В гугле полно видео от индусов, но нихера не работает.
CreateWindowEx и весь стандартный win32 gui app skeleton, который можно без проблем спиздить в гугле. По WM_PAINT ты просто BeginPaint/LineTo/ArcTo/EndPaint и все.
SDL тебе никаким образом тут не поможет, она про растровую графику, свои кружочки тебе придется по точечкам рисовать. OpenGL как бы умеет в линии, но это функциональность давно deprecated, а в современном OpenGL линии принято рисовать длинными и тонкими треугольниками. Поэтому из всех вариантов GDI - самый простой способ.
Это говорят про GDI+ (хотя GDI+ тоже можно, если заморочиться), а я говорю про GDI. Ничего серьезного на GDI давно не делают, но оно по-прежнему поддерживается, работает в любой винде, и достаточно просто в использовании: https://pastebin.com/raw/7nu7GzsP
Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
Где его можно посмотреть?
Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
TL;DR ищу гайд для написания lite аналога partition wizard с нуля.
>Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
>Где его можно посмотреть?
Форматирование это по сути создание базы данных на носителе. Посмотреть начиная с педевикии и списка источников.
> Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
Вручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера - это кремнием в транзисторах контроллера USB зашито.
Короч, тебе танненбаума "архитектура компьютера" внутривенно 2 раза в день до появления понимания.
>>1754353
Анон, послушай меня, самый простой способ и стаковерфлоу со мной согласен это bgi turbo c через dosbox.
В свое время я так и писал простенькую графику, рад в 21м веке узнать что нихуяшеньки не изменилось.
Новичку в си другого выбора не дано, то что тут выложено в gdi через указатели с нулем инфы и спецификаций. И то хуй найдешь.
Удачи вам.
добавил в compiler options:
-Wall -Wextra -pedantic -Wno-unused-parameter -std=c11
добавил в linker options:
-luser32 -lgdi32
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
А такое чтобы сразу работало есть?
> dosbox
Ну если тебе просто кружочек нарисовать, то самый простой способ - это JS и <canvas>, там даже устанвливать ничего не нужно. Я думал, мы о чем-то практически применимом разговариваем.
> в 21м веке узнать что нихуяшеньки не изменилось
В 21 веке завезли сишный апи для Skia, например. Признайся, ты просто не хочешь изучать ничего нового.
> с нулем инфы и спецификаций
MSDN более чем достаточно, там не только описания функций есть, но и вводные статьи, вот потыкай: https://docs.microsoft.com/en-us/windows/win32/gdi/windows-gdi Но для неосиляторов раньше специальная книжка была Feng Yuan "Windows Graphics Programming".
>>1754469
> VS же считается топом
Для серьезных проектов. Для хелловорлдов - что угодно, хоть вимы, хоть вскоды и саблаймы, хоть clion.
> Вчера полчаса ебался с scanf_s
Один запрос в гугле, первый результат. Или можно смириться и писать, как хочет MS.
> какие косяки могут быть впереди
Некоторые возможности из C11 поддерживаются только с бубном. Например, надо запустить VS Installer и доустановить там clang.
> И почему вообще в разных IDE абсолютно идентичный код может давать разный вывод?
IDE тут не при чем. Это проблемы твоего кода. Нормально пиши - нормально будет.
>современный уровень
>сейчас даже амуда искаропки в 4ггц+ идет
>>1739810
> Для Си умельцы скорее всего тоже либ уже налепили.
Зачастую, кстати, у С-дедов такие библиотеки дают лучшую производительность, чем у С++-миллениалов. Быстрее только на чистом ассемблере. Деды в целом и это могут, но долго это. Поэтому на чистом ассемблере пишут только местами: ту логику/вычисления, которая исполняется 85-99% от общего времени.