Программирование


Ответить в тред Ответить в тред

<<
Назад | Вниз | Каталог | Обновить тред | Автообновление
383 30 147

C Programming Language #58 /clang/ Аноним # OP 02/06/20 Втр 20:39:48 17112681
C Propaganda.jpg (1970Кб, 2000x2610)
2000x2610
Тред, посвященный прародителю всех С-подобных языков и по совместительству единственному идеальному и всесторонне годному средству программирования как на системном, так и на прикладном уровне.

Пожалуйста, пользуйтесь 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)
Аноним 02/06/20 Втр 23:28:00 17114392
>>1711268 (OP)
Я один не использую все эти typedef, #define и прочие операторы которые просто присваивают псевдонимы типам и константам?

Не думаю что эти функции особо нужны в ЯП. Поясните, пожалуйста, прав ли я или нет. Если нет то какое практическое преминение может быть этим typedef и define
Аноним 03/06/20 Срд 03:17:00 17115603
>>1711439
>typedef и define
ТРУ ФАЛСЕ БАЙТ
Аноним 03/06/20 Срд 03:51:38 17115804
>>1711439
Чтобы не размазывать в пределах модуля ololoverysometype тысячу раз, а писать какое-нибудь короткое ovstype
Аноним 03/06/20 Срд 04:17:22 17115885
>>1711439
typedef struct tagMyStruct
{
} MyStruct;
Аноним 03/06/20 Срд 07:22:05 17116066
>>1711439
макросы, макросики
Аноним 03/06/20 Срд 08:59:14 17116277
>>1711439
> Если нет то какое практическое преминение может быть этим 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
};
Аноним 04/06/20 Чтв 14:35:59 17129358
2020-06-04deite[...].jpg (114Кб, 822x638)
822x638
День добрый, подскажите скрин изкниги П. Дейтел, Х.Дейтел - С для программистов с введением в С11 - 2016 , первый выделенный printf работет нормально, второй вместо подчеркиваний цифры какие то печатал. пока я d на s не поменял и звёздочку не убрал. puts просто ошибку выдавало в С-free 5.0. Причем код в книжке и в исходниках одинаковый. Это опечатки или проблема в С-free + mingw5&
Аноним 04/06/20 Чтв 17:34:17 17131489
>>1712935
Это опечатки. Везде должно быть printf, c %s ты все правильно сделал, хотя смысл этих конструкций от меня ускользает, делать printf("%s", "строка") совершенно незачем. Это вся книга такая?
Аноним 04/06/20 Чтв 18:18:11 171318310
>>1713148
> делать printf("%s", "строка") совершенно незачем.
Это защищает тебя от format string атаки
Аноним 04/06/20 Чтв 19:58:58 171328111
>>1713183
Да ты что! Это с двумя константными строками?
Аноним 05/06/20 Птн 00:28:20 171356212
>>1713183
С кем воюешь, шизоид? Погбеб выкопал и сухпаёк уже собрал, на случай ядерной атаки?
Аноним 05/06/20 Птн 09:32:55 171371713
>>1713148

Странно что эти опечатки в исходниках повторяются которые с книгой шли, книгу тут анон выкладывал в ввиде картинки.
Аноним 05/06/20 Птн 10:12:35 171372914
>>1713562
Если бы было printf(user_data), тогда да, за это бить надо, пока не дойдет. Но в книге совершенно другой случай.
Аноним 05/06/20 Птн 12:55:10 171386115
Здравствуй, анон. Мучаюсь с макросами и _Generic в c11 в попытках написать небольшую библиотеку с типа-шаблонами и типа-перегрузкой функций.

Очень интересны следующие вопросы:
1) Есть ли способ по заданному целочисленному типу T получить соответствующий беззнаковый тип UT (например, по int32_t получить uint32_t, а по uint32_t - тоже uint32_t)?
Иначе говоря, пытаюсь запилить что-то в духе
__UNSIGNED(T) var;
которое после обработки будет
UT var;

2) Есть ли хотя бы просто способ проверить, что некий T является беззнаковым?

3) В дополнение ко (2): если известны все беззнаковые типы, которые потенциально могут использоваться, можно ли решить данный вопрос без нагромождений #if в каждом месте, где требуется определить знаковость?
Аноним 05/06/20 Птн 14:24:44 171390516
>>1713861
Ладно, для третьего вопроса пока есть такой говнокод:

#define CAT_2(X1,X2) X1##_##X2

#define __UNSIGNED_OF_int8_t uint8_t
#define __UNSIGNED_OF_int16_t uint16_t
...
#define __UNSIGNED(T) CAT_2(___UNSIGNED_OF,T)

Очень надеюсь, что есть что-то лучше.

Аноним 06/06/20 Суб 01:47:39 171474017
>>1713717
Правильно делают. Нормальный человек понимает что пишет, опечатки наоборот помогают учить язык. А дауны макаки бездумно перепечатывают, а потом ноют "пачиму ниработаит".
Аноним 06/06/20 Суб 22:23:46 171523618
Сап, двач. Есть ли где-нибудь годный сборник ВСЕХ UB? Ну, или хотя бы просто всех UB, связанных с целочисленной арифметикой и побитовыми операциями?
Аноним 07/06/20 Вск 01:30:53 171536419
Аноним 07/06/20 Вск 02:46:57 171539720
Аноним 07/06/20 Вск 02:54:22 171540021
Аноним 07/06/20 Вск 03:46:53 171540922
Аноним 07/06/20 Вск 08:31:29 171542823
index.jpeg (6Кб, 225x225)
225x225
>>1715236
>сборник ВСЕХ UB
А ты стандарт-то читал?
Аноним 07/06/20 Вск 09:13:25 171543224
14334349766410.jpg (50Кб, 300x300)
300x300
uint32_t testvalue = (((72000000 / 64) x (5 / 1000)) - 1);

Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
Аноним 07/06/20 Вск 09:31:14 171543425
6v3CLvEl5Q.jpg (173Кб, 1280x853)
1280x853
>>1715432
У тебя там все деления целочисленные.
Смекаешь?
Аноним 07/06/20 Вск 09:43:29 171543526
Аноним 07/06/20 Вск 09:55:16 171543827
>>1715236
> сборник ВСЕХ UB
В прошлом тредике что-то постили еще: >>1696945 →

>>1715432
Скобки раскрой, нахуй ты их вообще расставил?
Аноним 07/06/20 Вск 10:16:20 171544628
14280770828420.png (67Кб, 308x300)
308x300
>>1715438
>Скобки раскрой, нахуй ты их вообще расставил?
uint32_t testValue = (1125000 * (N / 1000)) - 1;
где N - изменяющееся число, от 1 до 20.
Аноним 07/06/20 Вск 10:18:44 171544929
>>1715446
Это не ответ, нахуй тебе скобки.
Аноним 07/06/20 Вск 10:22:19 171545130
>>1715438
Спасибо, поищу.

>>1715428
Мне нужны только undefined behaviour в чистом виде. Не понятно, причем здесь стандарт, где эти вещи надо выколупывать смому из тонн текста.
Аноним 07/06/20 Вск 10:24:22 171545231
092cb5d5dd5c77L.jpg (16Кб, 400x300)
400x300
>>1715449
Для красоты.

Как правильно преобразовать выражение, чтобы, сука, получить результат, как при решении на кулькуляторе?
Аноним 07/06/20 Вск 10:48:35 171545932
>>1715452
Тебе блять дебилу уже сказали: убери нахуй свои ебаные скобки. И все. Заебал.
Аноним 07/06/20 Вск 11:50:15 171548633
>>1715452
Ещё раз для тебя ебика повторю: У ТЕБЯ ТИП ЦЕЛОЧИСЛЕННЫЙ
Аноним 07/06/20 Вск 12:13:49 171548934
14291603992680.png (1286Кб, 2048x1536)
2048x1536
Аноним 07/06/20 Вск 13:08:05 171552635
Аноним 07/06/20 Вск 13:24:45 171553836
>>1715526
Нахуй там плавающая точка, если результат все равно обрезается до инта как раз после деления?
Аноним 07/06/20 Вск 13:56:58 171558437
Аноним 07/06/20 Вск 14:19:13 171563138
>>1715489
Нахуй ты пальцы постишь? Как думаешь что в целочисленных типах подставляется вместо X/1000 при x<1000?
Аноним 07/06/20 Вск 17:58:27 171585639
Пацаны, где скачать C89 стандарт? У меня пригорамба. Его удалили ото всюду.
Аноним 07/06/20 Вск 18:40:51 171588740
Аноним 08/06/20 Пнд 14:07:21 171672141
Допустим у нас объявлена структура и мы создали эту структуру в какой-то функции, вопрос: нужно ли использовать free() или она удалится из памяти по завершению функции?

Пример:

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) ???

}
Аноним 08/06/20 Пнд 14:32:14 171673642
>>1716721
> нужно ли использовать free() или она удалится из памяти по завершению функции?
Нет, такие переменные называются автоматическими, и они автоматически перестают существовать при выходе из функции. Но проще всего думать по-другому: если ты сам что-то выделил или открыл (с помощью malloc или там fopen), то ты сам и должен вызвать очистку. Тут ты никаких malloc не вызывал, поэтому и free сделать не можешь.
Аноним 08/06/20 Пнд 14:43:53 171674643
>>1716736
>автоматические
Может локальные?
И трутся потому что на стеке.
Аноним 08/06/20 Пнд 14:47:26 171675044
>>1716746
>автоматические
>локальные
Два разных понятия.
Аноним 08/06/20 Пнд 15:00:27 171675845
>>1716736
>открыл (с помощью malloc или там fopen)
Да, структура (а точнее её часть) создаётся calloc' ом. Думал это не существенно.

Пасиб).

П.С. удаляется структура через особую ф-цию если что, и free используется только для части с calloc.
Аноним 08/06/20 Пнд 15:33:39 171677946
Аноним 08/06/20 Пнд 16:21:50 171683047
>>1716779
Мануал почитать, не?
Аноним 08/06/20 Пнд 19:25:14 171701248
>>1716779
void foo(void) { int automatic_local; }
void bar(void) { static int non_automatic_local; }
void baz(void) { extern int non_local_non_automatic; }
Аноним 10/06/20 Срд 17:51:22 171881949
15917974218580.jpg (310Кб, 1280x720)
1280x720
Аноним 10/06/20 Срд 19:42:09 171887450
>>1718819
Я нихуя не понял. Оставил только 3 строчки, все остальное стер. Работает
Аноним 11/06/20 Чтв 12:25:30 171923151
>Кстати поясните нахуя МЦСТ свой ёбаный путь, когда, например, VIA делает процы на x86-x64? В чём суть?

Потому что штеуд запретил навсегда лицензировать хуй86 кому бы то ни было еще кроме лизочки писечки и собственно via.

Если бы штеуд разрешал пилить х86 этим бы не то что МЦСТ этим бы 3/4 производителей чипов бы занимались шутка ли такое-то легаси.
Аноним 11/06/20 Чтв 20:13:51 171981852
>>1719231
Ну ведь есть не только хуй86. Тут даже десктопные пека теперь будут на самой популярной архитектуре "скоро". Что скажешь?
Аноним 12/06/20 Птн 14:08:16 172034853
Поясните более подробно за указатели и адреса молю.

Чем отличается
int c
от int
c

Такая непонятная хуйня уже весь мозг себе сломал.
Аноним 12/06/20 Птн 14:10:39 172035154
>>1718874
>нихуя не понял
потому у него cpp он тредом ошибься.
Аноним 12/06/20 Птн 15:55:24 172044955
>>1720348
Понять указатели это как девственности лишиться. Сиди и думай
Аноним 12/06/20 Птн 16:03:03 172045656
>>1720449
я листва дo сих пoр. пoэтoму oбъясни мне, мoлю. или дай хoтя бы ссылку на какoй-нибудь мануал пo ним.
Аноним 12/06/20 Птн 16:04:09 172045957
>>1720348
>>1720449
тo есть oтличается

int "звздoчка"с

int"звёздoчка" с
Аноним 12/06/20 Птн 16:07:24 172046258
Аноним 12/06/20 Птн 16:24:00 172048859
>>1720449
хули там понимать, за 1 час можно понять всю суть указателей
Аноним 12/06/20 Птн 16:26:44 172049160
Аноним 12/06/20 Птн 17:40:55 172056761
Аноним 12/06/20 Птн 17:43:52 172057362
>>1720567
C18? Алсо, кто его запил, Ритчи же давно нету.
Аноним 12/06/20 Птн 17:46:03 172057863
Аноним 12/06/20 Птн 17:50:33 172058564
>>1720348
>int c
>от int c

временем жизни
Аноним 12/06/20 Птн 17:51:23 172058865
>>1720585
двач проглотил звёздочки просто которые должны были показать разницу между ними.
Аноним 12/06/20 Птн 23:53:40 172102266
Аноним 13/06/20 Суб 07:15:28 172116367
>>1721022
Ну нахуя шизоиду отвечаешь?
Аноним 13/06/20 Суб 14:33:34 172138868
Аноним 13/06/20 Суб 15:55:29 172146869
>>1721388
Вопрос то у меня не по ней, а конкретно по libcurl.
Аноним 13/06/20 Суб 20:49:22 172185770
>>1719818

Есть именно что хуй 86, убивший за 30 лет нахуй всех своих конкурентов - Power, Alpha, SPARC.

Если ты про арм - то он не конкурент, даже в самых своих мощных реализациях от яблока и квалкома он кукурузнее самых неудачных фуфыксов.
Аноним 13/06/20 Суб 23:06:50 172197771
>>1721857
arm убьёт x86, можете скринить. А потом будет RISC-V.
Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать, да и бум мобилок ускоряет заколачивание гроба.
Аноним 13/06/20 Суб 23:55:55 172201472
>>1721977


> arm убьёт x86

Не убьет.

> бум мобилок ускоряет заколачивание гроба

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

В то время как бэкенд по прежнему крутится на могучих х86 зивонах и никаким немощным рукам их там не потеснить - когда доходит до дела - нужна честная моща пер коре а не кукуруза с многоядерным потанцевалом и проблемой рожающих бабищ в 99% реальных задач.

> Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать

Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.

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

Дошло до того что зеоны ебут уже который год считавшихся непобедимыми динозавров от IBM (POWER и Z).

Аноним 13/06/20 Суб 23:58:36 172201573
>>1722014

Да и, собственно, с появлением дохуядерных эпичей от лизки и дохуядерных платинов от штеуда, арм на серверах закопан нахуй окончтельно.
Аноним 14/06/20 Вск 00:49:29 172205374
image.png (10Кб, 553x39)
553x39
image.png (5Кб, 381x54)
381x54
Пацаны, че за хуйня. Работаю над кодом вместе с libusb.

Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.

Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)

Аноним 14/06/20 Вск 00:58:11 172206275
>>1722014
Новые армы в бенчах уже показывают сравнимый с интелами результат: https://www.macrumors.com/guide/arm-macs/ - и это при в разы меньшем tdp. У интелов же - родовая травма в виде сложного декодера и малого числа именованных регистров, из-за чего им крайне сложно повышать число инструкций на такт. Ты забыл, так я напомню - во времена Haswell интелы росли в однопотоке на 3-5% на поколение. И мы сейчас вполне можем вернуться в это страшное время.
Аноним 14/06/20 Вск 01:47:01 172209676
>>1722062
>2020
>хвалить обоссанную ноусофт консоль
Я уже молчу, каким отбитым имбецилом надо быть, чтобы не видеть разницы игрушки от компьютера с набором софта за 40 лет. Ах да, это же пердоля с таким же ноусофтом и пердольными игрушками. Вот откуда рак и деградация лезет, из этого отстойника скама человеческого.
Аноним 14/06/20 Вск 02:22:41 172210477
>>1722014
>Не убьет.
Скринь.

>Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона...

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

>Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
Ага, что вкупе с обратной совместимостью, а также всякими непрозрачными архитектурными перделками превратило типичный проц от, допустим, интела в никому не понятный ОГРОМНЫЙ чёрный ящик с кучей бекдоров, какими-то встроенными микро-ос и прочим хламом. А агрессивные попытки все это заставить быстрее работать оборачиваются очередными уязвимостями.
Аноним 14/06/20 Вск 02:24:27 172210678
>>1722096
Ну да, ну да - смартфон нинужон, дубль два. Конец уже сейчас предсказуем - нынешний айпад про станет новым форматом железа, и у жужжащих ящиков пропадет ещё половина рынка. Потом вендоры АРМ и ПОСов подтянутся и интелов станет ещё меньше. Слона съесть несложно, ежели по частям.
Аноним 14/06/20 Вск 02:25:35 172210779
>>1722096
>с набором софта за 40 лет
Какой, нахуй, софт за 40 лет? Сейчас уже 95% реально используемого людьми софта либо open-source, либо скомпилировано под кучу других платформ, помимо windows+x86. Хоть на чайнике запускай.
Аноним 14/06/20 Вск 02:26:03 172210880
Аноним 14/06/20 Вск 04:00:34 172214281
>>1722108
Зделой объявление функции перед мейном.
Аноним 14/06/20 Вск 09:05:00 172218182
>>1722107
>Какой, нахуй, софт за 40 лет?
Вот двачую. Игорей конца 90 уже хер где запустишь, разве что в эмуляторе, что съедает хваленую производительность хуй86.
Аноним 14/06/20 Вск 22:31:59 172306683
>>1722108
Если ты установишь эту либу на систему, она будет подключена как

[code]
#include <libusb-1.0/libusb.h>
[/code]
.
Аноним 15/06/20 Пнд 00:29:37 172313284
Нужен кто-то, кто мог бы решить ряд задач из университетского курса. Процессы, нити. С деньгами постараюсь не обидеть, обсудим.
Если кого-то заинтересовало - пишите в тележку
@twoomer
Аноним 16/06/20 Втр 11:31:38 172450985
Тред живой?
Аноним 16/06/20 Втр 11:46:26 172452186
Помогите найти простые примеры программ и игр на си, а то я пробовал выдает только c++ и c#
Аноним 16/06/20 Втр 13:15:07 172459387
>>1724521
Движок игры Дум (1993 год) напиан на Си, например.
А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой.
С++ - идеальный варик для ГЕЙдева.
16/06/20 Втр 13:32:35 172461888
>>1724521
Луа, гну сциентифик лайбрари. Первое это полноценный язык, занимающий всего пару тысяч строк кода. Второе образец того, как должна была выглядеть лаба1.с - реализация различных математических алгоритмов типа оптимизации, линейкит итд.
Аноним 16/06/20 Втр 13:45:10 172462489
>>1724521
>Помогите найти простые примеры программ и игр на си

>>1724593
>Движок игры Дум (1993 год) напиан на Си, например.
>>1724618
>Луа, гну сциентифик лайбрари.
Вы нормальные? Он же просил простые игры, ПРОСТЫЕ!
Аноним 16/06/20 Втр 14:15:48 172465090
Аноним 16/06/20 Втр 14:18:48 172465391
>>1724593

>А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой

Если подключить Lua или иную скриптопарашу, а сами си использовать онли для низкоуровневых кишочков, то не так уж и больно.
Аноним 16/06/20 Втр 14:59:17 172468392
>>1724653
все равно, все это попытка высрать баржу, гораздо более здраво писать такие вещи на С++ (или Сишарпе, смотря какой API хочешь и вообще какие требования к игре)
Аноним 16/06/20 Втр 15:35:04 172471893
Нравится Си тем что язык не сложный, небольшой, не нужно изучать постоянно всякие фреймворки как в JS или Java. Вот только сомневаюсь что смогу найти работу. Для системных программистов высокие требования. ВО, а его у меня нет. Большой опыт работы, которого у меня тоже нет. Мало вакансий. Что делать?
Аноним 16/06/20 Втр 15:44:56 172473694
>>1724718
Если ВО - не варик, то учи сам + пили личные проекты, офк нетривиальные. Это единственный выход.
А вообще - байтослесарям сложно найти работу в странах СНГ. Они больше ценятся забугром, там и embedded software engineer получает не меньше, чем жс-макака. В СНГ, увы, ситуация далеко не такая.
Аноним 16/06/20 Втр 16:22:41 172480795
Аноним 16/06/20 Втр 17:18:57 172490396
>>1724718
>не нужно изучать 3рд пати хуйню
Не нужно только до того момента пока ты тыкаешься в хеловорлды и линкедлисттуториал.с, в реальности же даже в современную микруху ты со знанием голого си не потыкаешься.
Аноним 16/06/20 Втр 17:28:45 172491997
>>1724903
Сравнение неподходящее. Какие то небольшие либы сравниваешь с монструозными фреймворками.
Аноним 16/06/20 Втр 17:44:47 172493398
>>1724919
>какие-то небольшие либы
Это конкретно в примере с бытовой микрухой может оказатсья КАКАЯ-ТО НЕБОЛЬШАЯ ЛИБА. И ты забываешь, что именно монструозность сишных фреймворков в прошлом, — вроде того же опенгла, старых директексов, снящихся в страшных снах людям вин32 и прочего, — стала от части причиной появления менее монструозных фреймворков на более современных языках. То что эту хуйню перестали использовать не значит что этого никогда не было. И не значит что не существует до сих пор поддерживаемых на них продуктов
Аноним 16/06/20 Втр 17:48:54 172493899
Алсо проиграл с луа с сурсом в сто строк пиздец
Аноним 16/06/20 Втр 20:49:54 1725165100
Аноним 16/06/20 Втр 20:55:45 1725172101
>>1724933
> старых директексов
И давно DirectX, у которого API на COM, стал сишным фреймворком? А вот опенгл нихуя не монструозный, полноценную реализацию OpenGL 1.x с софтварным рендером можно целиком написать в одно рыло, и код, как пользовательский, так и самой либы, будет понятен, в отличие от крестов в том же DirectX.

На самом деле проблема геймдева на Си заключается в менеджменте памяти в основном. Когда большие мальчики обмазываются всякими RAII и автоматическими указателями, когда они даже не знают, сколько раз выделилась память для их строчек, и сколько раз эти строчки при конкатенации скопировались, ты по-прежнему вынужден ебаться с goto cleanup и маллоками на каждый чих. И это слегка демотивирует. Чтобы как-то обойти эту проблему, ты тащишь статические буферы везде, куда сможешь дотянуться, что создает кучу других, еще более веселых проблем.
Аноним 16/06/20 Втр 21:09:03 1725178102
Аноним 16/06/20 Втр 21:33:48 1725210103
>>1725172
>И давно DirectX, у которого API на COM, стал сишным фреймворком?
COM - сишный API. Лично юзал DirectX из сишного кода.

Аноним 16/06/20 Втр 22:09:00 1725257104
>>1725210
>COM
Нет. Это общеязыковой api для винды. Его можно юзать на вижуал бэйсике.
Аноним 16/06/20 Втр 22:19:01 1725268105
>>1725257
Технически, это сишный АПИ (функции с cdecl типом вызова, экспортируемые из DLL) + набор соглашений.
Аноним 16/06/20 Втр 22:40:35 1725291106
>>1725268
Потому что на Си написан? Хотя я сомневаюсь, скорее всего на плюсах. Никакой это не сишный апи. Вот libc в линуксе да, чисто сишный.
Аноним 16/06/20 Втр 22:49:48 1725299107
>>1725210
Да, юзать COM еще туда-сюда из сишки можно. Если MS не забыла для тебя кроме варианта class написать в хедере все эти struct и STDMETHOD, обмазав толстым слоем макросов (посмотри, в заголовках директикса отдельный #ifdef для сишки... пока еще есть или уже нету в последних версиях?). С реализацией своих объектов начинается боль, особенно когда у тебя несколько интерфейсов. Да, их тоже можно на си писать, можно хоть на ассемблере писать, но это будет больно, это будет тонна однотипных реализаций QI/AddRef/Release, которые нельзя объединить, потому что офсеты lpVtbl в структуре у разных интерфейсов разные. При этом на крестах вся эта боль почти целиком уходит. Поэтому COM - крестовый.
Аноним 16/06/20 Втр 22:53:12 1725308108
>>1725210
> Лично юзал DirectX из сишного кода.
Алсо, я забыл добавить. Я вот юзал std::string из сишного кода (на лету генерировал обертки, превращающие __thiscall в __stdcall). Он стал от этого сишным?
Аноним 17/06/20 Срд 10:00:14 1725827109
>>1725308

> Я вот юзал std::string из сишного кода

А животных ты часом не ебёшь, извращенец?)))
Аноним 17/06/20 Срд 11:51:23 1725888110
Аноним 17/06/20 Срд 17:35:43 1726247111
cuck.jpeg (25Кб, 460x460)
460x460
>>1725888
>Черная живет материя!
Вопрос: почему есть место для белых whitespace, а для чёрных нет?
Аноним 17/06/20 Срд 18:32:51 1726329112
изображение.png (596Кб, 880x495)
880x495
>>1726247
Место для чёрных это backspace.

Кстати, забавляют эти потуги белых людей решать за чёрных людей, что для них оскорбительно, а что нет. Это же вроде расизм, разве нет?
Аноним 17/06/20 Срд 19:30:40 1726389113
image.png (18Кб, 749x53)
749x53
image.png (10Кб, 1139x28)
1139x28
>>1711268 (OP)
Хочу, чтобы у меня на всех окнах было одинаковое верхнее меню (File, Edit, View, ...), но GTK почему-то не разрешает мне это сделать. Как фиксить?
Аноним 17/06/20 Срд 20:55:55 1726446114
>>1725888

Лол, у нас на работе ради прикола переименовали master-slave на master-pokemon. Но это ещё до всей этой хуйни было.
Аноним 17/06/20 Срд 22:38:52 1726556115
>>1711268 (OP)
https://pastebin.com/gRC0UScq
Где я проебался с выравниванием, что atoi падает с сегфолтом?
В omp parallel нельзя выделять выравненную память?
Аноним 17/06/20 Срд 22:44:09 1726560116
>>1726556
Блять, я сонный ебаный не передавал количество тредов при запуске. C господа, отбой.
Аноним 18/06/20 Чтв 10:06:50 1726773117
Как удалить строку из файла силами C? Занести все строки файла в оперативную память, пересоздать файл и занести их обратно?
Аноним 18/06/20 Чтв 10:15:02 1726779118
>>1726773
Закинуть кусок файла после строки в память, удалить строку (и после не забыть fseek выставить на последний байт перед удаленной строкой), записать ранее сохраненный кусок по SEEK_CRT.
Аноним 18/06/20 Чтв 10:20:35 1726784119
>>1726779
>удалить строку
Прости хоспаде. ничего не удаляй, просто выстави fseek на первый байт той строки и пиши.
Аноним 18/06/20 Чтв 10:34:34 1726807120
>>1726773
Правильный способ от олда:
1. создал временный файл
2. читаешь по символу, считаешь строки, пишешь во временный
3. fflush
4. rename(временный, оригинал)
Аноним 18/06/20 Чтв 23:34:27 1727670121
>>1726784
Как лишние символы затереть?

>>1726807
А как сделать временный файл таким, чтоб не было пересечений с уже существующими файлами в папке?
Аноним 19/06/20 Птн 00:40:05 1727708122
>>1727670
tmpfile() тебе дали и tmpnam() еще.
Аноним 19/06/20 Птн 01:36:42 1727736123
>>1711588
за такое говнище надо сразу в ебало давать
Аноним 19/06/20 Птн 11:29:27 1727907124
Аноним 20/06/20 Суб 14:57:10 1728937125
Снимок экрана 2[...].png (918Кб, 2880x1800)
2880x1800
Аноны, как заменить gets() на fgets()?
Аноним 20/06/20 Суб 15:51:43 1728985126
>>1728937
fgets(указатель на массив, кол-во читаемых символов, stdin)
Только он вносит символ перевода строки в строку, а не выкидывает его оттуда. Можешь либо свою функцию написать, либо обёртку для fgets, которая выкидывает символ перевода строки и очищает входной поток.
Аноним 20/06/20 Суб 16:14:47 1729004127
Аноним 20/06/20 Суб 16:24:12 1729013128
>>1729004

Лол, зачем ты проверяешь неравенство с NULL? Можно же просто булевоское значение указателя взять.
Аноним 20/06/20 Суб 16:31:57 1729019129
Аноним 20/06/20 Суб 18:37:06 1729115130
>>1729019

1) у вскякого арифметического типа (указателя, например) есть будевское значение. Если указатель не нулл, он true.
2) ты не проверяешь ошибки выделения памяти. это хуёво.
3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
4) ваще, какое-странное решение отмечать конец массива строк пустой строкой. Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом? в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
Аноним 20/06/20 Суб 19:21:07 1729141131
>>1729115
> используй strncpy
Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
Аноним 20/06/20 Суб 20:17:36 1729187132
>>1729141
>Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?

чёт обосрался я. запишем в конец буфера ещё нолик в любом случае.
Аноним 20/06/20 Суб 20:26:11 1729201133
>>1729115
>Если указатель не нулл, он true.
Вроде это ебота от платформы зависит. null не всегда равно 0x00.
>2) ты не проверяешь ошибки выделения памяти. это хуёво.
Согласен. Но это нахуй никому не нужный привет_мир на две-три сотни лайнов.
>3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
Что и в п.2

>4) ваще, какое-странное решение отмечать конец массива строк пустой строкой.
Мне так местные посоветовали.
>Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом?
Хорошая идея, пока лучшая.
>в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
Тогда маленький мемори-лик, да. Но строки будут непустыми.

>5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.

Внезапно для меня realloc() может вернуть указатель с другим значением. Не знаю с чем это связано, но очевидно не с brk(), так как после фиксированной n строки значение указателя меняется(алсо меняются и указатели на строки). Я потому сюда и закинул эту хуиту, уж больно уродливо вышло.
Аноним 20/06/20 Суб 22:18:51 1729273134
>>1729201
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.

короч, null pointer константа по стандарту - арифметическая константа, имеющая значение 0. или таковая, приведённая к типу (void звёздочка). чёт, я не смог прм точную цитату в стандарте про обратное преобразование лул, но все другие источники говорят, что булевское значение указателя true тогда и только тогда кода он не null pointer.
>>1729201
>realloc() может вернуть указатель с другим значением

ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
Аноним 21/06/20 Вск 00:37:03 1729355135
>>1729201
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
Нет. Это в стандарте языка, здесь от платформы ничего не зависит.
if (ptr == NULL) пишут только зеленые касатики, прошаренные бати знают, что первое - говнокод, и кошерно писать if (!ptr)
Аноним 21/06/20 Вск 02:48:18 1729389136
>>1729273
> я не смог прм точную цитату в стандарте про обратное преобразование лул
Его нет. if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0. Операторы сравнения != и == сами автомагически умеют сравнивать указатель с нулевым указателем такого же типа, каким бы не было представление. И уже у операторов сравнения на выходе инт.

>>1729355
Не говнокод ни разу. Исключительно вопрос выбранного стиля. Явное сравнение лучше читается, плюс некоторые пишут выражения вида if ((ptr = func()) != NULL), в них без != NULL нельзя - будет варнинг. Из этого выражения явное сравнение ради консистентности растекается и на if (ptr != NULL), и на if (ptr == NULL).
Аноним 21/06/20 Вск 12:36:48 1729488137
>>1729389
>будет варнинг

клангу похуй
Аноним 21/06/20 Вск 12:51:34 1729503138
>>1729389
>if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0

по маняопределению.
не видел такого в стандарте. там только написано, что арифметические типы имеют булевское значение true если не равны нулю. Указатели же неявно преобразуются к арифметическому типу. Про нулл поинтер сказано, что он - нулевая арифметическая константа или результат её приведения к типу войд звёздочка. Явно про обратное преобразование не сказано.
Аноним 21/06/20 Вск 13:37:47 1729536139
>>1729355
> if (ptr == NULL) пишут только зеленые
Зеленый жир, плиз.
Писать надо:
if (NULL == expression)
потому что expression может быть длинное, функция, и смотреть в конец неудобно и не наглядно, код плохой получается. А когда в начале, сразу видно что и как.
Аноним 21/06/20 Вск 17:14:09 1729698140
>>1729273
>ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
Добра тебе, мелкобуквенный гений. А я просто приучил себя к указателям, как собаку Павлова.
>>1729389
>в них без != NULL нельзя - будет варнинг
Кстати вспомнил, почему так и начал писать, т.к. раньше тоже !ptr юзал. Энивей какой-нибудь -pedantic варнинг родит.
Аноним 21/06/20 Вск 17:39:00 1729708141
>>1729698
>Энивей какой-нибудь -pedantic варнинг родит.
Нет, я снова обманывать, с таким сетом флагов
>-Wall -Wextra -std=c99 -pedantic
gcc молчит.
Аноним 21/06/20 Вск 19:01:26 1729784142
>>1729503
> по маняопределению.
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)
Толсто.
21/06/20 Вск 19:02:29 1729786143
>>1729784
> вменяемом комментарии
компиляторе
Аноним 22/06/20 Пнд 06:32:23 1730265144
Не смог нагуглить, как сделать вывод в консоль,чтоб сверху или снизу выводилась строка состояния, а в остальных строках выводились данные из другого потока и чтоб они не перезаписывали строку состояния в идеале чтоб данные прокручивались а строка состояния была на своем месте
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
Аноним 22/06/20 Пнд 06:33:32 1730267145
>>1730265
это на линуксе должно работать
Аноним 22/06/20 Пнд 06:42:43 1730275146
Аноним 22/06/20 Пнд 11:26:35 1730399147
Объясните, в каких случаях принято делать структуру с указателями на функции? Чем обычное объявление функций хуже?
Аноним 22/06/20 Пнд 14:48:20 1730593148
>>1730399

1) колбеки в чяужую библиотеку

2) массив функций, вызов по номеру без свитч-кейс без регистрации

3) реализация опенгл под шинду - там по умолчанию изкаробки только фичи из конца девяностых, за нулевыми и десятыми с их шейдерами нужно добывать как руду у драйвера через указатели на функции..
Аноним 25/06/20 Чтв 00:24:23 1733128149
Привет, анон. Есть какой-то известный быстрый алгоритм для перевода дробной части, записанной в бинарном виде, в строку с десятичной записью? Дробная часть может быть 128 бит, так что, видимо, конвертация в double и печать в строку не катит.
Аноним 25/06/20 Чтв 12:49:43 1733499150
>>1733128
Я как-то из интереса попытался на асме написать функцию вывода числа типа 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 и нуля обрабатывать отдельно
Аноним 25/06/20 Чтв 12:51:18 1733500151
>>1733499
Блядское форматирование. Фикс.

0,1101 = (1/2) + (1/4) + (1/16) = 0.5 + 0.25 + 0.0625 = (1000×5 + 100×5^2 + 5^4)×10^(-4)
Аноним 25/06/20 Чтв 15:05:58 1733607152
>>1733500
а теперь вали читать IEEE754 и плакать
Аноним 25/06/20 Чтв 15:24:31 1733626153
>>1733607
Можно вкратце, что не так?
Аноним 25/06/20 Чтв 16:26:29 1733669154
>>1733607
Ну, вообще да, с денормализованными числами так не выйдет.
Аноним 25/06/20 Чтв 19:55:01 1733892155
>>1733499
Это да, это понятно, но как это сделать без длинной арифметики (число бит для дробной части у меня большое)?

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

>>1733607
Ну, тем не менее, это релевантно для чисел с фиксированной точкой, с которыми я и мучаюсь.
Аноним 25/06/20 Чтв 22:19:06 1734007156
>>1733892
> но как это сделать без длинной арифметики
Никак, смирись и пили длинную арифметику. Не так уж это и сложно, можешь в столбик считать, как в школе.
Аноним 25/06/20 Чтв 23:56:26 1734065157
>>1734007
Эх, печаль. Я не спорю, что не сложно, просто для 128 бит это выглядит как оверхед. Ладно, поищу, может, есть ли portable-реализация __int128_t.
Аноним 26/06/20 Птн 04:37:32 1734184158
>>1734065
Мне казалось, что даже для float нужен как минимум int512, для хранения 5^n. Хотя, наверняка есть способ попроще.
Аноним 26/06/20 Птн 10:28:23 1734324159
Какую книгу можно почитать, новую, по последним стандартам Си? Кернигана и прату читал, но уже прошло много времени, подзабыл ось. Что-то новенького хочется. Подскажите.
Аноним 26/06/20 Птн 11:09:18 1734345160
>>1734184
Да, ты прав, я на свежую голову посчитал, там больше надо.
Аноним 26/06/20 Птн 12:29:35 1734390161
Аноним 26/06/20 Птн 22:19:29 1734855162
>>1711268 (OP)
Есть ли какие то подводные у:
typedef struct {...} struct_name;
Всегда ли можно писать так?
Аноним 26/06/20 Птн 22:59:38 1734882163
>>1734855
Единственный подводный - связанные структуры данных (элементы списков, деревьев), для которых ты не сможешь использовать тип, определяемый тайпдефом, внутри этого тайпдефа: typedef struct { ??? ∗next_node; int value; } linked_list_node; ну ты понял. Потому что этот тип на момент использования еще не существует. А вот у typedef struct foo { ... } foo; или typedef struct foo foo; struct foo {}; подводных нет. Второй вариант более многословный, зато позволяет при необходимости быстро отделить интерфейс от реализации: просто оставляешь тайпдеф как есть в .h, а структуру уносишь в .c, и если у тебя все манипуляции идут через указатель на foo, то пользовательский код никогда не узнает, что там внутри.
Аноним 26/06/20 Птн 23:05:13 1734886164
>>1734882
Про связанные списки я знал, а вот за разделение интерфейса и реализации спасибо, не знал.
Аноним 27/06/20 Суб 06:26:06 1735022165
>>1734886
тащемта, opaque pointers обеспечивают идеальную инкапсуляцию, абсолютно непробиваемую
27/06/20 Суб 07:38:43 1735035166
>>1734345
Вы про расширения SSE/AVX не слышали?
Аноним 27/06/20 Суб 10:49:52 1735075167
>>1735035
А откуда такая уверенность, что целевая платформа - x86?
Аноним 27/06/20 Суб 12:48:33 1735128168
Как сделать чтобы в выводе консоли изменялись лишь некоторые данные?

Ну допустим Я вывел

Таблица
Счёт: ++variable

И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.

Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
Аноним 27/06/20 Суб 12:52:41 1735130169
unnamed.jpg (52Кб, 512x331)
512x331
>>1735128
Вот скрин консольной таблицы из интернета чтобы анонам понятнее было.

Вот допустим это всё вывод моей программы. И мне нужно только чтобы подчёкнутое красным число 10 изменялось, допустим 9 или 11 12 13. При этом чтобы всё таблица не перевыводилась с нуля. Как это сделать?
Аноним 27/06/20 Суб 14:14:06 1735180170
Аноним 27/06/20 Суб 14:24:38 1735185171
Аноним 28/06/20 Вск 06:27:34 1735689172
>>1734345
Я насчитал минимум в 44 байта
Аноним 29/06/20 Пнд 13:57:03 1736782173
Аноны, без шуток, Сишечка может умереть лет через, скажем, 50? Знаю, тупой вопрос, да и мне к тому времени уже будет похуй, но чисто теоретически интересно.
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Аноним 29/06/20 Пнд 14:25:47 1736814174
>>1736782
Проблема с таким далёким будущим — мы даже не можем предсказать, не будет ли через 50 лет ассемблер ниже уровнем чем си, лол.

А вообще, сейчас есть тенденция запихать побольше ядер (т.к. частоты наращивать не получается) и единственное что можно гарантировать — будут востребованы языки хорошо умеющие в мультитрединг. И это явно не си, но и аналоговнет, что называется.

>Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст), но переписывать работающий софт который всех и так устраивает — это тупость.
Аноним 29/06/20 Пнд 14:57:31 1736857175
>>1736782
Нет, не может, C - это lingua franca программирования.
Аноним 29/06/20 Пнд 15:13:27 1736886176
>>1736814
>Есть смысл новый писать не на сях
Не все так однозначно. Много "безопасных" программ юзают туеву хучу сишных либ. Пример, за котором далеко не надо ходить, Дискорд. Написан на джаваскрипте, гуй - Электрон, но если ты откроешь memory layout процесса - ты увидишь кучу so(в случае с Линуксом)/dll(в случае с виндой), которые написаны на Сях. И там может быть дыра, так что даже такое якобы безопасное приложение уязвимо к атакам на память.
Учитывая, что даже в 2к20 продолжают писать на сях, а не только поддерживать тонну легаси, то хз-хз... При моей жизни Си точно не умрёт.
Аноним 29/06/20 Пнд 15:35:14 1736908177
>>1736886
Ну, разница в том, что у тебя вместо 30-ти 0-day CVE будет 15-20, это на самом-то неплохой прогресс как ни крути. А с другой стороны это хорошо так поднимет цены на рынке эксплоитов, хех.

Понятное дело, что они не умрут, на них в конце концов кода куда больше чем на каком нибудь коболе, который все ещё жив спустя 30+ лет умирания, только вот имхо — область точно сузится до переносимого ассемблера. Единственный прогноз, который вообще возможно сделать на эту тему.
Аноним 29/06/20 Пнд 16:35:40 1736975178
>>1736908
>переносимого ассемблера
Си и так переносимый ассемблер, алло. Это то, что делает Си неубиваемым ЯПом.
Аноним 29/06/20 Пнд 16:40:13 1736979179
>>1736975
А ещё на сях и плюсах написано куча софта, который спокойно можно написать и на чём нибудь другом, приём, вас плохо слышно.

Ядром, кодеками и драйверами всё как бы не ограничивается, всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
Аноним 29/06/20 Пнд 16:41:04 1736980180
>>1736979
>всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
Это едва ли не половина всего софта, написанного на сях.
Аноним 29/06/20 Пнд 17:16:08 1736999181
>>1736980
И какие игоры за последние 15 лет написаны на сях?
Аноним 29/06/20 Пнд 17:28:42 1737011182
>>1736999
Почти все. Я си с плюсами не различаю в этом вопросе, т.к. любой плюсовый геймдев стоит на куче сишных либ от опенгла до всяких физических движков.

Из именно игр — вроде как автор factorio говорил что она на чистом си написана.
Аноним 29/06/20 Пнд 18:07:20 1737051183
>>1737011
После 2000 года все перешли на С++

>Я си с плюсами не различаю в этом вопросе
Ясно

>физических движков.
Physx, bullet, havok - все С++.
Аноним 29/06/20 Пнд 18:17:34 1737068184
Homer-facepalm.jpg (170Кб, 590x387)
590x387
Аноним 29/06/20 Пнд 19:47:04 1737158185
>>1736782
Через 30 лет произойдет коболизация си.
Выжившие сишники будут поддерживать ядро пинус для марсоходов.
Аноним 29/06/20 Пнд 20:34:51 1737195186
>>1736814
Предсказать, что будет через 50 лет, в принципе невозможно. Разве можно было предсказать хоть примерное развитие современного телекома и программирования в 1970 году? Уильям Гейтс со своими 640 кб оперативы и то позже был.

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

Нет, не думаю, что C/C++ сохранится. Слишком уж динозавр из другого мира.
Аноним 29/06/20 Пнд 20:37:06 1737196187
>>1737051
>После 2000 года все перешли на С++
На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.

Плюсы очень спорное решение на самом деле.

Аноним 29/06/20 Пнд 21:04:18 1737219188
>>1737196
Разговор про игоры. Игорей, особенно крупных, на Си давно не пишут.
Аноним 29/06/20 Пнд 21:07:58 1737223189
>>1737195
>Нет, не думаю, что C/C++ сохранится
Лол, даже ссаный кобол уже лет 30 умирает, но никак не сдохнет, хотя кода на нем написано в десятки тысяч раз меньше, чем на С/С++

>развитие супер параллельных процессоров, нейро-процессоров
И подноготная всей этой параши будет как всегда на С/С++

Скорее джаваскрипт сдохнет в вебе (нет), чем С/С++ в системщине и подноготной всея мира ойти технологий
Аноним 29/06/20 Пнд 22:02:59 1737294190
>>1737223
Кобол уже 30 лет назад сдох, просто где-то до сих под используется древний софт на древних компах или их эмуляторах.

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

Но само программирование может драматически измениться с тем, как поменяются парадигмы программирования.

Тупо сишечка и плюсы плохо предназначены для многопоточного программирования. А эволюция очевидно идёт в направлении супер-многопоточного программирования. Потому что возможности одного ядра давно исчерпаны, по мелочам как-то оптимизируют, зато вот возможностей для увеличения количества ядер очень и очень много. Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер (блядь, кто-нибудь в 70-е годы мог предсказать микро-сд карты на сотни гигабайт за копейки?), но для этого надо принципиально менять парадигмы программирования и платформы.

Это неизбежно произойдёт. Но как именно это будет выглядеть невозможно предсказать.
Аноним 29/06/20 Пнд 22:09:52 1737299191
>>1737294
> Тупо сишечка и плюсы плохо предназначены для многопоточного программирования
Не неси хуйню
Аноним 29/06/20 Пнд 22:10:54 1737300192
>>1735075
А надо сразу уточнять тогда, здесь провидцев нет.
Аноним 29/06/20 Пнд 22:13:39 1737304193
>>1737294
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Пруф? Пока выглядит как высер, не обессудь.
Аноним 29/06/20 Пнд 22:14:17 1737305194
>>1737196
>На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Фантазии. Отдельные чудаки могут писать на чем угодно, но стандарт индустрии - с++ и с#.
Аноним 29/06/20 Пнд 22:17:03 1737306195
>>1737294
>Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер
Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.

>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Отлично приспособлены, ничуть не хуже любого другого языка.
Аноним 29/06/20 Пнд 23:24:54 1737362196
>>1737306
>Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.

С гигагерцами ПОКА есть проблемы, количество транзисторов на кристалл до сих пор растёт по экспоненте.

https://youtu.be/c01BlUDIlK4
Аноним 30/06/20 Втр 01:31:58 1737433197
>>1736814
>будут востребованы языки хорошо умеющие в мультитрединг.
Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело.
>Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст)
Раст не даёт той безопастности, о которой ты говоришь и думаешь.
>но переписывать работающий софт который всех и так устраивает — это тупость.
Всё так, а ещё большая тупость - менять коней на переправе.
Аноним 30/06/20 Втр 02:22:33 1737456198
>>1737433
>Раст не даёт той безопастности, о которой ты говоришь и думаешь.
Что ты имеешь в виду?
Аноним 30/06/20 Втр 09:21:11 1737555199
>>1737305
> стандарт индустрии - с#
Во влажных фантазиях M$-фанбоев, клепающих миллионный по счёту три-в-ряд.
30/06/20 Втр 10:55:16 1737629200
>>1737294
>микро-сд карты на сотни гигабайт за копейки?
где бы такую купить...
Аноним 30/06/20 Втр 11:29:12 1737662201
>>1737362
>С гигагерцами ПОКА есть проблемы
В середине нулевых был достигнут современный уровень, 3.5 GHz, на процессоре пентиум-4. Дальше он не рос, производительность увеличивалась за счёт качества архитектуры, а не тактовой частоты. Зачастую тактовая частота снижалась, а потом заново увеличивалась.

А вот количество транзисторов до сих пор растёт по экспоненте. Усложняли ядра, добавляли кеш-память, добавляют ядра. AMD уже разродился процом на 64 ядра. На видеокартах тысячи примитивных ядер, есть ai-ускорители на тысячи ядер.

Ничто не мешает в принципе сделать и миллион ядер. Пока немного не хватает технологий для этого. Но развитие идёт к тому, чтобы поддерживать массовую параллельность. А от языка требуется, чтобы он нативно удобно поддерживал массовую параллельность, как в гошечке это есть.
Аноним 30/06/20 Втр 11:57:16 1737692202
>>1711268 (OP)
Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART? Мне нужен элементарный flow controi, т.к. апапартной поддержки нет, а софтварный XON/XOFF очевидно не подходит из-за "бинарности" отправляемого файла. Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе если бы не это, то уже давно навасянил бы какое-то кастомное простое говно
Аноним 30/06/20 Втр 12:28:52 1737718203
Аноним 30/06/20 Втр 12:30:24 1737721204
Аноним 30/06/20 Втр 13:05:08 1737761205
>>1737433
Вот это уровень дискуссии, высрал хуйню, потом почувствовал себя затралленым — и начал репортить)0

Можно засчитывать слив питушку.
Аноним 30/06/20 Втр 13:06:05 1737763206
Мочер, а ты сам-то хоть читаешь что трешь?
Аноним 30/06/20 Втр 14:55:52 1737851207
>>1737721
>>1737718
Не очень хочется заниматься этой конвертацией говна и уменьшать и так не очень большую максимальную скорость передачи...
Но наверное ты прав, тут либо извращаться и пилить свой протокол, либо извращаться и использовать.то, что ты предложил.
Аноним 30/06/20 Втр 15:10:59 1737875208
>>1737692
>Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART
>Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе
zmodem
Аноним 30/06/20 Втр 21:52:15 1738434209
>>1724521
dcss на си написан. Там открытый код.
Аноним 30/06/20 Втр 23:28:37 1738506210
>>1738434
>dcss на си написан
с++
Аноним 01/07/20 Срд 02:38:21 1738580211
>>1737662
> AMD уже разродился процом на 64 ядра
128.
Аноним 01/07/20 Срд 02:41:41 1738583212
>>1737662
> Ничто не мешает в принципе сделать и миллион ядер
А ты видео то смотрел? С увеличением кол-ва ядер увеличивается сложность алгоритмов, затраты на планировку и вообще при таком количестве ядер, все алгоритмы поломаются и просто перестанут работать без должных оптимизаций.
Аноним 01/07/20 Срд 04:38:37 1738613213
>>1738583
>все алгоритмы поломаются и просто перестанут работать без должных оптимизаций

в треде о том и разговор, что в ситуации, когда рост производительности идёт в многопоточном плане, без роста однопоточной производительности, нужно а) использовать другие алгоритмы б) использовать инструменты, языки и стили программирования которые (лучше) позволяют автоматически параллелизовывать написанное. Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
Аноним 01/07/20 Срд 11:04:45 1738713214
>>1738613
>Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
Звучит правдоподобно.
Аноним 01/07/20 Срд 11:57:48 1738762215
>>1737875
Слишком сложно или нет? я хуй его знает, загуглил готовые реализации - вроде очень много кода
Аноним 01/07/20 Срд 11:58:25 1738763216
>>1738713
bitches dunno bout mah #pragma omp for
Аноним 01/07/20 Срд 12:31:01 1738797217
>>1738613
>Ну тип, если функцианальник и часто испольешь мапы в своём коде
То это говно на списках создает кучу cache miss'ов и прочего говна. А если заюзал pragma omp parallel for, то все просто и понятно
Аноним 01/07/20 Срд 12:55:56 1738839218
>>1738583
В том-то и задача языка, чтобы сделать программирование таких алгоритмов и задач лёгким и непринуждённым.

Си слишком дубовый, слишком явный и низкоуровневый. Иногда это хорошо, для каких-то системных задач, но иногда нет.

Возможности для конкурентности сильно ограничены из-за этого.

В Го отдельный тред-поток исполнения запускается просто оперетором "go", удобные каналы и агрегаторы каналов (селекты). Не нужно думать, что там внутри, не нужно детально прорабатывать схему распараллеливания, не нужно всяких #pragma-костылей. Просто запускается отдельный поток. Ты уже просто думаешь на языке потоков и корутин. В си так просто не получится. И сам язык внутри для таких задач не предназначен.

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

Это просто один из примеров. Го мне не нравится, но эта концепция явно хорошая и удобная, думаю будет заимствована языками следующего поколения.
Аноним 01/07/20 Срд 13:56:08 1738895219
>>1738839
НЕ НУЖНО #PRAGMA-КОСТЫЛЕЙ
@
НУЖЕН ОПЕРАТОР GO

Пиздец ты долбоёб, конечно, земля бетоном
Аноним 01/07/20 Срд 14:19:02 1738913220
>>1738895
НЕ НУЖНО GOTO-КОСТЫЛЕЙ
@
НУЖНЫ ОПЕРАТОРЫ ЦИКЛОВ

Чел, ты же понимаешь что ты дебс? Другой анон.
Аноним 01/07/20 Срд 17:45:34 1739186221
>dstrcat(str, list[p->a && !pre_rec? 3 : 2]);
а за такое выебут?
Аноним 01/07/20 Срд 18:10:44 1739221222
Котаны, мне нужно передать в функцию указатель на буфер с данными типа uint8_t. А в функции я хочу изменить значение этого указателя так, чтобы он изменился и на верхнем уровне. Т.е. я хочу сделать

uint8_t* p_frame = NULL;
func(p_frame);

И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
Аноним 01/07/20 Срд 18:23:55 1739242223
>>1739221
-вернуть адрес из функции:
uint_t func(uint8_t); //прототип
p_frame=func(p_frame);

-передать указатель на адрес:
func(uint8_t); //прототип
func(&p_frame);

В обоих случаях потребуется изменять декларацию функции. А вот как без изменений - хз.
Аноним 01/07/20 Срд 18:29:11 1739251224
Аноним 01/07/20 Срд 18:33:11 1739256225
>>1739242
>>1739251
Спасибо, наверное придется менять на второй вариант
Аноним 01/07/20 Срд 18:42:01 1739269226
>>1739221
Так себе подход, очень опасный в плане выстрелов в ногу
Сделай либо p_name = func(p_frame); либо
func(p_frame, &p_name);
Аноним 01/07/20 Срд 18:59:56 1739282227
>>1739186
Скорее всего да, лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?: и непонятно чего ты хочешь
Аноним 01/07/20 Срд 19:01:40 1739285228
>>1739269
> p_name = func(p_frame)
Я уже возвращаю длину буфера этой же функцией, просто я упростил для примера
> func(p_frame, &p_name);
Мне нужно именно чтобы p_frame принял значение, вычисленное внутри. Больше мне ничего от функции не надо, только адрес буфера в памяти и длина буфера. В лоб можно было бы конечно передавать указатель на длину буфера как аргумент, а возвращать адрес. Я подумаю над этим.

А в чем опасность? Запутаюсь потом на верхнем уровне в указателях?
Аноним 01/07/20 Срд 19:11:54 1739296229
>>1739221
Верни число обработанных байт и прибавь потом к указателю.
&p передавать не оче хорошо, потому что компилятор свалит p на стек.
Аноним 01/07/20 Срд 19:34:14 1739323230
>>1739282
>Скорее всего да,
Ну я про такое вот индексирование в духе lea.
>лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?:
Всё что слева от знака вопроса - кондишн.
>и непонятно чего ты хочешь
передать нужный индекс.
Аноним 02/07/20 Чтв 00:02:05 1739525231
>>1738797
>То это говно на списках создает кучу cache miss'ов и прочего говна
нормальный компилятор со статическим анализатором видит, что у тебя список - не список(не нужна динамическая вставка т проч) и переделывает в массив. Плюс, ВНЕЗАПНО, мап может работать и на массивах и вообще на любых коллекциях. Далее, если у тебя на каждый кусок приличное независимое вычисление (вместо последовательности мапов ты сделал мап композиции функциий, кэш мисс твой нивелируется).
Аноним 02/07/20 Чтв 08:59:28 1739656232
>>1739525
>нормальный компилятор ... видит ... переделывает
Эту мантру повторяют со времен Коммон Лиспа. До сих пор компиляторы тупят.
Аноним 02/07/20 Чтв 09:04:57 1739657233
eto-drugoe-vy-n[...].jpg (93Кб, 1024x730)
1024x730
Аноним 02/07/20 Чтв 13:01:16 1739799234
>>1738839
Опять ньюфаги путают Concurrency и Parallelism. Иди кури мат. часть, а потом высирай тонны текста на двачах.
Аноним 02/07/20 Чтв 13:05:38 1739807235
Анон, объясни, почему язык строился вокруг такой ебанутой системы типов? Как можно было додуматься до этого монстра: unsigned long long int, а не стартовать изначально с типов фиксированной длинны (которые и записываются гораздо короче)?
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?

Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
Аноним 02/07/20 Чтв 13:06:48 1739810236
>>1738613
Найс аутотренинг. А нахуя ты свое /go/вно то здесь пиаришь? У меня и с плюсами процессоры не простаивают, есть корутины и тредпулы. Для Си умельцы скорее всего тоже либ уже налепили.
Аноним 02/07/20 Чтв 13:14:32 1739817237
>>1739807
А чего ты хочешь от переносимого ассемблера? 0 абстракции в случае с си — это же фича, лол.
Аноним 02/07/20 Чтв 13:27:29 1739836238
>>1739817
Так тут как раз и не 0 абстракции. Если бы типы были привязаны к байтам/словам/dword и прочее, то да. Но вместо этого преподносится лажа какая-то с замысловатыми плавающими ограничениями на размер. В итоге это нихрена не переносимый ассемблер. Но одной платформе int один, на другой - иного размера.
Аноним 02/07/20 Чтв 13:31:19 1739839239
>>1739807
Что тебе мешает пользоваться типами из stdint.h, которые тебе гарантируют одинаковый размер переменной на всех платформах?
Аноним 02/07/20 Чтв 13:32:30 1739842240
>>1739839
Ничто не мешает. Вопрос, почему это не по дефолту, а по дефолту какой-то франкенштейн.
Аноним 02/07/20 Чтв 15:28:35 1739926241
>>1739842
По причинам которые ты не знаешь, а администрация языка перед тобой отчитываться не будет. Кем ты себя возомнил, чучело?
Аноним 02/07/20 Чтв 15:30:20 1739928242
>>1739842
Потому что гладиолус.
Почему в Си нет проверки границ массивов, хотя эта операция ничего не стоит по рантайму и дает защиту от глупых ошибок? Потому что такой язык как Си дает тебе МИНИМАЛЬНУЮ абстракцию над голыми инструкциями, которые исполняет процессор. Читай, язык полностью полагается на программиста, ты сам выбираешь способ отстрелить себе ногу к хуям собачьим обрабатывать данные, выбирать типы переменных, работать с памятью и т.п. Минимум ограничений - кредо этих языков.
Тупо? Бесспорно. Но парадокс - на С/С++ (особеноо на С) держится весь мир компьютерных технологий, вся подноготная 98% технологий крутится на этих языках. Это как рак, который пустил метастазы до того, как его успели убить. Теперь хуй убьют, лол.
Аноним 02/07/20 Чтв 15:38:03 1739932243
>>1739928
А может это как скелет на котором всё держится?
Аноним 02/07/20 Чтв 15:41:06 1739933244
Аноним 02/07/20 Чтв 15:44:16 1739935245
>>1739928
>хотя эта операция ничего не стоит по рантайму
Почему не стоит? Одно сравнение же.
Аноним 02/07/20 Чтв 15:51:34 1739943246
>>1739935
Имелось в виду, что при современных мощностях сравнение - ничтожная операция по рантайм футпринту, отсутствие которого может привести к багу, который можно превратить в произвольное исполнение кода. Сам выбирай что важнее, учитывая современное железо.
Аноним 02/07/20 Чтв 15:53:49 1739947247
>>1739932
Ну так-то да. Си - это по сути кроссплатформенный ассемблер, а в языке ассемблера не место большому количеству абстракций (разве что над голыми битами, лол).
02/07/20 Чтв 16:11:35 1739958248
>>1739943
>при современных мощностях сравнение - ничтожная операция
И что с чем сравнивать, если у тебя функция принимает указатель неизвестно на который алимент массива?
Если передавать "дескрипторы" вместо указателей, как в Эльбрусах, то это не совсем ничтожные расходы.
Аноним 02/07/20 Чтв 16:21:18 1739967249
>>1739958
Современное железо это компенсирует с лихвой. Сишка нужна в эмбедщине, где жетские ограничения ресурсов - бесспорно. Но в мощнейших махинах это только открывает огромный attack surface.
Хотя альтернатив нет. Мы не живем в мире с розовыми пони, где высирают такое чудо техники, как Раст, и который быренько за 5 лет заменяет все наследние С/С++. Реальность куда более жестока и несправедлива.
С другой стороны, мб это и к лучшему, потому что UB - это весело, хоть и небезопасно. Сама возможность произвольно исполнить код на машине, а тем более удаленной, будоражит меня. И без С/С++ наследия это вряд ли было частью реальности.
Аноним 02/07/20 Чтв 16:22:58 1739969250
>>1739967
быстрофикс
исполнить произвольный код
Аноним 02/07/20 Чтв 16:30:59 1739975251
dashie.png (76Кб, 772x835)
772x835
>>1739967
>Современное железо это компенсирует с лихвой.
Железо ничего никогда не компенсирует, оно просто может выполнить кое-что параллельно за счет большей стоимости разработки и большей потребляемой мощности.
Аноним 02/07/20 Чтв 16:47:06 1739988252
>>1739975
И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов? Офк они не такие быстрые, как они, порой софт, написанный на них, ползет как дерьмо, но порой и нет. И ничего, юзают. В 80ых такое было нереально и засим вся прикладуха писалась на сях. Даже в 90ых годах это было нередкостью, хотя та же безопасная в плане памяти джава с рождения жестко хайпанула. А все из-за тогдашних мощностей. Сейчас это частично нивелируется современным железом, поэтому каждый второй софт на прикладном уровне высран на скриптопараше вроде жса (привет обрыганскому Электрону)
Аноним 02/07/20 Чтв 16:49:00 1739989253
>>1739988
быстрофикс
В STL границы буферов таки чекаются, если делать это через кошерный метод at(), а не через оператор [], что есть сахар над арифметикой указателей без каких-либо проверок.
Аноним 02/07/20 Чтв 16:57:17 1739997254
>>1739988
>И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов?
Они проверяют потому, что (1) в них нет указателей, (2) они и так требуют много накладных расходов (удалены от железа).
Аноним 02/07/20 Чтв 17:10:41 1740007255
>>1739997
Мораль басни была в другом - на прикладном уровне всем похуй на сверхпердольные оптимизации. Почему? Да блять потому, что железо 2к20 года != железо 1987 года. Вот и все. В системщине - да, бесспорно, но системщиной мир компьютерных технологий не ограничивается.
>в них нет указателей
В расте есть указатели, но там это проверяется, и при этом это системный ЯП. И только не заводи пластинку про unsafe, это смешно.
Аноним 02/07/20 Чтв 21:28:12 1740169256
>>1740007
> железо 2к20 года != железо 1987 года
Только ведь и задачи 2020 != задачи 1987.

> всем похуй на сверхпердольные оптимизации
Пиши правильно: мне похуй, потому что я пишу хелловорлды.
Аноним 02/07/20 Чтв 21:31:52 1740178257
Блять, вопрос не про границы массива вообще был. Как использование unsigned long long вместо uint64_t влияет на производительность? Ебом токнулись? Вопрос в том, почему этл мерзкое решение задизайнили по дефолту? Мне просто интересны причины. В чисто исторических целях, так сказать.
Аноним 02/07/20 Чтв 21:33:56 1740180258
>>1740178
>мерзкое решение
Какое именно?
Аноним 02/07/20 Чтв 21:35:23 1740184259
>>1740178
По факту ничем не отличается. По задумке — I'll зависит от платформы, uint64 всегда 64
Аноним 02/07/20 Чтв 21:35:27 1740185260
>>1740178
> Как использование unsigned long long вместо uint64_t влияет на производительность
Именно это - никак. А вот unsigned long может быть 32 или 64 бита, при этом твой код вполне переносим, потому что меньше 32 бит оно быть не может. А вот если напишешь uint64_t, и твой код на 32-битном проце будет тормозить из-за необходимости обеспечивать ненужную тебе по сути 64-битную арифметику путем ебли двух регистров одновременно. На самом деле в stdint есть int_fast типы и int_least типы, вот они норм, и их стоило запилить изначально. А фиксированные нужны, только если ты структуры упакованные в файл пишешь, или у тебя ограничения по памяти.
Аноним 02/07/20 Чтв 21:35:40 1740186261
Аноним 02/07/20 Чтв 21:37:43 1740188262
>>1740185
Ну вот и вопрос-то, почему так не сделали...
Аноним 02/07/20 Чтв 21:39:12 1740191263
>>1740180
Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Аноним 02/07/20 Чтв 21:44:55 1740204264
>>1740188
Потому что на тот момент, когда это делали, вариантов было меньше. Это сейчас у нас интов дохуя развелось больше, чем в stdint есть, а раньше или long, или short были алиасом для int.
Аноним 02/07/20 Чтв 21:45:48 1740205265
>>1740191
>Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Ну ты же знаешь, что на VAX int = long = 32 бита, а потом придумали long long, чтобы получить 64 бита без конфликта с существующими идентификаторами.
Аноним 03/07/20 Птн 13:00:53 1740544266
>>1711268 (OP)
С какими значениями -O, -march и/или -mtune нужно компилировать программу, чтобы бинарники работали на всех среднестатестических убунтах?
Аноним 03/07/20 Птн 13:43:39 1740584267
>>1740544
march=pentium4, любой -O, -mtune можно задрать куда-нибудь повыше.
Аноним 03/07/20 Птн 15:31:56 1740740268
>>1740584
А если нужно только для x86_64?
Аноним 03/07/20 Птн 16:28:54 1740804269
Аноним 03/07/20 Птн 19:48:44 1741052270
>>1740007
Я не понял, зачем вам границы массива? Если надо размер, чтобы не пройти итератором за пределы массива, то для вас есть sizeof, если не надо, то с чего бы он был по дефолту? Как программа вообще узнает вышла она за границы массива или не вышла, если она просто читает из памяти подряд? Это типа надо границы массива помечать как-то в памяти что ли? Особой комбинацией нулей и едениц? Как вы вообще себе представляете границы массива в памяти?
Аноним 03/07/20 Птн 19:55:11 1741056271
>>1741052
> Я не понял, зачем вам границы массива?
На самом деле bounds checking для отладки много где есть. Если писать говнокод или просто на отъебись - очень помогает.

> Как вы вообще себе представляете границы массива в памяти?
fat pointers или таблицы, как для виртуальной памяти в процессорах.
Аноним 03/07/20 Птн 19:57:29 1741057272
>>1741052
Да, проверка на выход за границу по длине.
> если не надо, то с чего бы он был по дефолту
Наверное потому работа с памятью одна из самых частых ошибок?
Аноним 03/07/20 Птн 20:07:28 1741064273
>>1741057
>Наверное потому работа с памятью одна из самых частых ошибок?
Си не прощает ошибок в любом случае. Тем более когда ты работаешь напрямую с микроконтроллером.
Аноним 03/07/20 Птн 20:10:35 1741067274
>>1741064
Да. Поэтому раст и хайпят, потому что он такие ошибки позволяет исключать
Аноним 03/07/20 Птн 20:15:17 1741071275
>>1741067
Никто его не хайпет кроме отдельных сектантов. Здесь вот один растошизик срет в С и С++ тредах.
Аноним 03/07/20 Птн 20:29:46 1741083276
bounds.png (16Кб, 608x499)
608x499
>>1741067
> потому что он такие ошибки позволяет исключать
Так и Си позволяет. Но Си еще много чего позволяет там, где в расте нужно писать заклинание на страницу, чтобы его величество компилятор дозволил.
Аноним 03/07/20 Птн 20:37:53 1741088277
>>1741083
Даладна.
А ещё можно просто код без ошибок писать. Вопрос только в том насколько распространено это юзается.
Аноним 03/07/20 Птн 20:57:36 1741105278
>>1741088
Да очень многие используют и статический анализ, и санитайзеры, и анальные стандарты типа мисры. Ты по опенсорсу-то не суди.
Аноним 03/07/20 Птн 20:59:33 1741111279
>>1741105
Почитай что пишут майки о расте.
Аноним 03/07/20 Птн 21:04:08 1741113280
>>1741111
Я читал, что пишут майки о сервелате, этого достаточно.
Аноним 03/07/20 Птн 21:44:59 1741160281
error.jpg (351Кб, 1724x958)
1724x958
Аноним 03/07/20 Птн 21:56:02 1741168282
>>1741160
Кресты и сишку поменять местами и правдивый мемчик
Аноним 03/07/20 Птн 22:44:27 1741209283
>>1741168
ну, сишка действительно четче по хардкору поясняет за хромосомное неумение, а не разматывает темплейты на двадцать экранов, но почему хардварный фейл к крестам ближе?
Аноним 04/07/20 Суб 01:55:01 1741274284
>>1741052
У любого буфера есть размер при его аллокации. При любом доступе к памяти а-ля буффер + оффсет можно проверять туда ли пишут/оттуда ли читают или нет. Дешевая же операция, камон.
>>1741071
Я не растошизик, но мелкософт очень хвалят раст и хотят на него переписывать винду, например. Максимум за 10 лет управятся. А вот Торвальдс ретроград, Линукс доталого будет на сишечке.
Но зато будет забавно, без дыр в памяти мир сер и скучен, есть в этом некая романтика, которую рано или поздно убьет технологический прогресс (надеюсь, когда я уже буду пенсионером)
Аноним 04/07/20 Суб 02:34:01 1741279285
>>1741274
Ааа, да ты тот второй растошизик который форсит Rust у Microsoft. Ну так вот любые пруфы то мб будут? А я могу тебе прям сейчас ответить: раста не будет. Почему? Потому что им проще расширить компилятор С++ для фикса общих ошибок и спроектировать новый безопасный апи, чем они собственно и занимаются с огромным успехом. Кроме того, ты хоть осознаешь все масштабы операционной системы? А я тебе скажу, 6млн. исходных файлов. Можешь представить сколько там LOC? Я вот не могу.
Аноним 04/07/20 Суб 03:11:35 1741286286
а может такое быть, чтобы strerror(errno) выдавал неправильный указатель? я просто смотрю в gdb, и там какая-то хуйня.

надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
Аноним 04/07/20 Суб 03:13:46 1741287287
>>1741286
а не, похоже понял. автотулс не рекомпельнул с новыми флагами
Аноним 04/07/20 Суб 06:21:38 1741299288
>>1741274
>При любом доступе к памяти а-ля буффер + оффсет можно проверять
Нет, нельзя, производительности придет конец.
Аноним 04/07/20 Суб 06:39:11 1741300289
>>1741274
>аллокации
Какая еще аллокация, когда с микроконтроллером работаешь?
Аноним 04/07/20 Суб 08:53:36 1741316290
>>1741287
>автотулс не рекомпельнул
>не рекомпельнул
>авто
Аноним 04/07/20 Суб 11:38:38 1741406291
>>1715435
Смотри: есть целые числа (инты, например) и дробные (float).

Целые числа всегда делятся нацело, т.е. 100/6=16, а твое 5/1000=0. Дробные числа делятся примерно так же, как в школе, т.е. 100.0f/6=16.666..., ну и для 5f/1000 аналогично.

У тебя в формуле правый множитель будет равен -1 (сам сообразишь почему).

Как избавиться? Внутри формулы юзай флоаты или даблы (в зависимости от требуемой точности), а потом кастуй к своему инту.
Аноним 04/07/20 Суб 12:27:22 1741436292
Как белые люди пишут кроссплатформенную дин.библиотеку?

Пускай есть некоторый сишный код, который нужно скомпилить и тягать как .so в никсах или как .dll в винде. С никсами все понятно - берешь gcc и компилишь. Слышал по mingw и cygwin, но это костыль костыля, как мне кажется. Как компилять либу на винде?
Аноним 04/07/20 Суб 13:14:21 1741490293
>>1741436
Mingw вполне себе юзабелен, из CI собирать всю хуйню под wine - одно удовольствие.
Аноним 04/07/20 Суб 13:33:22 1741501294
>>1741274
Когда все проверяется в черном ящике каждый раз без исключения - эта а приори не оптимизированный код. segment-naebnulsa-safe контейнер - не экстрасенс какой-то, чтоб проанализировать вызывающий алгоритм на инвариативность условия, что индекс меньше размера, стало быть говно.
Аноним 04/07/20 Суб 13:34:40 1741502295
>>1741274
Да и хули толку, что рантайм ошибки не будет, если алгоритм все равно по факту обосрался с индексацией и задачу не выполнил? Все равно руками проверять, раз на то пошло.
Аноним 04/07/20 Суб 13:38:30 1741509296
>>1741274
Есть тяжелые структуры данных, вся жизнь которых сводится к хождению по индексам на индексы через индексы, и если всрать в реализацию безопасные массивы, время основных операций в такой системе вырастет не на какую-то там
>дешевая же операция, камон
а пропорционально, то есть в разы
Аноним 04/07/20 Суб 14:29:02 1741626297
21777170-6AE7-4[...].jpeg (374Кб, 750x792)
750x792
Привет. Чарльз Петцольд в своей книге утверждает, что количество адресуемой памяти влияет на скорость процессора аргументируя тем что на пике. Читаю и не пойму что он имел в виду. Может кто шарит? Тред ассемблерщиков пустует, там решил не спрашивать.
Аноним 04/07/20 Суб 14:56:38 1741656298
>>1741626
Он там сравнивает 16 и 32-бит режимы?
Дай больше контекста.
Аноним 04/07/20 Суб 15:06:02 1741674299
Аноним 04/07/20 Суб 15:52:02 1741726300
>>1741300
Я не имел в виду только аллокацию памяти на куче, в мире микроконтроллеров это, в большинстве своем, непозволительная роскошь, ибо ресурсов маловато даже для обрыганского аллокатора памяти и менеджера кучи.

Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
Произошла аллокация статического 16-ти байтового буфера на стэке.

>>Нет, нельзя, производительности придет конец.
Как тогда раст позиционируется как системный яп и проникает потихоньку в эмбеддед? У него ведь не только тяжелый статический анализатор кода, а еще и рантайм проверки (в случае с МК могут быть нерелевантны, ибо там, как правило, не имеют дело с кучей)

>>Ну так вот любые пруфы то мб будут?
https://www.youtube.com/watch?v=NQBVUjdkLAA
Аноним 04/07/20 Суб 15:56:51 1741731301
>>1741726
>Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
ав-та-ма-ти-чис-ка-я
повтори
Аноним 04/07/20 Суб 16:05:16 1741739302
>>1741626
Скорее всего у него там обосновано почему.

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

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

В общем там недостаточно просто уметь адресовать.
Аноним 04/07/20 Суб 18:02:35 1741928303
>>1741739
> но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами
Совершенно не по этой причине, не из-за быстродействия. Просто чем больше бит, тем больше площадь адресной шины, а место на кристалле дорогое. К тому же разводить широкую шину сложнее. Поэтому адрес 64 бита, а реально бит в адресной шине меньше.
Аноним 04/07/20 Суб 19:34:22 1741993304
>>1741739
>Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
>

Бля, чем ей "сложнее управлять"? у тебя кэшлайны такие же, развелось дебилов. менеджеры памяти тоже нормальнве люди пишут, и количество имеющейся памяти не влияет на скорость элементарных операций.
Аноним 04/07/20 Суб 20:30:45 1742046305
Есть инфа, зачем в сетевой библиотеке функции, переводящие endianness, представлены парами htonl/ntohl и htons/ntohs? Разве это не операция с четным периодом, как xor?
Аноним 04/07/20 Суб 20:38:10 1742049306
Аноны, а у вас свои набитые опытом либы имеются? Или в случае Си это бессмысленно?
Аноним 04/07/20 Суб 20:41:38 1742051307
Аноним 04/07/20 Суб 20:53:24 1742056308
Аноним 04/07/20 Суб 22:52:14 1742120309
>общаться в си треде где 90% постеров это ебанаты студентишки и бывшие трактористы из юнитфактори не написавшие в своей жизни ни строчки кода отличного от linkedlisttutorial.c по туториалу, для которых авторитет это не имя и опыт за ним, а кто за скока вкатился
кринж
Аноним 04/07/20 Суб 23:23:52 1742135310
>>1711268 (OP)
Хочу вкатиться в Natural Language Processing, Data Visualisation и всякий статический анализ. Для себя, для будущего диплома. Знаю, придется переписывать половину pandas на Си и творить ебанутые вещи.

Хочу выучить C11. Есть время для этого хобби, два года, есть мрачная решимость не подходить ко гвидопыху даже с десятифутовым копьем.

Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.

Я, конечно, добаеб и земля мне пухом, но если анонс подскажет полезных библиотек/книжек, буду рад.
Аноним 05/07/20 Вск 00:47:41 1742161311
>>1742135
Ну, тащемта, это даже не ты ебанат, а эта тема вообще не имеет никакого развития, даже вкат в NLP И так далее сомнителен. Вкат в визулизацию — это вообще кекус, там задачи — написать скрипт чтобы разобрать массив данных, причём в большинстве случаев это разовая акция на порисерчить.

>C11
Чел, во-первых это не плюсы, и 11 от 99 отличаются на 1,5 фичи в языке и 3 новых хидера в стдлибе, а во вторых С11 не то, чтобы что то нужное и везде используется в лучшем случае 99.

> Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Тащемта даже хачкель для анализа данных подходит лучше, на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область (которая вообще не то, чтобы сидьно про программирование, оно там вообще вторично).

А про ненависть к ооп — а что для тебя вообще ооп?
Аноним 05/07/20 Вск 02:10:01 1742200312
Приветствую братьев-сишников, желаю приятного кодинга.
Аноним 05/07/20 Вск 10:54:41 1742303313
image.png (55Кб, 1024x768)
1024x768
>>1742200
вам також смачного
Аноним 05/07/20 Вск 11:10:06 1742314314
дiдько, таки обiсрався на скрiншотi
Аноним 05/07/20 Вск 11:14:44 1742322315
>>1742303
> нет подсветки
> хаки
> константы Ls Cd не капсом
> не проверяется возвращаемое значение write
Аноним 05/07/20 Вск 11:27:57 1742332316
>>1742322
Гораздо хуже "while (ent = readdir"
вместо "while ((ent = readdir"
Анончегу пох на предупреждения или он их отключил.
Аноним 05/07/20 Вск 11:36:55 1742342317
image.png (71Кб, 1280x960)
1280x960
>>1742322
. спецом, шоб писать охуительно качественный человекочитаемый код хоть под распечатку на чб принтере
. на то и есть домашние проекты, чтоб доверять самому себе и не обмазываться бест практиками
. в чем космический смысл писать константы КАПСОМ, если можно просто с Капса?
. write писал еще когда nlSendStr не было, ща оберну
Аноним 05/07/20 Вск 13:50:57 1742457318
>>1742161

Спасибо за мнение.

>на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область

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

>А про ненависть к ооп — а что для тебя вообще ооп?
ООП для меня просто школьная травма.

Бесконечные классы за гранью нормального, всякие get/set, и -1 балл на контрольной за printf вместо cout с охуительным объяснением "ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно". Пять лет прошло, а я злой как собака как вспомню.


Аноним 05/07/20 Вск 16:36:34 1742595319
>>1742457
>, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Это и есть та самая меморимодел?
Аноним 05/07/20 Вск 16:58:33 1742634320
>>1742457
>ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно
Что за шиза?
Аноним 05/07/20 Вск 18:00:13 1742708321
>>1742457
>Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Ты же понимаешь, что это _абсолютно_ write-only подход, который практически невозможно поддерживать и развивать? Ты же сам 2 месяца не разберёшься в коде без полного погружения в это. Это даже хуже типичного говнокода от датасатанистов.

>всякие get/set
А при чём тут ООП-то? Когда тебе понадобится присобачить минимальную логику, начиная от отладочной информации или просто ассертов просто ради приблежиния к уровню self documenting code, и заканчивая серьёзными изменениями (например, строка превратилась в бинарный формат, который надо печатать форматированно), то ты и на ассемблере всё на гет/сет все публичные интерфейсы перепишешь, лол.

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

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

inb4: Ух, чую как злая шкила меня сейчас говном закидает, лол.
Аноним 05/07/20 Вск 18:00:35 1742709322
Аноним 05/07/20 Вск 18:03:12 1742711323
>>1742708
Я не он, но ООП реально говно.
Аноним 05/07/20 Вск 18:15:31 1742723324
>>1742708
> Со стороны нормального программного дизайна
Со стороны программного дизайна потоки в C++ - это полный пиздец, ничего хуже еще не придумывали.
Аноним 05/07/20 Вск 18:20:15 1742728325
cover122356.jpg (142Кб, 660x400)
660x400
>>1742711
А что такое ООП, чел? В С вот реализация инкапсулируется от интерфейса с помощью хидеров, инкапсуляция — 1 из 3 принципов ООП, С — ООП язык на 1/3?

>>1742723
Я же и не говорил обратного, но это хоть какая-то инкапсуляция. Ебашь на здоровье массивы байтов напрямую, кто же запрещает-то. Просто через пару лет догонишь что это хуйня а не подход.
Аноним 05/07/20 Вск 18:24:55 1742732326
>>1742728
> С — ООП язык на 1/3?
ООП-язык - это язык с сахарком. В си сахарка нет. Вот в ObjC например есть.
Аноним 05/07/20 Вск 18:41:10 1742743327
>>1742732
Ну смотри, есть C++ а есть Obj-C. И там и там есть "сахарок", только реализует он всё примерно диаметрально противоположно. Кто из них ООП?

ООП — это, блядь, концепция. Ясен хуй, что никому не нравятся всякие там паттерны итд, но паттерны — это костыли для конкретного языка, а не ООП. ООП — это 3 ебучих принципа, ничего лучше которых никто не придумал (разве что про наследование можно поспорить).
Аноним 05/07/20 Вск 18:44:38 1742746328
>>1742743
> ООП — это 3 ебучих принципа
Нет. Только один: объекты обмениваются сообщениями. И он нихуя не применим на практике без проблем с производительностью. Поэтому ООП-ом каждый называет какие-то свои фантазии. Ну или то, что в вузике вдолбили.
Аноним 05/07/20 Вск 18:51:52 1742757329
>>1742708
>Со стороны нормального программного дизайна это как раз таки нормальное замечание.
Со стороны нормального дизайна использовать сиаут для форматирования строки это пиздец.
Аноним 05/07/20 Вск 18:52:42 1742759330
159369814218465[...].jpg (160Кб, 640x960)
640x960
>>1742728
>А что такое ООП, чел
Это когда оперируешь объектами классов их иерархией. И все это говно сильно зависит от контекста, плюс поддерживание инкапсуляции, один васян решил скрыть доступ, а второй городит огород чтобы нормально считать значение переменной или избавится от оверхеда проверки значения. Короче оч на любителя, как разведенки с прицепами. Но Qt для мордочек юзаю, да. Философия Перл/С здесь ближе, написал в документашке не лезь и все этого достаточно.
Аноним 05/07/20 Вск 18:58:31 1742766331
>>1742746
>Нет. Только один: объекты обмениваются сообщениями.
В понимании примерно всего коммьюнити — 3, и почти весь софт на планете пишется с их применением, поэтому Алан Кей идёт нахуй.

Даже в Objective-C завезли __attribute__((objc_direct)) что как бы намекает, что этот подход мертв.

>>1742757
Читать умеешь?
>>1742728
>Я же и не говорил обратного

>>1742759
А аналоги-то какие? Как в новомодных фп архитектурах просто использовать композицию вместо наследования и копипастить код из редюсера в редюсер стейта и создавать заново весь стейт (а лучше и контекст) при каджом изменении а потом гнать по скомпозированному дереву функций?
Аноним 05/07/20 Вск 19:10:07 1742778332
>>1742766
>А аналоги-то какие?
Слать на хуй ООП парадигму. Ну может комуто нравится когда в одной либе петух это класс птиц, а в другой динозавров.
05/07/20 Вск 19:13:39 1742786333
>>1742732
>В си сахарка нет.
*(a+3)
a[3]
Аноним 05/07/20 Вск 19:13:54 1742787334
Мне в ООП нравится только инкапсуляция. Сам я пишу драйвера и системы управления железками разными, и вот именно это я всегда использую в си.
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.

Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
Аноним 05/07/20 Вск 19:19:02 1742795335
>>1742787
>Мне в ООП нравится только инкапсуляция
Чего именно?
Аноним 05/07/20 Вск 19:19:25 1742797336
>>1742634
Ну круто же, строка сама знает, как себя форматировать.
Аноним 05/07/20 Вск 19:22:24 1742801337
159369813219586[...].jpg (58Кб, 527x791)
527x791
>>1742797
Ага, если учитывать все кодировки и системы письма, то твой класс улетит в ебеня. Но обычно получается ни то ни се и все работают с байтовым буфером по своим потребностям.
Аноним 05/07/20 Вск 19:23:54 1742803338
>>1742795
Инициализации железа. Вся работа с ногами и регистрами отдельно, логика системы отдельно.
Аноним 05/07/20 Вск 19:25:59 1742804339
>>1742797
Кстати, вот иллюстрация убогости С: надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s, программа упаде.
Аноним 05/07/20 Вск 19:28:34 1742805340
>>1742804
Просто делаешь строки sprintfом
Аноним 05/07/20 Вск 19:30:21 1742807341
Когда познакомился с плисами, а также Верилогом и прочими hdl, понял, что ООП это всего-навсего железки в коде.
Аноним 05/07/20 Вск 20:17:59 1742848342
>>1742804
> надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s
То компилятор скажет, что ты ошибся. Да, это работает только для printf-like функций, а если у тебя свой собственный формат спецификаторов или вообще его нет, тогда тебе никто не поможет.
Аноним 06/07/20 Пнд 04:36:18 1743031343
Как заставить gcc проверять количество и тип аргументов вызываемой функции?
Т.е. я объявляю прототип типа
void func(int a, int b);
И если в коде по ошибке вызываю так
funс(1, 2 , 3);
то компиль молчит как партизан
"-Wall" не помогает
Аноним 06/07/20 Пнд 06:43:30 1743036344
.png (43Кб, 980x650)
980x650
Аноним 06/07/20 Пнд 11:07:44 1743063345
>>1743031
Компилятор не увидел прототип?
Аноним 06/07/20 Пнд 11:28:05 1743072346
>>1713183
А если выводить через puts?
Аноним 06/07/20 Пнд 14:40:35 1743166347
15850576468980.jpg (41Кб, 528x498)
528x498
Какое же сложное это ваше программирование. Вот хочу смочь в С - а где мне компилировать? Ставить себе линух или на виртуальную машину и использовать gnu? Или тупо в вижуал студио на виндоусе для начала сойдет? Для чего нужно ставить clang и что это вообще такое?
Аноним 06/07/20 Пнд 14:47:37 1743175348
image.png (123Кб, 727x691)
727x691
>>1743166
Вижуал студио сказал что не хочет работать без обновления,
а чтобы обновиться нужно залогиниться в учетку майкрософт, от которой я забыл пароль. Сбросил пароль - ввожу и тут он мне говорит что это старый пароль, хотя он не подходил. Видимо я уже менял пароль, и это старый старый пароль и он почему-то больше не подходит им. Вот нахуя программисты майкрософт создают такую еблю для пользователя?
Аноним 06/07/20 Пнд 16:05:22 1743213349
>>1743166
что тебе делать, тебе тут говорить не должны; линукс - рай для творческого программирования

си компилирует gcc, который всегда во всех дистрах в репах; редачить можно в обвязке, а многие используют обычные редакторы с подсветкой
Аноним 06/07/20 Пнд 16:45:42 1743235350
>>1743175
>Вот нахуя программисты майкрософт создают такую еблю для пользователя?

> Почему буквальный EvilCorp мне плохое зло зделол?
Аноним 06/07/20 Пнд 16:58:14 1743242351
>>1743166
>Или тупо в вижуал студио на виндоусе для начала сойдет?
На форточках я бы посоветовал использовать Code::Blocks + MinGW. Со студией хоть и проще начать работать, но в сравнении с CB её функционал для новичка является overkill, поэтому освоить её сложнее.

А вообще, учить человека программированию начиная с C - издевательство, так можно его превратить в Си-дебила. Типичный Си-дебил ничего, кроме императивных языков с Си-подобным синтаксисом освоить практически неспособен.
Аноним 06/07/20 Пнд 17:02:58 1743249352
>>1743242
> Code::Blocks + MinGW
двачирую, и весит мало и бесплатная.
>>1743242
а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
Аноним 06/07/20 Пнд 17:05:52 1743252353
>>1743175
лол. в рот ебал эти эко-коко-системы.
есть ли какие-то форумы/движения/репозитории, которые продвигают идею что комп должен быть ВСЕЯДНЫМ ?
(без крайностей)
Аноним 06/07/20 Пнд 17:06:14 1743254354
>>1743036
>>1743063
Забыл добавить, что func объявлена в func.h файле и реализована в func.c файле. При этом главный файл не содержит
include "func.h", т.е. в теории функции вообще не должно быть видно.
Тем не менее компиль компилит, а линкер линкует.
Аноним 06/07/20 Пнд 17:22:27 1743264355
>>1743166
>Ставить себе линух?
Попробуй. Еще захочешь, базарю. На самом деле не нужно, используй удобную для себя систему.

>Или тупо в вижуал студио на виндоусе для начала сойдет?
Сойдет и для продолжения. Хотя лично я предпочитаю Clion, но на винде он обычно поверх студии ставится, лол. Не спрашивай.

>Для чего нужно ставить clang?
С - компилируемый язык, так что для превращения твоих буквочек в программу нужен компилятор.
Дефолтный выбор для винды - msvc(visual studio сама его поставит), для линуксов\макоси - gcc.

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

>что это вообще такое?
Не стоит вскрывать эту тему, но вы все равно будете спрашивать..
Clang - часть проекта llvm.org
Если коротко, то clang отвечает за фронтенд компилятора, за счет опен-соусности и хорошего api эту хуеверть используют в разных IDE для подсветочки кода, функций рефакторинга, пиздатых сообщений об ошибках и прочих кодоанализов. В связке с llvm превращается в черную магию, способную работать с кодом на любом этапе компиляции, сожрать твой разум, сделать новый язык программирования или даже перевести код с одного языка на другой, попутно забрав твою душу.
Ты был предубежден.


мимо-крестодебич, зашел в тред случайно.
Аноним 06/07/20 Пнд 17:25:53 1743267356
>>1743249
>а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
Это субъективно, но не стану спорить.

Как минимум какой-нибудь Scheme или Standard ML очень в тему, если приспичило углубиться в Computer Science. У редкого адепта K&R не выносят мозг рекурсивные алгоритмы, обычно используемые в ФП (бинарные деревья из книги они осилили с горем пополам).
Аноним 06/07/20 Пнд 17:26:53 1743268357
>>1743242
Да я не совсем нулевой, в университете вроде бы сдал курс программирования, и даже численные методы на паскале на самом деле не помню чё там было, вроде C++, было похуй сдал и забыл так что сейчас думаю научиться хоть чему-то полезному, не важно какой синтаксис учить сначала мне кажется. Я не из тех кабанчиков которые через 1 месяц хотят устраиваться погромистами.

>>1743264
Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Аноним 06/07/20 Пнд 17:47:07 1743283358
>>1743242
>На форточках я бы посоветовал использовать Code::Blocks + MinGW
>MinGW
Может лучше wsl или уже линукс?

>>1743268
>Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду?
Тебе как обычному посону достаточно нажать кнопочку compile в ide или как ты там предпочитаешь.
Всю еблю и танцы с разными железками, преобразованием говнокода чтоб анубыстроблядь работало и прочие заботы берет на себя компилятор(тот же clang).
В 99% случаев думать о том что там под капотом происходит вообще не надо.
Аноним 06/07/20 Пнд 18:57:26 1743334359
>>1743283
>что там под капотом происходит вообще не надо.
Уходите в питухон/мл трхед
Аноним 06/07/20 Пнд 19:15:34 1743349360
>>1743268
>жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Можешь попробовать Code block портабельную сборку, на сайте у какогото инфоцыгана что ли видел, тредов 20 назад про неё спрашивал обосрали конечно но работает только вроде пути к компиляторам если не в С копируешь вручную надо поменять.
Аноним 06/07/20 Пнд 20:09:38 1743391361
>>1743242
Откуда этот миф про первый язык?
Если айсикью недостает какой язык не дай человек на нём и застагнирует.
Аноним 06/07/20 Пнд 21:02:24 1743416362
>>1743242
Как раз си, и Книга Кернигана и Ритчи идеальны для вкатывания в проргаммирование вообще. Там же все с самых азов. Еще лучше если купить отладочную плату при этом.
Аноним 06/07/20 Пнд 22:05:09 1743445363
>>1743349
Блять, легче тогда devcpp поставить и не ебаться, для новичка топ - нет подсветки, простой в установке и идёт в комплекте с компилятором
Аноним 06/07/20 Пнд 22:25:44 1743451364
>>1743391
В си есть указатели с ними проще списки понять. Какая то абстракция есть, другие всё стремятся "очеловечить" что ли Си как математика.
Аноним 06/07/20 Пнд 22:55:15 1743465365
>>1743416
Как один из концов. Пацанское рвение прошариться в ламповом низкоуровневом коддинге утроит общую продуктивность занятий, даже если "КПД" не очень. А так, SICP правильнее.
Аноним 07/07/20 Втр 07:59:34 1743578366
>>1743445
ЛЕГЧЕ было бы просто новый аккаунт в макйрософте зарегистрировать и какать в визуальную студию, но нужно же блджад в пр в мертвый тред насрать
Аноним 07/07/20 Втр 08:16:17 1743580367
>>1743578
>аккаунт в макйрософте зарегистрировать
Зашквар же.
Аноним 07/07/20 Втр 08:19:53 1743581368
>>1743580
так двач тоже зашквар, значит для него это не проблема
Аноним 07/07/20 Втр 15:33:10 1743979369
>>1711268 (OP)
Расположение битовых полей в памяти.


Имеется некий пакет передачи, который нужно заполнить в правильной последовательности, например:
5 битов - адрес
3 бита - номер функции
10 битов - данные
7 битов - контрольная сумма
Ну и решил для удобства всё это сделать структурой с битовыми полями. На байтах всё выходило как надо(потому что биты в байтах, переменных и элементы в массиве всегда размещаются одним и тем же образом). Но когда я стал тоже делать битовыми полями, всё вышло через жопу. Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Аноним 07/07/20 Втр 15:52:20 1744001370
>>1743979
пили свой препроцессор, который использование таких структур переведет в соответствующие голые операции
Аноним 07/07/20 Втр 15:58:04 1744006371
>>1743979
> Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Какой опытный путь, гуглить ты не пробовал?

В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
07/07/20 Втр 16:17:57 1744017372
>>1743979
> Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Да. Ни обычные структуры, ни структуры с битфилдами нельзя отправлять через сеть в сыром виде, их можно только писать в файл, если этот файл будет прочитан той же программой на той же платформе. Для обмена данными надо писать (де)сериализатор, который возьмет байтики (или битики) из принятого буфера, распарсит их и запишет в поля структуры: myshit.smth = read_uint(&src); myshit.some_bitfield = bitstream_read(&bs, 5), ну типа того.

Да, многие пренебрегают этим, надеясь на то, что big endian их не коснется, и что исключения у флоатов выключены, и что что выраванивания у членов структуры и буфера с полученными данными правильные, и что -fms-bitfields их спасет. Но лучше не стоит.
Аноним 07/07/20 Втр 17:27:34 1744087373
>>1743979
ПРОСТО ИСПОЛЬЗУЙ ЛОГИЧСКИЕ ОПЕРАЦИИ
Аноним 07/07/20 Втр 18:23:58 1744124374
>>1743979
Битовые поля хуёво стандартизированы. Поэтому лучше воздержаться от их использования.
Аноним 07/07/20 Втр 19:19:14 1744172375
>>1744124
>Битовые поля хуёво стандартизированы.
Они стандартизированы, просто каждый компилятор располагает их по разному в памяти.
>Поэтому лучше воздержаться от их использования.
Не все так однозначно.
Если ты работаешь с битовыми полями только в программе, то их можно использовать, они намного удобнее.
А если собираешься куда-то пересылать, то лучше тогда биты распределять в пакете передачи вручную с помощью битовых операций.
Тот же MISRA C не запрещает битовые поля, хотя как бы этот стандарт во всем придерживается, чтобы код не зависил от компилятора.
Аноним 07/07/20 Втр 19:24:28 1744180376
>>1744006
>Какой опытный путь
Изменял биты в полученном пакете передачи, а потом на бумажке отмечал, где находится то или иное битовое поле.
>, гуглить ты не пробовал?
Потом, когда увидел такое говно, загуглил, оказалось, что расположение битовых полей в памяти отличается от компилятора к компилятору.
>В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
Да это я знаю, порядок байтов в массивах и структурах всегда одинаков - элементы в начале структуры/массива имеют младшие адреса. А биты в байте располагаются от старшего к младшему.
Речь про битовые поля, а они могут быть не кратны байту, и как расположит компилятор их в структуре это всегда загадка.
Аноним 07/07/20 Втр 20:36:59 1744292377
image.png (587Кб, 1024x576)
1024x576
Аноним 07/07/20 Втр 22:38:04 1744424378
>>1711268 (OP)
Блин, а это говно:
>- Brian Kernighan, Dennis Ritchie "The C Programming Language":
разве обязательно читать?
Просто я прочёл справочник Шильдта(и иногда заглядываю в его при работе) и мне этого с головой хватает для проганья, не вижу смысла что-то ещё читать дополнительно.
Аноним 07/07/20 Втр 22:39:46 1744425379
>>1711627
>> define
>Это единственный в Си нормальный способ объявления констант
А теперь объясни, чем константы отличаются от дефайнов...
Аноним 07/07/20 Втр 23:47:12 1744470380
>>1744425
> чем константы отличаются от дефайнов
Пиши в файле:
const int nelem = 42;
int array[nelem];
И компилируй. Алсо, const не гарантирует, что переменная nelem не будет читаться там, где ее можно было оптимизировать до immediate-операнда в инструкции.
Аноним 08/07/20 Срд 04:02:10 1744558381
>>1744425
Тем, что дефайн - это find & replace ДО начала компиляции. При абузе дефайнов ты охуеешь дебажить это говно, так как переменной как таковой нет, до процесса компиляции просто идет замена x на y, если макрос: #define x y

А константа - переменная, под которую выделяется место в read-only сегменте памяти. И при дебаге, в отличие от дефайнов, у тебя будет не много веселых магических чисел, а переменная с конкретным адресом в памяти.
Аноним 08/07/20 Срд 04:05:39 1744559382
>>1744470
Не хочешь оптимизаций от компилятора для конкретной переменной - юзай ключевое слово volatile в таких случаях.
Аноним 11/07/20 Суб 10:10:04 1747770383
Аноним 11/07/20 Суб 10:16:11 1747772384
>>1747770
Загнал палучается в студию и понял что проблема в двойных кавычках хех мдаа понимаю.
Настройки X
Ответить в тред X
15000 [S]
Макс объем: 40Mб, макс кол-во файлов: 4
Кликни/брось файл/ctrl-v
Стикеры X
Избранное / Топ тредов