Я один не использую все эти typedef, #define и прочие операторы которые просто присваивают псевдонимы типам и константам?
Не думаю что эти функции особо нужны в ЯП. Поясните, пожалуйста, прав ли я или нет. Если нет то какое практическое преминение может быть этим typedef и define
>typedef и define
ТРУ ФАЛСЕ БАЙТ
Чтобы не размазывать в пределах модуля ololoverysometype тысячу раз, а писать какое-нибудь короткое ovstype
typedef struct tagMyStruct
{
} MyStruct;
макросы, макросики
> Если нет то какое практическое преминение может быть этим 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
};
День добрый, подскажите скрин изкниги П. Дейтел, Х.Дейтел - С для программистов с введением в С11 - 2016 , первый выделенный printf работет нормально, второй вместо подчеркиваний цифры какие то печатал. пока я d на s не поменял и звёздочку не убрал. puts просто ошибку выдавало в С-free 5.0. Причем код в книжке и в исходниках одинаковый. Это опечатки или проблема в С-free + mingw5&
Это опечатки. Везде должно быть printf, c %s ты все правильно сделал, хотя смысл этих конструкций от меня ускользает, делать printf("%s", "строка") совершенно незачем. Это вся книга такая?
> делать printf("%s", "строка") совершенно незачем.
Это защищает тебя от format string атаки
Да ты что! Это с двумя константными строками?
С кем воюешь, шизоид? Погбеб выкопал и сухпаёк уже собрал, на случай ядерной атаки?
Странно что эти опечатки в исходниках повторяются которые с книгой шли, книгу тут анон выкладывал в ввиде картинки.
Если бы было printf(user_data), тогда да, за это бить надо, пока не дойдет. Но в книге совершенно другой случай.
Здравствуй, анон. Мучаюсь с макросами и _Generic в c11 в попытках написать небольшую библиотеку с типа-шаблонами и типа-перегрузкой функций.
Очень интересны следующие вопросы:
1) Есть ли способ по заданному целочисленному типу T получить соответствующий беззнаковый тип UT (например, по int32_t получить uint32_t, а по uint32_t - тоже uint32_t)?
Иначе говоря, пытаюсь запилить что-то в духе
__UNSIGNED(T) var;
которое после обработки будет
UT var;
2) Есть ли хотя бы просто способ проверить, что некий T является беззнаковым?
3) В дополнение ко (2): если известны все беззнаковые типы, которые потенциально могут использоваться, можно ли решить данный вопрос без нагромождений #if в каждом месте, где требуется определить знаковость?
Очень интересны следующие вопросы:
1) Есть ли способ по заданному целочисленному типу T получить соответствующий беззнаковый тип UT (например, по int32_t получить uint32_t, а по uint32_t - тоже uint32_t)?
Иначе говоря, пытаюсь запилить что-то в духе
__UNSIGNED(T) var;
которое после обработки будет
UT var;
2) Есть ли хотя бы просто способ проверить, что некий T является беззнаковым?
3) В дополнение ко (2): если известны все беззнаковые типы, которые потенциально могут использоваться, можно ли решить данный вопрос без нагромождений #if в каждом месте, где требуется определить знаковость?
Ладно, для третьего вопроса пока есть такой говнокод:
#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)
Очень надеюсь, что есть что-то лучше.
Правильно делают. Нормальный человек понимает что пишет, опечатки наоборот помогают учить язык. А дауны макаки бездумно перепечатывают, а потом ноют "пачиму ниработаит".
Сап, двач. Есть ли где-нибудь годный сборник ВСЕХ UB? Ну, или хотя бы просто всех UB, связанных с целочисленной арифметикой и побитовыми операциями?
>UB
чиго?
В стандарте.
Uncle Bob
Просто съеби
>сборник ВСЕХ UB
А ты стандарт-то читал?
uint32_t testvalue = (((72000000 / 64) x (5 / 1000)) - 1);
Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
У тебя там все деления целочисленные.
Смекаешь?
Nope.
> сборник ВСЕХ UB
В прошлом тредике что-то постили еще:
Скобки раскрой, нахуй ты их вообще расставил?
>Скобки раскрой, нахуй ты их вообще расставил?
uint32_t testValue = (1125000 * (N / 1000)) - 1;
где N - изменяющееся число, от 1 до 20.
Это не ответ, нахуй тебе скобки.
Спасибо, поищу.
Мне нужны только undefined behaviour в чистом виде. Не понятно, причем здесь стандарт, где эти вещи надо выколупывать смому из тонн текста.
Для красоты.
Как правильно преобразовать выражение, чтобы, сука, получить результат, как при решении на кулькуляторе?
Тебе блять дебилу уже сказали: убери нахуй свои ебаные скобки. И все. Заебал.
Ещё раз для тебя ебика повторю: У ТЕБЯ ТИП ЦЕЛОЧИСЛЕННЫЙ
Спасибо.
Нахуй там плавающая точка, если результат все равно обрезается до инта как раз после деления?
Спасибо, работает.
Нахуй ты пальцы постишь? Как думаешь что в целочисленных типах подставляется вместо X/1000 при x<1000?
Пацаны, где скачать C89 стандарт? У меня пригорамба. Его удалили ото всюду.
Допустим у нас объявлена структура и мы создали эту структуру в какой-то функции, вопрос: нужно ли использовать 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) ???
}
Пример:
typedef struct { int x, y; } pair;
static void get_distance_to_origin(pair p, *out_buffer){
pair origin;
origin.x = 0; origin.y = 0;
out_buffer->out = dist(p, origin);
//free(origin) ???
}
> нужно ли использовать free() или она удалится из памяти по завершению функции?
Нет, такие переменные называются автоматическими, и они автоматически перестают существовать при выходе из функции. Но проще всего думать по-другому: если ты сам что-то выделил или открыл (с помощью malloc или там fopen), то ты сам и должен вызвать очистку. Тут ты никаких malloc не вызывал, поэтому и free сделать не можешь.
>автоматические
Может локальные?
И трутся потому что на стеке.
>автоматические
>локальные
Два разных понятия.
>открыл (с помощью malloc или там fopen)
Да, структура (а точнее её часть) создаётся calloc' ом. Думал это не существенно.
Пасиб).
П.С. удаляется структура через особую ф-цию если что, и free используется только для части с calloc.
И в чем разница?
Мануал почитать, не?
Аноны, всем привет!
Сразу скажу: я люблю С и даже люблю плюсы (лол, да, я больной ублюдок) и пишу 98% времени только на этих языках иногда скриптики на пайтоне пишу по необходимости, когда это уместно
Скажите, как так получается, что среди огромного количества немолодых языков именно Сишечка и кресты остались на плаву и остаются актуальными и по сей день, а мб и останутся еще на пару десятков лет.
Я вот ни разу не ретроград и положительно отношусь к тому же Расту. Ведь крутой же язык, но бля, так-то если логически подумать, то ДАЖЕ ели он КОГДА_НИБУДЬ взлетит, то лет через 20-30 в лучшем случае, несмотря на то, что этот язык вполне удачно и рыбку есть и на хуй садится (безопасность памяти без сборщика мусора и производительность крестов - это прорыв в мире софта, имхо).
Но даже со всеми своими минусами С и С++ очень популярны и незаменимы в продакшене на мировом уровне, по крайней мере в ближайшие 2 десятка лет минимум. Как так получается? Всегда поражала некая устойчивость этих языков. Все решает то, что на этих ЯПах написано СЛИШКОМ много софта, переписывать который невыгодно ни с временной, ни с экономической точки зрения? Так получается? Ибо если мыслить исключительно с технической точки зрения, то Раст уделывает С и С++ по фичам и дает ту самую безопасность, но парадокс в том, что такой язык может даже не взлететь в итоге и не спихнуть с трона С и С++. Меня это несколько озадачивает.
На ваш взгляд, причина только в том, что УЖЕ слишком много системного софта написано на С и С++ и людям просто невыгодно/лень переходить на раст всем миром, пусть даже он и более навороченный и взявший от обоих миров все самое лучшее? Ваше мнение, уважаемые. Всем бобра :3
Сразу скажу: я люблю С и даже люблю плюсы (лол, да, я больной ублюдок) и пишу 98% времени только на этих языках иногда скриптики на пайтоне пишу по необходимости, когда это уместно
Скажите, как так получается, что среди огромного количества немолодых языков именно Сишечка и кресты остались на плаву и остаются актуальными и по сей день, а мб и останутся еще на пару десятков лет.
Я вот ни разу не ретроград и положительно отношусь к тому же Расту. Ведь крутой же язык, но бля, так-то если логически подумать, то ДАЖЕ ели он КОГДА_НИБУДЬ взлетит, то лет через 20-30 в лучшем случае, несмотря на то, что этот язык вполне удачно и рыбку есть и на хуй садится (безопасность памяти без сборщика мусора и производительность крестов - это прорыв в мире софта, имхо).
Но даже со всеми своими минусами С и С++ очень популярны и незаменимы в продакшене на мировом уровне, по крайней мере в ближайшие 2 десятка лет минимум. Как так получается? Всегда поражала некая устойчивость этих языков. Все решает то, что на этих ЯПах написано СЛИШКОМ много софта, переписывать который невыгодно ни с временной, ни с экономической точки зрения? Так получается? Ибо если мыслить исключительно с технической точки зрения, то Раст уделывает С и С++ по фичам и дает ту самую безопасность, но парадокс в том, что такой язык может даже не взлететь в итоге и не спихнуть с трона С и С++. Меня это несколько озадачивает.
На ваш взгляд, причина только в том, что УЖЕ слишком много системного софта написано на С и С++ и людям просто невыгодно/лень переходить на раст всем миром, пусть даже он и более навороченный и взявший от обоих миров все самое лучшее? Ваше мнение, уважаемые. Всем бобра :3
>как
Стандартизация и х86, пропала необходимость в бесконечном количестве языков.
Дальше не читал, стена пиздец огромная брат
void foo(void) { int automatic_local; }
void bar(void) { static int non_automatic_local; }
void baz(void) { extern int non_local_non_automatic; }
> Раст уделывает С и С++ по фичам
Видели мы таких уделывателей. Они уделывались и куда-то исчезали. И чем более крутые фичи и мудреный синтаксис там были, тем быстрее исчезали. Людям не нужен крутой язык. Людям нужно говнокодить, даже если это системный софт или вообще драйвера. А для заклинаний у нас уже есть кресты, никто в здравом уме одни нечитаемые заклинания на еще более нечитаемые не променяет. Особенно когда на первых пишут, а на вторых - только полтора восторженных юноши.
>дает ту самую безопасность
В том и смысл, что не даёт, поэтому и не взлетает.
А как же тот факт, что насрать в память можно только в unsafe блоках, куда и можно кинуть все потуги по тестам? Ведь вне ансейфа там не может быть ни переполнения, ни дабл фри, ни UAF. Не серебрянная пуля, офк, но зато не весь код == потенциальный UB, а только отдельные и четко известные его части.
Согласен.
Мне жутко обидно за Раст. Такой годноты мировая общественность еще не знала, но он, по-видимому, не взлетит.
>видали мы таких уделывателей
Ну и кого же вы там видали?
Добавлю, что дело скорее в том, что системное программирование, как бы выразиться, не на подъеме. Все операционки, базы данных и библиотеки уже написаны. А переписывать на Раст многолетний код, который уже работает, никто не будет, естественно.
> Все операционки уже написаны
То-то ни одной нет, а для мобилок гугл аж вторую подряд пилит.
Да пусть хоть обпилится этими ОС. Все сейчас на ядро линукса переходят. Ну, или какой-нибудь BSD под себя переделывают.
Ни разу не показатель. Гугл пытались высрать Дарт - высрать-то высрали, но вот жопаскрипт показал кто тут батя, даже гугловое влияние не позволило хоть как-то взлететь их поделию, хотя все пророчили, что Дарт - прямой убийца жса.
Линукс как использовали, чтобы запускать его на мобильниках, микроволновках, спутниках, космических кораблях, картошке, умном вантузе, так и будут использовать. Чтобы убить такое, нужно изобрести принципиально новую архитектуру компьютеров и в частности процессоров, прямо принципиально новую, непохожую на существующую, и заставить весь мир на нее перейти. Но вероятность этого чуть менее, чем 0 процентов.
>и заставить весь мир на нее перейти
и написать новые йоба-языки программирования, которые настолько же отличаются от всех существующих, как и новая архитектура компьютеров.
Не, мб через лет 100-150 будет ебейшая компьютерная революция и полная перестройка, но не при нашей жизни, братцы.
ну а как насчет новых проектов? Ведь разработка системного ПО далеко не всегда == ковырянию в легаси уже существующей кодовой базы. Речь не только про такие крупные проекты, как ОС, известные БД и т.п., есть же еще драйверы, прошивки, которые пилятся гораздо чаще, чем ОСи. Ну и просто системные утилиты, сервисы там какие-то, которые должны крутиться на каком-то порте и иметь прямой выход в интернет
На небольшом подъёме компьютерное зрение на микроконтроллерах. Писать на Си нейронки с восьмибитной фиксированной точкой - это тот еще коктейль делать. Хотя. говорят, интересно, и не ковыряние легаси.
это все зависит еще от страны
Много компаний берут ядро Линукса и пилят кастомный софт на него (дрова и прошивки под разный эмбеддед, как правило).
>есть же еще драйверы, прошивки, которые пилятся гораздо чаще, чем ОСи
Я ковыряю сейчас Embedded Rust, с одной стороны забавно, что система типов используется в правильном направлении - ты не можешь засунуть регистры микроконтоллера в невалидное состояние, потому что если пин занят, например, аналоговым вводом, у тебя уже не получится работать с ним, как с цифровым выводом, компилятор будет ругаться, потому что сам пин - это ресурс, который может принадлежать либо одной структуре, либо другой.
Но, с другой стороны, на контроллерах даже на С++ в основной своей массе не перешли, слишком мало профитов это все дает, программы простые сами по себе и йоба-контроль от компилятора не нужен, а для более сложных вещей уже можно и скриптовый язычок какой-нибудь поинтерпретировать.
https://pastebin.com/HQ99t604
Что не так?
Что не так?
Я нихуя не понял. Оставил только 3 строчки, все остальное стер. Работает
>Кстати поясните нахуя МЦСТ свой ёбаный путь, когда, например, VIA делает процы на x86-x64? В чём суть?
Потому что штеуд запретил навсегда лицензировать хуй86 кому бы то ни было еще кроме лизочки писечки и собственно via.
Если бы штеуд разрешал пилить х86 этим бы не то что МЦСТ этим бы 3/4 производителей чипов бы занимались шутка ли такое-то легаси.
Потому что штеуд запретил навсегда лицензировать хуй86 кому бы то ни было еще кроме лизочки писечки и собственно via.
Если бы штеуд разрешал пилить х86 этим бы не то что МЦСТ этим бы 3/4 производителей чипов бы занимались шутка ли такое-то легаси.
Ну ведь есть не только хуй86. Тут даже десктопные пека теперь будут на самой популярной архитектуре "скоро". Что скажешь?
Поясните более подробно за указатели и адреса молю.
Чем отличается
int c
от int c
Такая непонятная хуйня уже весь мозг себе сломал.
Чем отличается
int c
от int c
Такая непонятная хуйня уже весь мозг себе сломал.
>нихуя не понял
потому у него cpp он тредом ошибься.
Понять указатели это как девственности лишиться. Сиди и думай
я листва дo сих пoр. пoэтoму oбъясни мне, мoлю. или дай хoтя бы ссылку на какoй-нибудь мануал пo ним.
тo есть oтличается
int "звздoчка"с
oт
int"звёздoчка" с
Ничем.
хули там понимать, за 1 час можно понять всю суть указателей
Читай стондарт.
C18? Алсо, кто его запил, Ритчи же давно нету.
В шапке всё есть.
>int c
>от int c
временем жизни
двач проглотил звёздочки просто которые должны были показать разницу между ними.
Libcurl сишная же
Ну нахуя шизоиду отвечаешь?
><iostream>
тoже сишная либра?
Вопрос то у меня не по ней, а конкретно по libcurl.
Есть именно что хуй 86, убивший за 30 лет нахуй всех своих конкурентов - Power, Alpha, SPARC.
Если ты про арм - то он не конкурент, даже в самых своих мощных реализациях от яблока и квалкома он кукурузнее самых неудачных фуфыксов.
arm убьёт x86, можете скринить. А потом будет RISC-V.
Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать, да и бум мобилок ускоряет заколачивание гроба.
> arm убьёт x86
Не убьет.
> бум мобилок ускоряет заколачивание гроба
Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона.
В то время как бэкенд по прежнему крутится на могучих х86 зивонах и никаким немощным рукам их там не потеснить - когда доходит до дела - нужна честная моща пер коре а не кукуруза с многоядерным потанцевалом и проблемой рожающих бабищ в 99% реальных задач.
> Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать
Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
х86 ассемблер может быть сколь угодно громоздким - микроархитектурка решает и ставит рекорды производительности на ядро.
Дошло до того что зеоны ебут уже который год считавшихся непобедимыми динозавров от IBM (POWER и Z).
Да и, собственно, с появлением дохуядерных эпичей от лизки и дохуядерных платинов от штеуда, арм на серверах закопан нахуй окончтельно.
Пацаны, че за хуйня. Работаю над кодом вместе с libusb.
Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.
Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)
Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.
Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)
Новые армы в бенчах уже показывают сравнимый с интелами результат: https://www.macrumors.com/guide/arm-macs/ - и это при в разы меньшем tdp. У интелов же - родовая травма в виде сложного декодера и малого числа именованных регистров, из-за чего им крайне сложно повышать число инструкций на такт. Ты забыл, так я напомню - во времена Haswell интелы росли в однопотоке на 3-5% на поколение. И мы сейчас вполне можем вернуться в это страшное время.
>2020
>хвалить обоссанную ноусофт консоль
Я уже молчу, каким отбитым имбецилом надо быть, чтобы не видеть разницы игрушки от компьютера с набором софта за 40 лет. Ах да, это же пердоля с таким же ноусофтом и пердольными игрушками. Вот откуда рак и деградация лезет, из этого отстойника скама человеческого.
>Не убьет.
Скринь.
>Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона...
Ну а теперь сравни гешефт с продажи одного условного сервака для бекенда и десятков тысяч мобильников, которые этот сервак будут использовать. Сравни число произведённых процов каждой архитектуры для данного наборчика и осознай, что в недалёком будущем камни на x86 будут производить 1.5 фабрики на весь мир. А за количественными переменами последуют и качественные.
>Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
Ага, что вкупе с обратной совместимостью, а также всякими непрозрачными архитектурными перделками превратило типичный проц от, допустим, интела в никому не понятный ОГРОМНЫЙ чёрный ящик с кучей бекдоров, какими-то встроенными микро-ос и прочим хламом. А агрессивные попытки все это заставить быстрее работать оборачиваются очередными уязвимостями.
Ну да, ну да - смартфон нинужон, дубль два. Конец уже сейчас предсказуем - нынешний айпад про станет новым форматом железа, и у жужжащих ящиков пропадет ещё половина рынка. Потом вендоры АРМ и ПОСов подтянутся и интелов станет ещё меньше. Слона съесть несложно, ежели по частям.
>с набором софта за 40 лет
Какой, нахуй, софт за 40 лет? Сейчас уже 95% реально используемого людьми софта либо open-source, либо скомпилировано под кучу других платформ, помимо windows+x86. Хоть на чайнике запускай.
#include <libusb/libusb.h> не?)
Вот ее объявление: https://github.com/libusb/libusb/blob/14a302a2f55cb2e619158854f94845f2ca2c8214/libusb/libusb.h#L2084
Зделой объявление функции перед мейном.
>Какой, нахуй, софт за 40 лет?
Вот двачую. Игорей конца 90 уже хер где запустишь, разве что в эмуляторе, что съедает хваленую производительность хуй86.
Если ты установишь эту либу на систему, она будет подключена как
[code]
#include <libusb-1.0/libusb.h>
[/code]
.
Нужен кто-то, кто мог бы решить ряд задач из университетского курса. Процессы, нити. С деньгами постараюсь не обидеть, обсудим.
Если кого-то заинтересовало - пишите в тележку
@twoomer
Если кого-то заинтересовало - пишите в тележку
@twoomer
Тред живой?
Помогите найти простые примеры программ и игр на си, а то я пробовал выдает только c++ и c#
Движок игры Дум (1993 год) напиан на Си, например.
А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой.
С++ - идеальный варик для ГЕЙдева.
Луа, гну сциентифик лайбрари. Первое это полноценный язык, занимающий всего пару тысяч строк кода. Второе образец того, как должна была выглядеть лаба1.с - реализация различных математических алгоритмов типа оптимизации, линейкит итд.
>Помогите найти простые примеры программ и игр на си
>Движок игры Дум (1993 год) напиан на Си, например.
>Луа, гну сциентифик лайбрари.
Вы нормальные? Он же просил простые игры, ПРОСТЫЕ!
>Вы нормальные? Он же просил простые игры, ПРОСТЫЕ!
Имплаинг дум - сложная игра
https://github.com/ljbade/wolf4sdl
>А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой
Если подключить Lua или иную скриптопарашу, а сами си использовать онли для низкоуровневых кишочков, то не так уж и больно.
все равно, все это попытка высрать баржу, гораздо более здраво писать такие вещи на С++ (или Сишарпе, смотря какой API хочешь и вообще какие требования к игре)
Нравится Си тем что язык не сложный, небольшой, не нужно изучать постоянно всякие фреймворки как в JS или Java. Вот только сомневаюсь что смогу найти работу. Для системных программистов высокие требования. ВО, а его у меня нет. Большой опыт работы, которого у меня тоже нет. Мало вакансий. Что делать?
Если ВО - не варик, то учи сам + пили личные проекты, офк нетривиальные. Это единственный выход.
А вообще - байтослесарям сложно найти работу в странах СНГ. Они больше ценятся забугром, там и embedded software engineer получает не меньше, чем жс-макака. В СНГ, увы, ситуация далеко не такая.
Пичалька
>не нужно изучать 3рд пати хуйню
Не нужно только до того момента пока ты тыкаешься в хеловорлды и линкедлисттуториал.с, в реальности же даже в современную микруху ты со знанием голого си не потыкаешься.
Сравнение неподходящее. Какие то небольшие либы сравниваешь с монструозными фреймворками.
>какие-то небольшие либы
Это конкретно в примере с бытовой микрухой может оказатсья КАКАЯ-ТО НЕБОЛЬШАЯ ЛИБА. И ты забываешь, что именно монструозность сишных фреймворков в прошлом, — вроде того же опенгла, старых директексов, снящихся в страшных снах людям вин32 и прочего, — стала от части причиной появления менее монструозных фреймворков на более современных языках. То что эту хуйню перестали использовать не значит что этого никогда не было. И не значит что не существует до сих пор поддерживаемых на них продуктов
Алсо проиграл с луа с сурсом в сто строк пиздец
> старых директексов
И давно DirectX, у которого API на COM, стал сишным фреймворком? А вот опенгл нихуя не монструозный, полноценную реализацию OpenGL 1.x с софтварным рендером можно целиком написать в одно рыло, и код, как пользовательский, так и самой либы, будет понятен, в отличие от крестов в том же DirectX.
На самом деле проблема геймдева на Си заключается в менеджменте памяти в основном. Когда большие мальчики обмазываются всякими RAII и автоматическими указателями, когда они даже не знают, сколько раз выделилась память для их строчек, и сколько раз эти строчки при конкатенации скопировались, ты по-прежнему вынужден ебаться с goto cleanup и маллоками на каждый чих. И это слегка демотивирует. Чтобы как-то обойти эту проблему, ты тащишь статические буферы везде, куда сможешь дотянуться, что создает кучу других, еще более веселых проблем.
>И давно DirectX, у которого API на COM, стал сишным фреймворком?
COM - сишный API. Лично юзал DirectX из сишного кода.
>COM
Нет. Это общеязыковой api для винды. Его можно юзать на вижуал бэйсике.
Технически, это сишный АПИ (функции с cdecl типом вызова, экспортируемые из DLL) + набор соглашений.
Потому что на Си написан? Хотя я сомневаюсь, скорее всего на плюсах. Никакой это не сишный апи. Вот libc в линуксе да, чисто сишный.
Да, юзать COM еще туда-сюда из сишки можно. Если MS не забыла для тебя кроме варианта class написать в хедере все эти struct и STDMETHOD, обмазав толстым слоем макросов (посмотри, в заголовках директикса отдельный #ifdef для сишки... пока еще есть или уже нету в последних версиях?). С реализацией своих объектов начинается боль, особенно когда у тебя несколько интерфейсов. Да, их тоже можно на си писать, можно хоть на ассемблере писать, но это будет больно, это будет тонна однотипных реализаций QI/AddRef/Release, которые нельзя объединить, потому что офсеты lpVtbl в структуре у разных интерфейсов разные. При этом на крестах вся эта боль почти целиком уходит. Поэтому COM - крестовый.
> Лично юзал DirectX из сишного кода.
Алсо, я забыл добавить. Я вот юзал std::string из сишного кода (на лету генерировал обертки, превращающие __thiscall в __stdcall). Он стал от этого сишным?
> Я вот юзал std::string из сишного кода
А животных ты часом не ебёшь, извращенец?)))
Черная живет материя!
https://github.com/openssl/openssl/pull/12089
https://github.com/openssl/openssl/pull/12089
>Черная живет материя!
Вопрос: почему есть место для белых whitespace, а для чёрных нет?
Место для чёрных это backspace.
Кстати, забавляют эти потуги белых людей решать за чёрных людей, что для них оскорбительно, а что нет. Это же вроде расизм, разве нет?
Хочу, чтобы у меня на всех окнах было одинаковое верхнее меню (File, Edit, View, ...), но GTK почему-то не разрешает мне это сделать. Как фиксить?
Лол, у нас на работе ради прикола переименовали master-slave на master-pokemon. Но это ещё до всей этой хуйни было.
https://pastebin.com/gRC0UScq
Где я проебался с выравниванием, что atoi падает с сегфолтом?
В omp parallel нельзя выделять выравненную память?
Блять, я сонный ебаный не передавал количество тредов при запуске. C господа, отбой.
Как удалить строку из файла силами C? Занести все строки файла в оперативную память, пересоздать файл и занести их обратно?
Закинуть кусок файла после строки в память, удалить строку (и после не забыть fseek выставить на последний байт перед удаленной строкой), записать ранее сохраненный кусок по SEEK_CRT.
>удалить строку
Прости хоспаде. ничего не удаляй, просто выстави fseek на первый байт той строки и пиши.
Правильный способ от олда:
1. создал временный файл
2. читаешь по символу, считаешь строки, пишешь во временный
3. fflush
4. rename(временный, оригинал)
Как лишние символы затереть?
А как сделать временный файл таким, чтоб не было пересечений с уже существующими файлами в папке?
tmpfile() тебе дали и tmpnam() еще.
за такое говнище надо сразу в ебало давать
Почему?
мимо
Аноны, как заменить gets() на fgets()?
fgets(указатель на массив, кол-во читаемых символов, stdin)
Только он вносит символ перевода строки в строку, а не выкидывает его оттуда. Можешь либо свою функцию написать, либо обёртку для fgets, которая выкидывает символ перевода строки и очищает входной поток.
https://pastebin.com/jC1PBdsX
а за такое ебут в жёпы?
а за такое ебут в жёпы?
Лол, зачем ты проверяешь неравенство с NULL? Можно же просто булевоское значение указателя взять.
копипастил слегка недописанный код,
вот так лучше - https://pastebin.com/uUy3jV95
>булевоское значение указателя
Куда ходить?
1) у вскякого арифметического типа (указателя, например) есть будевское значение. Если указатель не нулл, он true.
2) ты не проверяешь ошибки выделения памяти. это хуёво.
3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
4) ваще, какое-странное решение отмечать конец массива строк пустой строкой. Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом? в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
> используй strncpy
Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
>Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
чёт обосрался я. запишем в конец буфера ещё нолик в любом случае.
>Если указатель не нулл, он true.
Вроде это ебота от платформы зависит. null не всегда равно 0x00.
>2) ты не проверяешь ошибки выделения памяти. это хуёво.
Согласен. Но это нахуй никому не нужный привет_мир на две-три сотни лайнов.
>3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
Что и в п.2
>4) ваще, какое-странное решение отмечать конец массива строк пустой строкой.
Мне так местные посоветовали.
>Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом?
Хорошая идея, пока лучшая.
>в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
Тогда маленький мемори-лик, да. Но строки будут непустыми.
>5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
Внезапно для меня realloc() может вернуть указатель с другим значением. Не знаю с чем это связано, но очевидно не с brk(), так как после фиксированной n строки значение указателя меняется(алсо меняются и указатели на строки). Я потому сюда и закинул эту хуиту, уж больно уродливо вышло.
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
короч, null pointer константа по стандарту - арифметическая константа, имеющая значение 0. или таковая, приведённая к типу (void звёздочка). чёт, я не смог прм точную цитату в стандарте про обратное преобразование лул, но все другие источники говорят, что булевское значение указателя true тогда и только тогда кода он не null pointer.
>realloc() может вернуть указатель с другим значением
ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
Нет. Это в стандарте языка, здесь от платформы ничего не зависит.
if (ptr == NULL) пишут только зеленые касатики, прошаренные бати знают, что первое - говнокод, и кошерно писать if (!ptr)
> я не смог прм точную цитату в стандарте про обратное преобразование лул
Его нет. if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0. Операторы сравнения != и == сами автомагически умеют сравнивать указатель с нулевым указателем такого же типа, каким бы не было представление. И уже у операторов сравнения на выходе инт.
Не говнокод ни разу. Исключительно вопрос выбранного стиля. Явное сравнение лучше читается, плюс некоторые пишут выражения вида if ((ptr = func()) != NULL), в них без != NULL нельзя - будет варнинг. Из этого выражения явное сравнение ради консистентности растекается и на if (ptr != NULL), и на if (ptr == NULL).
>будет варнинг
клангу похуй
>if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0
по маняопределению.
не видел такого в стандарте. там только написано, что арифметические типы имеют булевское значение true если не равны нулю. Указатели же неявно преобразуются к арифметическому типу. Про нулл поинтер сказано, что он - нулевая арифметическая константа или результат её приведения к типу войд звёздочка. Явно про обратное преобразование не сказано.
> if (ptr == NULL) пишут только зеленые
Зеленый жир, плиз.
Писать надо:
if (NULL == expression)
потому что expression может быть длинное, функция, и смотреть в конец неудобно и не наглядно, код плохой получается. А когда в начале, сразу видно что и как.
>ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
Добра тебе, мелкобуквенный гений. А я просто приучил себя к указателям, как собаку Павлова.
>в них без != NULL нельзя - будет варнинг
Кстати вспомнил, почему так и начал писать, т.к. раньше тоже !ptr юзал. Энивей какой-нибудь -pedantic варнинг родит.
>Энивей какой-нибудь -pedantic варнинг родит.
Нет, я снова обманывать, с таким сетом флагов
>-Wall -Wextra -std=c99 -pedantic
gcc молчит.
> по маняопределению.
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 и там много всего еще. Но заметь, никаких преобразований.
> Писать надо:
> if (NULL == expression)
Толсто.
> вменяемом комментарии
компиляторе
Не смог нагуглить, как сделать вывод в консоль,чтоб сверху или снизу выводилась строка состояния, а в остальных строках выводились данные из другого потока и чтоб они не перезаписывали строку состояния в идеале чтоб данные прокручивались а строка состояния была на своем месте
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
это на линуксе должно работать
нашел, ncurses
Объясните, в каких случаях принято делать структуру с указателями на функции? Чем обычное объявление функций хуже?
1) колбеки в чяужую библиотеку
2) массив функций, вызов по номеру без свитч-кейс без регистрации
3) реализация опенгл под шинду - там по умолчанию изкаробки только фичи из конца девяностых, за нулевыми и десятыми с их шейдерами нужно добывать как руду у драйвера через указатели на функции..
Привет, анон. Есть какой-то известный быстрый алгоритм для перевода дробной части, записанной в бинарном виде, в строку с десятичной записью? Дробная часть может быть 128 бит, так что, видимо, конвертация в double и печать в строку не катит.
Я как-то из интереса попытался на асме написать функцию вывода числа типа 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 и нуля обрабатывать отдельно
Блядское форматирование. Фикс.
0,1101 = (1/2) + (1/4) + (1/16) = 0.5 + 0.25 + 0.0625 = (1000×5 + 100×5^2 + 5^4)×10^(-4)
а теперь вали читать IEEE754 и плакать
Можно вкратце, что не так?
Ну, вообще да, с денормализованными числами так не выйдет.
Это да, это понятно, но как это сделать без длинной арифметики (число бит для дробной части у меня большое)?
Я помню, что, например, для перевода из восьмеричной системы в десятичную был довольно элегантный и легковесный алгоритм (в то время как перевод в лоб требовал длинную арифметику для деления и умножения).
Ну, тем не менее, это релевантно для чисел с фиксированной точкой, с которыми я и мучаюсь.
> но как это сделать без длинной арифметики
Никак, смирись и пили длинную арифметику. Не так уж это и сложно, можешь в столбик считать, как в школе.
Эх, печаль. Я не спорю, что не сложно, просто для 128 бит это выглядит как оверхед. Ладно, поищу, может, есть ли portable-реализация __int128_t.
Мне казалось, что даже для float нужен как минимум int512, для хранения 5^n. Хотя, наверняка есть способ попроще.
Какую книгу можно почитать, новую, по последним стандартам Си? Кернигана и прату читал, но уже прошло много времени, подзабыл ось. Что-то новенького хочется. Подскажите.
Да, ты прав, я на свежую голову посчитал, там больше надо.
Дейтелов мб?
Есть ли какие то подводные у:
typedef struct {...} struct_name;
Всегда ли можно писать так?
Единственный подводный - связанные структуры данных (элементы списков, деревьев), для которых ты не сможешь использовать тип, определяемый тайпдефом, внутри этого тайпдефа: typedef struct { ??? ∗next_node; int value; } linked_list_node; ну ты понял. Потому что этот тип на момент использования еще не существует. А вот у typedef struct foo { ... } foo; или typedef struct foo foo; struct foo {}; подводных нет. Второй вариант более многословный, зато позволяет при необходимости быстро отделить интерфейс от реализации: просто оставляешь тайпдеф как есть в .h, а структуру уносишь в .c, и если у тебя все манипуляции идут через указатель на foo, то пользовательский код никогда не узнает, что там внутри.
Про связанные списки я знал, а вот за разделение интерфейса и реализации спасибо, не знал.
тащемта, opaque pointers обеспечивают идеальную инкапсуляцию, абсолютно непробиваемую
Вы про расширения SSE/AVX не слышали?
А откуда такая уверенность, что целевая платформа - x86?
Как сделать чтобы в выводе консоли изменялись лишь некоторые данные?
Ну допустим Я вывел
Таблица
Счёт: ++variable
И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.
Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
Ну допустим Я вывел
Таблица
Счёт: ++variable
И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.
Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
Вот скрин консольной таблицы из интернета чтобы анонам понятнее было.
Вот допустим это всё вывод моей программы. И мне нужно только чтобы подчёкнутое красным число 10 изменялось, допустим 9 или 11 12 13. При этом чтобы всё таблица не перевыводилась с нуля. Как это сделать?
ncurses clear(3)
спасибo анчoус.
Я насчитал минимум в 44 байта
Аноны, без шуток, Сишечка может умереть лет через, скажем, 50? Знаю, тупой вопрос, да и мне к тому времени уже будет похуй, но чисто теоретически интересно.
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Проблема с таким далёким будущим — мы даже не можем предсказать, не будет ли через 50 лет ассемблер ниже уровнем чем си, лол.
А вообще, сейчас есть тенденция запихать побольше ядер (т.к. частоты наращивать не получается) и единственное что можно гарантировать — будут востребованы языки хорошо умеющие в мультитрединг. И это явно не си, но и аналоговнет, что называется.
>Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст), но переписывать работающий софт который всех и так устраивает — это тупость.
Нет, не может, C - это lingua franca программирования.
>Есть смысл новый писать не на сях
Не все так однозначно. Много "безопасных" программ юзают туеву хучу сишных либ. Пример, за котором далеко не надо ходить, Дискорд. Написан на джаваскрипте, гуй - Электрон, но если ты откроешь memory layout процесса - ты увидишь кучу so(в случае с Линуксом)/dll(в случае с виндой), которые написаны на Сях. И там может быть дыра, так что даже такое якобы безопасное приложение уязвимо к атакам на память.
Учитывая, что даже в 2к20 продолжают писать на сях, а не только поддерживать тонну легаси, то хз-хз... При моей жизни Си точно не умрёт.
Ну, разница в том, что у тебя вместо 30-ти 0-day CVE будет 15-20, это на самом-то неплохой прогресс как ни крути. А с другой стороны это хорошо так поднимет цены на рынке эксплоитов, хех.
Понятное дело, что они не умрут, на них в конце концов кода куда больше чем на каком нибудь коболе, который все ещё жив спустя 30+ лет умирания, только вот имхо — область точно сузится до переносимого ассемблера. Единственный прогноз, который вообще возможно сделать на эту тему.
>переносимого ассемблера
Си и так переносимый ассемблер, алло. Это то, что делает Си неубиваемым ЯПом.
А ещё на сях и плюсах написано куча софта, который спокойно можно написать и на чём нибудь другом, приём, вас плохо слышно.
Ядром, кодеками и драйверами всё как бы не ограничивается, всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
>всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
Это едва ли не половина всего софта, написанного на сях.
И какие игоры за последние 15 лет написаны на сях?
Почти все. Я си с плюсами не различаю в этом вопросе, т.к. любой плюсовый геймдев стоит на куче сишных либ от опенгла до всяких физических движков.
Из именно игр — вроде как автор factorio говорил что она на чистом си написана.
После 2000 года все перешли на С++
>Я си с плюсами не различаю в этом вопросе
Ясно
>физических движков.
Physx, bullet, havok - все С++.
>опенгла
Через 30 лет произойдет коболизация си.
Выжившие сишники будут поддерживать ядро пинус для марсоходов.
Предсказать, что будет через 50 лет, в принципе невозможно. Разве можно было предсказать хоть примерное развитие современного телекома и программирования в 1970 году? Уильям Гейтс со своими 640 кб оперативы и то позже был.
Сейчас тенденции на смены парадигм. Например, развитие супер параллельных процессоров, нейро-процессоров. Пока диковинка, но за 10 лет может стать чем-то обыденным. Изменения в концепциях написание программ, уход в виртуализацию всего и вся, куча всего ещё.
Нет, не думаю, что C/C++ сохранится. Слишком уж динозавр из другого мира.
>После 2000 года все перешли на С++
На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Плюсы очень спорное решение на самом деле.
Разговор про игоры. Игорей, особенно крупных, на Си давно не пишут.
>Нет, не думаю, что C/C++ сохранится
Лол, даже ссаный кобол уже лет 30 умирает, но никак не сдохнет, хотя кода на нем написано в десятки тысяч раз меньше, чем на С/С++
>развитие супер параллельных процессоров, нейро-процессоров
И подноготная всей этой параши будет как всегда на С/С++
Скорее джаваскрипт сдохнет в вебе (нет), чем С/С++ в системщине и подноготной всея мира ойти технологий
Кобол уже 30 лет назад сдох, просто где-то до сих под используется древний софт на древних компах или их эмуляторах.
Само собой, сишечка полностью не сдохнет. Хотя бы потому, что ядра ОС и кучи системного софта на ней написаны, которые работают хорошо, исправно, и свои задачи прекрасно выполняют.
Но само программирование может драматически измениться с тем, как поменяются парадигмы программирования.
Тупо сишечка и плюсы плохо предназначены для многопоточного программирования. А эволюция очевидно идёт в направлении супер-многопоточного программирования. Потому что возможности одного ядра давно исчерпаны, по мелочам как-то оптимизируют, зато вот возможностей для увеличения количества ядер очень и очень много. Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер (блядь, кто-нибудь в 70-е годы мог предсказать микро-сд карты на сотни гигабайт за копейки?), но для этого надо принципиально менять парадигмы программирования и платформы.
Это неизбежно произойдёт. Но как именно это будет выглядеть невозможно предсказать.
> Тупо сишечка и плюсы плохо предназначены для многопоточного программирования
Не неси хуйню
А надо сразу уточнять тогда, здесь провидцев нет.
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Пруф? Пока выглядит как высер, не обессудь.
>На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Фантазии. Отдельные чудаки могут писать на чем угодно, но стандарт индустрии - с++ и с#.
>Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер
Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Отлично приспособлены, ничуть не хуже любого другого языка.
>Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
С гигагерцами ПОКА есть проблемы, количество транзисторов на кристалл до сих пор растёт по экспоненте.
https://youtu.be/c01BlUDIlK4
>будут востребованы языки хорошо умеющие в мультитрединг.
Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело.
>Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст)
Раст не даёт той безопастности, о которой ты говоришь и думаешь.
>но переписывать работающий софт который всех и так устраивает — это тупость.
Всё так, а ещё большая тупость - менять коней на переправе.
>Раст не даёт той безопастности, о которой ты говоришь и думаешь.
Что ты имеешь в виду?
> стандарт индустрии - с#
Во влажных фантазиях M$-фанбоев, клепающих миллионный по счёту три-в-ряд.
>Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело
Мдэ, ты вообще на чём нибудь кроме си писал за последние 10 лет, мм, неолуддит?
>Раст не даёт той безопастности, о которой ты говоришь и думаешь.
Тем временем как минимум 2/3 уязвимостей — это переполнение буфера, use-after-free и прочие радости. Нет, он даёт именно ту безопасность, о которой я думаю.
>Всё так, а ещё большая тупость - менять коней на переправе.
>Пословица, также как и фразеологизм, в России с середины 1990-х годов употребляются в контексте нежелательности смены политических деятелей и представителей властных структур: Ельцина, потом Путина и Единой России. В аналогичном смысле эту пословицу используют и в других странах: в Белоруссии — применительно к её президенту Лукашенко, в Малайзии — применительно к её премьер-министру Абдулле Ахмаду Бадави[3]. В этом же смысле эта поговорка была использована президентом США Авраамом Линкольном на президентских выборах 1864 года, когда он баллотировался на второй президентский срок во время гражданской войны в США[4][5].
Ору.
Если уж мы дошли до афоризмов, то можно сравнивать си с пыней? Не дадим геям усыновить наш код!1
Спешите видеть, либераха приплетает рашку к ойти.
>ряяя вреееетиии диды страдали и я буду(99
Ты сам это начал. Ответить на всё остальное нормально видимо, не в состоянии уже.
>микро-сд карты на сотни гигабайт за копейки?
где бы такую купить...
>С гигагерцами ПОКА есть проблемы
В середине нулевых был достигнут современный уровень, 3.5 GHz, на процессоре пентиум-4. Дальше он не рос, производительность увеличивалась за счёт качества архитектуры, а не тактовой частоты. Зачастую тактовая частота снижалась, а потом заново увеличивалась.
А вот количество транзисторов до сих пор растёт по экспоненте. Усложняли ядра, добавляли кеш-память, добавляют ядра. AMD уже разродился процом на 64 ядра. На видеокартах тысячи примитивных ядер, есть ai-ускорители на тысячи ядер.
Ничто не мешает в принципе сделать и миллион ядер. Пока немного не хватает технологий для этого. Но развитие идёт к тому, чтобы поддерживать массовую параллельность. А от языка требуется, чтобы он нативно удобно поддерживал массовую параллельность, как в гошечке это есть.
Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART? Мне нужен элементарный flow controi, т.к. апапартной поддержки нет, а софтварный XON/XOFF очевидно не подходит из-за "бинарности" отправляемого файла. Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе если бы не это, то уже давно навасянил бы какое-то кастомное простое говно
base64 + sw fc
>base64
uuencode
intel hex
Вот это уровень дискуссии, высрал хуйню, потом почувствовал себя затралленым — и начал репортить)0
Можно засчитывать слив питушку.
Мочер, а ты сам-то хоть читаешь что трешь?
Не очень хочется заниматься этой конвертацией говна и уменьшать и так не очень большую максимальную скорость передачи...
Но наверное ты прав, тут либо извращаться и пилить свой протокол, либо извращаться и использовать.то, что ты предложил.
>Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART
>Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе
zmodem
dcss на си написан. Там открытый код.
>dcss на си написан
с++
> AMD уже разродился процом на 64 ядра
128.
> Ничто не мешает в принципе сделать и миллион ядер
А ты видео то смотрел? С увеличением кол-ва ядер увеличивается сложность алгоритмов, затраты на планировку и вообще при таком количестве ядер, все алгоритмы поломаются и просто перестанут работать без должных оптимизаций.
>все алгоритмы поломаются и просто перестанут работать без должных оптимизаций
в треде о том и разговор, что в ситуации, когда рост производительности идёт в многопоточном плане, без роста однопоточной производительности, нужно а) использовать другие алгоритмы б) использовать инструменты, языки и стили программирования которые (лучше) позволяют автоматически параллелизовывать написанное. Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
>Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
Звучит правдоподобно.
Слишком сложно или нет? я хуй его знает, загуглил готовые реализации - вроде очень много кода
bitches dunno bout mah #pragma omp for
>Ну тип, если функцианальник и часто испольешь мапы в своём коде
То это говно на списках создает кучу cache miss'ов и прочего говна. А если заюзал pragma omp parallel for, то все просто и понятно
В том-то и задача языка, чтобы сделать программирование таких алгоритмов и задач лёгким и непринуждённым.
Си слишком дубовый, слишком явный и низкоуровневый. Иногда это хорошо, для каких-то системных задач, но иногда нет.
Возможности для конкурентности сильно ограничены из-за этого.
В Го отдельный тред-поток исполнения запускается просто оперетором "go", удобные каналы и агрегаторы каналов (селекты). Не нужно думать, что там внутри, не нужно детально прорабатывать схему распараллеливания, не нужно всяких #pragma-костылей. Просто запускается отдельный поток. Ты уже просто думаешь на языке потоков и корутин. В си так просто не получится. И сам язык внутри для таких задач не предназначен.
Если язык не предназначен, то значит разработчик будет максимально избегать подобных подходов.
Это просто один из примеров. Го мне не нравится, но эта концепция явно хорошая и удобная, думаю будет заимствована языками следующего поколения.
НЕ НУЖНО #PRAGMA-КОСТЫЛЕЙ
@
НУЖЕН ОПЕРАТОР GO
Пиздец ты долбоёб, конечно, земля бетоном
НЕ НУЖНО GOTO-КОСТЫЛЕЙ
@
НУЖНЫ ОПЕРАТОРЫ ЦИКЛОВ
Чел, ты же понимаешь что ты дебс? Другой анон.
>dstrcat(str, list[p->a && !pre_rec? 3 : 2]);
а за такое выебут?
а за такое выебут?
Котаны, мне нужно передать в функцию указатель на буфер с данными типа uint8_t. А в функции я хочу изменить значение этого указателя так, чтобы он изменился и на верхнем уровне. Т.е. я хочу сделать
uint8_t* p_frame = NULL;
func(p_frame);
И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
uint8_t* p_frame = NULL;
func(p_frame);
И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
-вернуть адрес из функции:
uint_t func(uint8_t); //прототип
p_frame=func(p_frame);
-передать указатель на адрес:
func(uint8_t); //прототип
func(&p_frame);
В обоих случаях потребуется изменять декларацию функции. А вот как без изменений - хз.
Спасибо, наверное придется менять на второй вариант
Так себе подход, очень опасный в плане выстрелов в ногу
Сделай либо p_name = func(p_frame); либо
func(p_frame, &p_name);
Скорее всего да, лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?: и непонятно чего ты хочешь
> p_name = func(p_frame)
Я уже возвращаю длину буфера этой же функцией, просто я упростил для примера
> func(p_frame, &p_name);
Мне нужно именно чтобы p_frame принял значение, вычисленное внутри. Больше мне ничего от функции не надо, только адрес буфера в памяти и длина буфера. В лоб можно было бы конечно передавать указатель на длину буфера как аргумент, а возвращать адрес. Я подумаю над этим.
А в чем опасность? Запутаюсь потом на верхнем уровне в указателях?
Верни число обработанных байт и прибавь потом к указателю.
&p передавать не оче хорошо, потому что компилятор свалит p на стек.
>Скорее всего да,
Ну я про такое вот индексирование в духе lea.
>лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?:
Всё что слева от знака вопроса - кондишн.
>и непонятно чего ты хочешь
передать нужный индекс.
>То это говно на списках создает кучу cache miss'ов и прочего говна
нормальный компилятор со статическим анализатором видит, что у тебя список - не список(не нужна динамическая вставка т проч) и переделывает в массив. Плюс, ВНЕЗАПНО, мап может работать и на массивах и вообще на любых коллекциях. Далее, если у тебя на каждый кусок приличное независимое вычисление (вместо последовательности мапов ты сделал мап композиции функциий, кэш мисс твой нивелируется).
>нормальный компилятор ... видит ... переделывает
Эту мантру повторяют со времен Коммон Лиспа. До сих пор компиляторы тупят.
Опять ньюфаги путают Concurrency и Parallelism. Иди кури мат. часть, а потом высирай тонны текста на двачах.
Анон, объясни, почему язык строился вокруг такой ебанутой системы типов? Как можно было додуматься до этого монстра: unsigned long long int, а не стартовать изначально с типов фиксированной длинны (которые и записываются гораздо короче)?
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?
Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?
Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
Найс аутотренинг. А нахуя ты свое /go/вно то здесь пиаришь? У меня и с плюсами процессоры не простаивают, есть корутины и тредпулы. Для Си умельцы скорее всего тоже либ уже налепили.
А чего ты хочешь от переносимого ассемблера? 0 абстракции в случае с си — это же фича, лол.
Так тут как раз и не 0 абстракции. Если бы типы были привязаны к байтам/словам/dword и прочее, то да. Но вместо этого преподносится лажа какая-то с замысловатыми плавающими ограничениями на размер. В итоге это нихрена не переносимый ассемблер. Но одной платформе int один, на другой - иного размера.
Что тебе мешает пользоваться типами из stdint.h, которые тебе гарантируют одинаковый размер переменной на всех платформах?
Ничто не мешает. Вопрос, почему это не по дефолту, а по дефолту какой-то франкенштейн.
По причинам которые ты не знаешь, а администрация языка перед тобой отчитываться не будет. Кем ты себя возомнил, чучело?
Потому что гладиолус.
Почему в Си нет проверки границ массивов, хотя эта операция ничего не стоит по рантайму и дает защиту от глупых ошибок? Потому что такой язык как Си дает тебе МИНИМАЛЬНУЮ абстракцию над голыми инструкциями, которые исполняет процессор. Читай, язык полностью полагается на программиста, ты сам выбираешь способ отстрелить себе ногу к хуям собачьим обрабатывать данные, выбирать типы переменных, работать с памятью и т.п. Минимум ограничений - кредо этих языков.
Тупо? Бесспорно. Но парадокс - на С/С++ (особеноо на С) держится весь мир компьютерных технологий, вся подноготная 98% технологий крутится на этих языках. Это как рак, который пустил метастазы до того, как его успели убить. Теперь хуй убьют, лол.
А может это как скелет на котором всё держится?
Тащемта, да.
>хотя эта операция ничего не стоит по рантайму
Почему не стоит? Одно сравнение же.
Имелось в виду, что при современных мощностях сравнение - ничтожная операция по рантайм футпринту, отсутствие которого может привести к багу, который можно превратить в произвольное исполнение кода. Сам выбирай что важнее, учитывая современное железо.
Ну так-то да. Си - это по сути кроссплатформенный ассемблер, а в языке ассемблера не место большому количеству абстракций (разве что над голыми битами, лол).
>при современных мощностях сравнение - ничтожная операция
И что с чем сравнивать, если у тебя функция принимает указатель неизвестно на который алимент массива?
Если передавать "дескрипторы" вместо указателей, как в Эльбрусах, то это не совсем ничтожные расходы.
Современное железо это компенсирует с лихвой. Сишка нужна в эмбедщине, где жетские ограничения ресурсов - бесспорно. Но в мощнейших махинах это только открывает огромный attack surface.
Хотя альтернатив нет. Мы не живем в мире с розовыми пони, где высирают такое чудо техники, как Раст, и который быренько за 5 лет заменяет все наследние С/С++. Реальность куда более жестока и несправедлива.
С другой стороны, мб это и к лучшему, потому что UB - это весело, хоть и небезопасно. Сама возможность произвольно исполнить код на машине, а тем более удаленной, будоражит меня. И без С/С++ наследия это вряд ли было частью реальности.
быстрофикс
исполнить произвольный код
>Современное железо это компенсирует с лихвой.
Железо ничего никогда не компенсирует, оно просто может выполнить кое-что параллельно за счет большей стоимости разработки и большей потребляемой мощности.
И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов? Офк они не такие быстрые, как они, порой софт, написанный на них, ползет как дерьмо, но порой и нет. И ничего, юзают. В 80ых такое было нереально и засим вся прикладуха писалась на сях. Даже в 90ых годах это было нередкостью, хотя та же безопасная в плане памяти джава с рождения жестко хайпанула. А все из-за тогдашних мощностей. Сейчас это частично нивелируется современным железом, поэтому каждый второй софт на прикладном уровне высран на скриптопараше вроде жса (привет обрыганскому Электрону)
быстрофикс
В STL границы буферов таки чекаются, если делать это через кошерный метод at(), а не через оператор [], что есть сахар над арифметикой указателей без каких-либо проверок.
>И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов?
Они проверяют потому, что (1) в них нет указателей, (2) они и так требуют много накладных расходов (удалены от железа).
Мораль басни была в другом - на прикладном уровне всем похуй на сверхпердольные оптимизации. Почему? Да блять потому, что железо 2к20 года != железо 1987 года. Вот и все. В системщине - да, бесспорно, но системщиной мир компьютерных технологий не ограничивается.
>в них нет указателей
В расте есть указатели, но там это проверяется, и при этом это системный ЯП. И только не заводи пластинку про unsafe, это смешно.
> железо 2к20 года != железо 1987 года
Только ведь и задачи 2020 != задачи 1987.
> всем похуй на сверхпердольные оптимизации
Пиши правильно: мне похуй, потому что я пишу хелловорлды.
Блять, вопрос не про границы массива вообще был. Как использование unsigned long long вместо uint64_t влияет на производительность? Ебом токнулись? Вопрос в том, почему этл мерзкое решение задизайнили по дефолту? Мне просто интересны причины. В чисто исторических целях, так сказать.
>мерзкое решение
Какое именно?
По факту ничем не отличается. По задумке — I'll зависит от платформы, uint64 всегда 64
> Как использование unsigned long long вместо uint64_t влияет на производительность
Именно это - никак. А вот unsigned long может быть 32 или 64 бита, при этом твой код вполне переносим, потому что меньше 32 бит оно быть не может. А вот если напишешь uint64_t, и твой код на 32-битном проце будет тормозить из-за необходимости обеспечивать ненужную тебе по сути 64-битную арифметику путем ебли двух регистров одновременно. На самом деле в stdint есть int_fast типы и int_least типы, вот они норм, и их стоило запилить изначально. А фиксированные нужны, только если ты структуры упакованные в файл пишешь, или у тебя ограничения по памяти.
ull* фикс
Ну вот и вопрос-то, почему так не сделали...
Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Потому что на тот момент, когда это делали, вариантов было меньше. Это сейчас у нас интов дохуя развелось больше, чем в stdint есть, а раньше или long, или short были алиасом для int.
>Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Ну ты же знаешь, что на VAX int = long = 32 бита, а потом придумали long long, чтобы получить 64 бита без конфликта с существующими идентификаторами.
С какими значениями -O, -march и/или -mtune нужно компилировать программу, чтобы бинарники работали на всех среднестатестических убунтах?
march=pentium4, любой -O, -mtune можно задрать куда-нибудь повыше.
А если нужно только для x86_64?
-march=nocona
Я не понял, зачем вам границы массива? Если надо размер, чтобы не пройти итератором за пределы массива, то для вас есть sizeof, если не надо, то с чего бы он был по дефолту? Как программа вообще узнает вышла она за границы массива или не вышла, если она просто читает из памяти подряд? Это типа надо границы массива помечать как-то в памяти что ли? Особой комбинацией нулей и едениц? Как вы вообще себе представляете границы массива в памяти?
> Я не понял, зачем вам границы массива?
На самом деле bounds checking для отладки много где есть. Если писать говнокод или просто на отъебись - очень помогает.
> Как вы вообще себе представляете границы массива в памяти?
fat pointers или таблицы, как для виртуальной памяти в процессорах.
Да, проверка на выход за границу по длине.
> если не надо, то с чего бы он был по дефолту
Наверное потому работа с памятью одна из самых частых ошибок?
>Наверное потому работа с памятью одна из самых частых ошибок?
Си не прощает ошибок в любом случае. Тем более когда ты работаешь напрямую с микроконтроллером.
Да. Поэтому раст и хайпят, потому что он такие ошибки позволяет исключать
Никто его не хайпет кроме отдельных сектантов. Здесь вот один растошизик срет в С и С++ тредах.
> потому что он такие ошибки позволяет исключать
Так и Си позволяет. Но Си еще много чего позволяет там, где в расте нужно писать заклинание на страницу, чтобы его величество компилятор дозволил.
Даладна.
А ещё можно просто код без ошибок писать. Вопрос только в том насколько распространено это юзается.
Да очень многие используют и статический анализ, и санитайзеры, и анальные стандарты типа мисры. Ты по опенсорсу-то не суди.
Почитай что пишут майки о расте.
Я читал, что пишут майки о сервелате, этого достаточно.
Кресты и сишку поменять местами и правдивый мемчик
ну, сишка действительно четче по хардкору поясняет за хромосомное неумение, а не разматывает темплейты на двадцать экранов, но почему хардварный фейл к крестам ближе?
У любого буфера есть размер при его аллокации. При любом доступе к памяти а-ля буффер + оффсет можно проверять туда ли пишут/оттуда ли читают или нет. Дешевая же операция, камон.
Я не растошизик, но мелкософт очень хвалят раст и хотят на него переписывать винду, например. Максимум за 10 лет управятся. А вот Торвальдс ретроград, Линукс доталого будет на сишечке.
Но зато будет забавно, без дыр в памяти мир сер и скучен, есть в этом некая романтика, которую рано или поздно убьет технологический прогресс (надеюсь, когда я уже буду пенсионером)
Ааа, да ты тот второй растошизик который форсит Rust у Microsoft. Ну так вот любые пруфы то мб будут? А я могу тебе прям сейчас ответить: раста не будет. Почему? Потому что им проще расширить компилятор С++ для фикса общих ошибок и спроектировать новый безопасный апи, чем они собственно и занимаются с огромным успехом. Кроме того, ты хоть осознаешь все масштабы операционной системы? А я тебе скажу, 6млн. исходных файлов. Можешь представить сколько там LOC? Я вот не могу.
а может такое быть, чтобы strerror(errno) выдавал неправильный указатель? я просто смотрю в gdb, и там какая-то хуйня.
надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
а не, похоже понял. автотулс не рекомпельнул с новыми флагами
>При любом доступе к памяти а-ля буффер + оффсет можно проверять
Нет, нельзя, производительности придет конец.
>аллокации
Какая еще аллокация, когда с микроконтроллером работаешь?
>автотулс не рекомпельнул
>не рекомпельнул
>авто
Смотри: есть целые числа (инты, например) и дробные (float).
Целые числа всегда делятся нацело, т.е. 100/6=16, а твое 5/1000=0. Дробные числа делятся примерно так же, как в школе, т.е. 100.0f/6=16.666..., ну и для 5f/1000 аналогично.
У тебя в формуле правый множитель будет равен -1 (сам сообразишь почему).
Как избавиться? Внутри формулы юзай флоаты или даблы (в зависимости от требуемой точности), а потом кастуй к своему инту.
Как белые люди пишут кроссплатформенную дин.библиотеку?
Пускай есть некоторый сишный код, который нужно скомпилить и тягать как .so в никсах или как .dll в винде. С никсами все понятно - берешь gcc и компилишь. Слышал по mingw и cygwin, но это костыль костыля, как мне кажется. Как компилять либу на винде?
Пускай есть некоторый сишный код, который нужно скомпилить и тягать как .so в никсах или как .dll в винде. С никсами все понятно - берешь gcc и компилишь. Слышал по mingw и cygwin, но это костыль костыля, как мне кажется. Как компилять либу на винде?
Mingw вполне себе юзабелен, из CI собирать всю хуйню под wine - одно удовольствие.
Когда все проверяется в черном ящике каждый раз без исключения - эта а приори не оптимизированный код. segment-naebnulsa-safe контейнер - не экстрасенс какой-то, чтоб проанализировать вызывающий алгоритм на инвариативность условия, что индекс меньше размера, стало быть говно.
Да и хули толку, что рантайм ошибки не будет, если алгоритм все равно по факту обосрался с индексацией и задачу не выполнил? Все равно руками проверять, раз на то пошло.
Есть тяжелые структуры данных, вся жизнь которых сводится к хождению по индексам на индексы через индексы, и если всрать в реализацию безопасные массивы, время основных операций в такой системе вырастет не на какую-то там
>дешевая же операция, камон
а пропорционально, то есть в разы
Привет. Чарльз Петцольд в своей книге утверждает, что количество адресуемой памяти влияет на скорость процессора аргументируя тем что на пике. Читаю и не пойму что он имел в виду. Может кто шарит? Тред ассемблерщиков пустует, там решил не спрашивать.
Он там сравнивает 16 и 32-бит режимы?
Дай больше контекста.
шиза какая-то
Я не имел в виду только аллокацию памяти на куче, в мире микроконтроллеров это, в большинстве своем, непозволительная роскошь, ибо ресурсов маловато даже для обрыганского аллокатора памяти и менеджера кучи.
Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
Произошла аллокация статического 16-ти байтового буфера на стэке.
>>Нет, нельзя, производительности придет конец.
Как тогда раст позиционируется как системный яп и проникает потихоньку в эмбеддед? У него ведь не только тяжелый статический анализатор кода, а еще и рантайм проверки (в случае с МК могут быть нерелевантны, ибо там, как правило, не имеют дело с кучей)
>>Ну так вот любые пруфы то мб будут?
https://www.youtube.com/watch?v=NQBVUjdkLAA
>Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
ав-та-ма-ти-чис-ка-я
повтори
Скорее всего у него там обосновано почему.
Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
Из каких-то таких соображений и появляются ограничения на поддержку памяти компьютерами. Вроде бы у тебя безграничная 64-х битная память, но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами. Во многие серверные платы ты тоже сколько угодно не вставишь.
В общем там недостаточно просто уметь адресовать.
> но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами
Совершенно не по этой причине, не из-за быстродействия. Просто чем больше бит, тем больше площадь адресной шины, а место на кристалле дорогое. К тому же разводить широкую шину сложнее. Поэтому адрес 64 бита, а реально бит в адресной шине меньше.
>Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
>
Бля, чем ей "сложнее управлять"? у тебя кэшлайны такие же, развелось дебилов. менеджеры памяти тоже нормальнве люди пишут, и количество имеющейся памяти не влияет на скорость элементарных операций.
Есть инфа, зачем в сетевой библиотеке функции, переводящие endianness, представлены парами htonl/ntohl и htons/ntohs? Разве это не операция с четным периодом, как xor?
Аноны, а у вас свои набитые опытом либы имеются? Или в случае Си это бессмысленно?
И что за хуйню ты принес? Какой-то Васян смузихлеб сидит и рассуждает без пруфов.
Это сотрудник мелкософтов, алло.
В интернете тоже дохуя статей по теме.
А в чем, собственно, проблема, что не так? Мир продолжает развиваться. В 60ых тоже сказал бы кому-то, что фортран/кобол будут потом мало кому нужны и фактически помрут - покрутили бы пальцем у виска. В итоге появился Си и спустил всем в рот, спихнув минимум 3 языка с трона. Сейчас следующее поколение готово выйти на замену - Раст. Что не так?
>Это сотрудник мелкософтов, алло.
Толку-то, борщехлеб может фантазировать сколько угодно, а на работе будет писать на плюсах и шарпе как все.
>Сейчас следующее поколение готово выйти на замену - Раст. Что не так?
Слышу такое уже лет 20, с тех пор как начал заниматься программированием
>общаться в си треде где 90% постеров это ебанаты студентишки и бывшие трактористы из юнитфактори не написавшие в своей жизни ни строчки кода отличного от linkedlisttutorial.c по туториалу, для которых авторитет это не имя и опыт за ним, а кто за скока вкатился
кринж
кринж
Маня, человек хотя бы год проработавший в индустрии никогда не будет использовать такой кринжовый бордосленг как "борще/смузи -хлеб", сходи пиров своих проэвалюэйти в юнитфактори
>Слышу такое уже лет 20, с тех пор как начал заниматься программированием
Дк новых системных ЯПов за последние лет 20 как раз-таки и не было. Долбоебы кукарекали про смерть Сишки после появления джавы (тупизм), но джава изначально была ЯПом абсолютно другого класса. Но Раст - первый системный язык за последние дохуя лет и он вносит много новых технологических аспектов, не имея богомерзкий сборщик мусора и, главное, безопасный по памяти (если не в ансейф блоке), да и к тому же thread-safe и не позволяет дата рейсам случаться. Все баги не элиминировать никаким языком, но весь класс ошибок работы с памятью идет нахуй с такими йоба-технологиями, а это самые опасные дыры, так как ошибка работы с памятью почти всегда == исполнение произвольного кода, что есть катастрофа. Миру давно не хватало языка, который может и рыбку съесть (упороться в безопасность), и на хуй сесть (не имея при этом сборщик мусора, имея скорость плюсов).
А по существу-то нечего ответить ;) Слив засчитан!
Полоумная маня из школы 21, проснись, блядь, ты серишь. Нахуя ты вообще свое мнение здесь расписываешь? Всем очевидно (кроме этого другого ебаната) что ты ни дня в жизни с реальным продуктом не работал
Хочу вкатиться в Natural Language Processing, Data Visualisation и всякий статический анализ. Для себя, для будущего диплома. Знаю, придется переписывать половину pandas на Си и творить ебанутые вещи.
Хочу выучить C11. Есть время для этого хобби, два года, есть мрачная решимость не подходить ко гвидопыху даже с десятифутовым копьем.
Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Я, конечно, добаеб и земля мне пухом, но если анонс подскажет полезных библиотек/книжек, буду рад.
Ну, тащемта, это даже не ты ебанат, а эта тема вообще не имеет никакого развития, даже вкат в NLP И так далее сомнителен. Вкат в визулизацию — это вообще кекус, там задачи — написать скрипт чтобы разобрать массив данных, причём в большинстве случаев это разовая акция на порисерчить.
>C11
Чел, во-первых это не плюсы, и 11 от 99 отличаются на 1,5 фичи в языке и 3 новых хидера в стдлибе, а во вторых С11 не то, чтобы что то нужное и везде используется в лучшем случае 99.
> Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Тащемта даже хачкель для анализа данных подходит лучше, на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область (которая вообще не то, чтобы сидьно про программирование, оно там вообще вторично).
А про ненависть к ооп — а что для тебя вообще ооп?
Приветствую братьев-сишников, желаю приятного кодинга.
Я тебе уже объяснил почему раста не будет, потому что у них уже налаженная процедура: расширенные компиляторы, многоступенчатое тестирование и секьюрный дизайн. Переписывать миллиарды строк кода никто не будет, а вот мигрировать на новый апи/компиль запросто.
> безопасный по памяти (если не в ансейф блоке)
А теперь представь свое ебало, когда узнаешь, что не хилый такой процент ОС без ансейфа ты тупо не напишешь, потому что бороучекер задрочен на твой васянский хеллуворлд, а не ос-дев.
> а и к тому же thread-safe и не позволяет дата рейсам случаться
Тоже самое. Это работает только для приложений пользовательского режима.
Другое дело, что у майкрософт уже есть кастомный компиль, который по-тихоньку убивает весь класс ошибок с памятью.
дiдько, таки обiсрався на скрiншотi
> нет подсветки
> хаки
> константы Ls Cd не капсом
> не проверяется возвращаемое значение write
Гораздо хуже "while (ent = readdir"
вместо "while ((ent = readdir"
Анончегу пох на предупреждения или он их отключил.
. спецом, шоб писать охуительно качественный человекочитаемый код хоть под распечатку на чб принтере
. на то и есть домашние проекты, чтоб доверять самому себе и не обмазываться бест практиками
. в чем космический смысл писать константы КАПСОМ, если можно просто с Капса?
. write писал еще когда nlSendStr не было, ща оберну
Спасибо за мнение.
>на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область
Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
>А про ненависть к ооп — а что для тебя вообще ооп?
ООП для меня просто школьная травма.
Бесконечные классы за гранью нормального, всякие get/set, и -1 балл на контрольной за printf вместо cout с охуительным объяснением "ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно". Пять лет прошло, а я злой как собака как вспомню.
>, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Это и есть та самая меморимодел?
>ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно
Что за шиза?
>Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Ты же понимаешь, что это _абсолютно_ write-only подход, который практически невозможно поддерживать и развивать? Ты же сам 2 месяца не разберёшься в коде без полного погружения в это. Это даже хуже типичного говнокода от датасатанистов.
>всякие get/set
А при чём тут ООП-то? Когда тебе понадобится присобачить минимальную логику, начиная от отладочной информации или просто ассертов просто ради приблежиния к уровню self documenting code, и заканчивая серьёзными изменениями (например, строка превратилась в бинарный формат, который надо печатать форматированно), то ты и на ассемблере всё на гет/сет все публичные интерфейсы перепишешь, лол.
>ООП для меня просто школьная травма.
Таки да, всё нормально, порефакторишь то же, что сам понаписал и начнёшь спокойно юзать ооп, реальных производственных травм у тебя нет.
Со стороны нормального программного дизайна это как раз таки нормальное замечание. На уровне лабы3 конечно похуй, но с практической стороны лучше иметь возможность тюнить даже такой функционал не меняя саму логику программы.
inb4: Ух, чую как злая шкила меня сейчас говном закидает, лол.
>Ты же сам
через
Я не он, но ООП реально говно.
> Со стороны нормального программного дизайна
Со стороны программного дизайна потоки в C++ - это полный пиздец, ничего хуже еще не придумывали.
А что такое ООП, чел? В С вот реализация инкапсулируется от интерфейса с помощью хидеров, инкапсуляция — 1 из 3 принципов ООП, С — ООП язык на 1/3?
Я же и не говорил обратного, но это хоть какая-то инкапсуляция. Ебашь на здоровье массивы байтов напрямую, кто же запрещает-то. Просто через пару лет догонишь что это хуйня а не подход.
> С — ООП язык на 1/3?
ООП-язык - это язык с сахарком. В си сахарка нет. Вот в ObjC например есть.
Ну смотри, есть C++ а есть Obj-C. И там и там есть "сахарок", только реализует он всё примерно диаметрально противоположно. Кто из них ООП?
ООП — это, блядь, концепция. Ясен хуй, что никому не нравятся всякие там паттерны итд, но паттерны — это костыли для конкретного языка, а не ООП. ООП — это 3 ебучих принципа, ничего лучше которых никто не придумал (разве что про наследование можно поспорить).
> ООП — это 3 ебучих принципа
Нет. Только один: объекты обмениваются сообщениями. И он нихуя не применим на практике без проблем с производительностью. Поэтому ООП-ом каждый называет какие-то свои фантазии. Ну или то, что в вузике вдолбили.
>Со стороны нормального программного дизайна это как раз таки нормальное замечание.
Со стороны нормального дизайна использовать сиаут для форматирования строки это пиздец.
>А что такое ООП, чел
Это когда оперируешь объектами классов их иерархией. И все это говно сильно зависит от контекста, плюс поддерживание инкапсуляции, один васян решил скрыть доступ, а второй городит огород чтобы нормально считать значение переменной или избавится от оверхеда проверки значения. Короче оч на любителя, как разведенки с прицепами. Но Qt для мордочек юзаю, да. Философия Перл/С здесь ближе, написал в документашке не лезь и все этого достаточно.
>Нет. Только один: объекты обмениваются сообщениями.
В понимании примерно всего коммьюнити — 3, и почти весь софт на планете пишется с их применением, поэтому Алан Кей идёт нахуй.
Даже в Objective-C завезли __attribute__((objc_direct)) что как бы намекает, что этот подход мертв.
Читать умеешь?
>Я же и не говорил обратного
А аналоги-то какие? Как в новомодных фп архитектурах просто использовать композицию вместо наследования и копипастить код из редюсера в редюсер стейта и создавать заново весь стейт (а лучше и контекст) при каджом изменении а потом гнать по скомпозированному дереву функций?
>А аналоги-то какие?
Слать на хуй ООП парадигму. Ну может комуто нравится когда в одной либе петух это класс птиц, а в другой динозавров.
>В си сахарка нет.
*(a+3)
a[3]
Мне в ООП нравится только инкапсуляция. Сам я пишу драйвера и системы управления железками разными, и вот именно это я всегда использую в си.
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.
Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.
Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
>Мне в ООП нравится только инкапсуляция
Чего именно?
Ну круто же, строка сама знает, как себя форматировать.
Ага, если учитывать все кодировки и системы письма, то твой класс улетит в ебеня. Но обычно получается ни то ни се и все работают с байтовым буфером по своим потребностям.
Инициализации железа. Вся работа с ногами и регистрами отдельно, логика системы отдельно.
Кстати, вот иллюстрация убогости С: надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s, программа упаде.
Просто делаешь строки sprintfом
Когда познакомился с плисами, а также Верилогом и прочими hdl, понял, что ООП это всего-навсего железки в коде.
> надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s
То компилятор скажет, что ты ошибся. Да, это работает только для printf-like функций, а если у тебя свой собственный формат спецификаторов или вообще его нет, тогда тебе никто не поможет.
Как заставить gcc проверять количество и тип аргументов вызываемой функции?
Т.е. я объявляю прототип типа
void func(int a, int b);
И если в коде по ошибке вызываю так
funс(1, 2 , 3);
то компиль молчит как партизан
"-Wall" не помогает
Т.е. я объявляю прототип типа
void func(int a, int b);
И если в коде по ошибке вызываю так
funс(1, 2 , 3);
то компиль молчит как партизан
"-Wall" не помогает
Компилятор не увидел прототип?
А если выводить через puts?
Какое же сложное это ваше программирование. Вот хочу смочь в С - а где мне компилировать? Ставить себе линух или на виртуальную машину и использовать gnu? Или тупо в вижуал студио на виндоусе для начала сойдет? Для чего нужно ставить clang и что это вообще такое?
Вижуал студио сказал что не хочет работать без обновления,
а чтобы обновиться нужно залогиниться в учетку майкрософт, от которой я забыл пароль. Сбросил пароль - ввожу и тут он мне говорит что это старый пароль, хотя он не подходил. Видимо я уже менял пароль, и это старый старый пароль и он почему-то больше не подходит им. Вот нахуя программисты майкрософт создают такую еблю для пользователя?
что тебе делать, тебе тут говорить не должны; линукс - рай для творческого программирования
си компилирует gcc, который всегда во всех дистрах в репах; редачить можно в обвязке, а многие используют обычные редакторы с подсветкой
>Вот нахуя программисты майкрософт создают такую еблю для пользователя?
> Почему буквальный EvilCorp мне плохое зло зделол?
>Или тупо в вижуал студио на виндоусе для начала сойдет?
На форточках я бы посоветовал использовать Code::Blocks + MinGW. Со студией хоть и проще начать работать, но в сравнении с CB её функционал для новичка является overkill, поэтому освоить её сложнее.
А вообще, учить человека программированию начиная с C - издевательство, так можно его превратить в Си-дебила. Типичный Си-дебил ничего, кроме императивных языков с Си-подобным синтаксисом освоить практически неспособен.
> Code::Blocks + MinGW
двачирую, и весит мало и бесплатная.
а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
лол. в рот ебал эти эко-коко-системы.
есть ли какие-то форумы/движения/репозитории, которые продвигают идею что комп должен быть ВСЕЯДНЫМ ?
(без крайностей)
Забыл добавить, что func объявлена в func.h файле и реализована в func.c файле. При этом главный файл не содержит
include "func.h", т.е. в теории функции вообще не должно быть видно.
Тем не менее компиль компилит, а линкер линкует.
>Ставить себе линух?
Попробуй. Еще захочешь, базарю. На самом деле не нужно, используй удобную для себя систему.
>Или тупо в вижуал студио на виндоусе для начала сойдет?
Сойдет и для продолжения. Хотя лично я предпочитаю Clion, но на винде он обычно поверх студии ставится, лол. Не спрашивай.
>Для чего нужно ставить clang?
С - компилируемый язык, так что для превращения твоих буквочек в программу нужен компилятор.
Дефолтный выбор для винды - msvc(visual studio сама его поставит), для линуксов\макоси - gcc.
Clang - это тоже компилятор, можно поставить в качестве альтернативы тем что выше и все будт заебца.
>что это вообще такое?
Не стоит вскрывать эту тему, но вы все равно будете спрашивать..
Clang - часть проекта llvm.org
Если коротко, то clang отвечает за фронтенд компилятора, за счет опен-соусности и хорошего api эту хуеверть используют в разных IDE для подсветочки кода, функций рефакторинга, пиздатых сообщений об ошибках и прочих кодоанализов. В связке с llvm превращается в черную магию, способную работать с кодом на любом этапе компиляции, сожрать твой разум, сделать новый язык программирования или даже перевести код с одного языка на другой, попутно забрав твою душу.
Ты был предубежден.
мимо-крестодебич, зашел в тред случайно.
>а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
Это субъективно, но не стану спорить.
Как минимум какой-нибудь Scheme или Standard ML очень в тему, если приспичило углубиться в Computer Science. У редкого адепта K&R не выносят мозг рекурсивные алгоритмы, обычно используемые в ФП (бинарные деревья из книги они осилили с горем пополам).
Да я не совсем нулевой, в университете вроде бы сдал курс программирования, и даже численные методы на паскале на самом деле не помню чё там было, вроде C++, было похуй сдал и забыл так что сейчас думаю научиться хоть чему-то полезному, не важно какой синтаксис учить сначала мне кажется. Я не из тех кабанчиков которые через 1 месяц хотят устраиваться погромистами.
Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
>На форточках я бы посоветовал использовать Code::Blocks + MinGW
>MinGW
Может лучше wsl или уже линукс?
>Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду?
Тебе как обычному посону достаточно нажать кнопочку compile в ide или как ты там предпочитаешь.
Всю еблю и танцы с разными железками, преобразованием говнокода чтоб анубыстроблядь работало и прочие заботы берет на себя компилятор(тот же clang).
В 99% случаев думать о том что там под капотом происходит вообще не надо.
>что там под капотом происходит вообще не надо.
Уходите в питухон/мл трхед
>жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Можешь попробовать Code block портабельную сборку, на сайте у какогото инфоцыгана что ли видел, тредов 20 назад про неё спрашивал обосрали конечно но работает только вроде пути к компиляторам если не в С копируешь вручную надо поменять.
Откуда этот миф про первый язык?
Если айсикью недостает какой язык не дай человек на нём и застагнирует.
Как раз си, и Книга Кернигана и Ритчи идеальны для вкатывания в проргаммирование вообще. Там же все с самых азов. Еще лучше если купить отладочную плату при этом.
Блять, легче тогда devcpp поставить и не ебаться, для новичка топ - нет подсветки, простой в установке и идёт в комплекте с компилятором
В си есть указатели с ними проще списки понять. Какая то абстракция есть, другие всё стремятся "очеловечить" что ли Си как математика.
Как один из концов. Пацанское рвение прошариться в ламповом низкоуровневом коддинге утроит общую продуктивность занятий, даже если "КПД" не очень. А так, SICP правильнее.
ЛЕГЧЕ было бы просто новый аккаунт в макйрософте зарегистрировать и какать в визуальную студию, но нужно же блджад в пр в мертвый тред насрать
>аккаунт в макйрософте зарегистрировать
Зашквар же.
так двач тоже зашквар, значит для него это не проблема
Расположение битовых полей в памяти.
Имеется некий пакет передачи, который нужно заполнить в правильной последовательности, например:
5 битов - адрес
3 бита - номер функции
10 битов - данные
7 битов - контрольная сумма
Ну и решил для удобства всё это сделать структурой с битовыми полями. На байтах всё выходило как надо(потому что биты в байтах, переменных и элементы в массиве всегда размещаются одним и тем же образом). Но когда я стал тоже делать битовыми полями, всё вышло через жопу. Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
пили свой препроцессор, который использование таких структур переведет в соответствующие голые операции
> Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Какой опытный путь, гуглить ты не пробовал?
В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
> Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Да. Ни обычные структуры, ни структуры с битфилдами нельзя отправлять через сеть в сыром виде, их можно только писать в файл, если этот файл будет прочитан той же программой на той же платформе. Для обмена данными надо писать (де)сериализатор, который возьмет байтики (или битики) из принятого буфера, распарсит их и запишет в поля структуры: myshit.smth = read_uint(&src); myshit.some_bitfield = bitstream_read(&bs, 5), ну типа того.
Да, многие пренебрегают этим, надеясь на то, что big endian их не коснется, и что исключения у флоатов выключены, и что что выраванивания у членов структуры и буфера с полученными данными правильные, и что -fms-bitfields их спасет. Но лучше не стоит.
ПРОСТО ИСПОЛЬЗУЙ ЛОГИЧСКИЕ ОПЕРАЦИИ
Битовые поля хуёво стандартизированы. Поэтому лучше воздержаться от их использования.
>Битовые поля хуёво стандартизированы.
Они стандартизированы, просто каждый компилятор располагает их по разному в памяти.
>Поэтому лучше воздержаться от их использования.
Не все так однозначно.
Если ты работаешь с битовыми полями только в программе, то их можно использовать, они намного удобнее.
А если собираешься куда-то пересылать, то лучше тогда биты распределять в пакете передачи вручную с помощью битовых операций.
Тот же MISRA C не запрещает битовые поля, хотя как бы этот стандарт во всем придерживается, чтобы код не зависил от компилятора.
>Какой опытный путь
Изменял биты в полученном пакете передачи, а потом на бумажке отмечал, где находится то или иное битовое поле.
>, гуглить ты не пробовал?
Потом, когда увидел такое говно, загуглил, оказалось, что расположение битовых полей в памяти отличается от компилятора к компилятору.
>В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
Да это я знаю, порядок байтов в массивах и структурах всегда одинаков - элементы в начале структуры/массива имеют младшие адреса. А биты в байте располагаются от старшего к младшему.
Речь про битовые поля, а они могут быть не кратны байту, и как расположит компилятор их в структуре это всегда загадка.
Блин, а это говно:
>- Brian Kernighan, Dennis Ritchie "The C Programming Language":
разве обязательно читать?
Просто я прочёл справочник Шильдта(и иногда заглядываю в его при работе) и мне этого с головой хватает для проганья, не вижу смысла что-то ещё читать дополнительно.
>> define
>Это единственный в Си нормальный способ объявления констант
А теперь объясни, чем константы отличаются от дефайнов...
> чем константы отличаются от дефайнов
Пиши в файле:
const int nelem = 42;
int array[nelem];
И компилируй. Алсо, const не гарантирует, что переменная nelem не будет читаться там, где ее можно было оптимизировать до immediate-операнда в инструкции.
Тем, что дефайн - это find & replace ДО начала компиляции. При абузе дефайнов ты охуеешь дебажить это говно, так как переменной как таковой нет, до процесса компиляции просто идет замена x на y, если макрос: #define x y
А константа - переменная, под которую выделяется место в read-only сегменте памяти. И при дебаге, в отличие от дефайнов, у тебя будет не много веселых магических чисел, а переменная с конкретным адресом в памяти.
Не хочешь оптимизаций от компилятора для конкретной переменной - юзай ключевое слово volatile в таких случаях.
Код решения:
http://www.learntosolveit.com/cprogramming/Ex_1.8_count_blanks_etc.html
Мой код:
https://ideone.com/9nfk4I
Почему первый вариант работает как надо а мой не считает нихуя?
http://www.learntosolveit.com/cprogramming/Ex_1.8_count_blanks_etc.html
Мой код:
https://ideone.com/9nfk4I
Почему первый вариант работает как надо а мой не считает нихуя?
Загнал палучается в студию и понял что проблема в двойных кавычках хех мдаа понимаю.
Сяч, я передаю указатель на char вот с таким кастом:
> func((const char zvezda) buf)
это означает, что он продублируется в ридонли дейта регион? он же не может в соответствующую секцию в бинаре прописаться?
> func((const char zvezda) buf)
это означает, что он продублируется в ридонли дейта регион? он же не может в соответствующую секцию в бинаре прописаться?
Господа, я горю нужен совет бывалых.
Надо передать фрейм через веб-сокет.
Бяда в том, что передающая функция принимает структуру вида пик1, а ws-клиент на другом конце ждёт объект JSON.
Как мне в Си сеариализовать в JSON объект? Либа - cJSON.
Надо отправить что-то вроде ({"isStagotip":"true"})
Надо передать фрейм через веб-сокет.
Бяда в том, что передающая функция принимает структуру вида пик1, а ws-клиент на другом конце ждёт объект JSON.
Как мне в Си сеариализовать в JSON объект? Либа - cJSON.
Надо отправить что-то вроде ({"isStagotip":"true"})
Он пишет про процессорный кеш. В его лучшие года он был 8-16 килобайт, сейчас он даже в 10 поколении топ L1 512кб L2 18 L3 24.75 мб соответственно. Очевидно что процессор при считывании чего-то большого в памяти будет прогонять часть через L1 разбивая на кусочки меньше 512 килобайт. А это в свою очередь отдельные. Очевидно что в таком случае 4 гига прогнать проще и быстрее чем 128 гигов.
Но это лишь моё предположение, надо смотреть в каком контексте он это говорил.
Нихуя не понятно, о чем ты спрашиваешь, но каст ничего никуда не копирует.
Спасибо, но не то.
uint8_t buf[128] = { 0 };
httpd_ws_frame_t ws_pkt;
ws_pkt.payload = buf;
Как скастовать \ передрать объект JSON в буфер buf, который имеет тип uint8_t?
Пока Сишники рофлят над растом, он потихоньку пробирается в Линукс, лол
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
>Растошизик пытается форсить мертвый язык
почему мертвый?
мимоанон, не понимающий происходящей шумихи вокруг ржавого, который начинают хайпить компании вроде мозиллы и майков
>ридонли дейта регион
Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё. Вообще, нахуя тебе явный каст? Конверсия указателя в указатель на константу происходит неявно и вообще абсолютно легальна (то, что функция принимает указатель на константу, обычно означает, что она не будет менять передаваемые таким образом данные). Система типов в си - достаточно мудра и держит тебя в узде.
растошизик незаметен
Куча детских болезней.
Есть профит по сравнению с каким-нибудь JS, Java, Kotlin или PHP. Когда речь заходит о сравнениис C - все профиты пропадают.
В основном растошизики орут что раст круче при работе с памятью и что сложнее выстрелить себе в ногу при этом умалчивая факт того что это профиты перед стандартом C 1997 года!
Help.
Попробовал вот так: https://pastebin.com/08anHKqu
Но memcpy не корректно скопировало массивы.
_Server: Got packet with message: "isStagotip" // запрос от клиента
_Server: Packet type: 1
{
"isStagotip": "false" // содержимое *json
}
_Server: Buf: {isStagotip" // результат работы memcpy c массивом buf
:(
countof ---> strlen + 1
вот этот шарит
Это у него просто отладчика нет. Если исходники есть - можно source-level отладкой пользоваться, если нет - код обычно оптимизированный, и никаких отдельных переменных под const там уже нет.
>что const записывается в "read only" память. Нету такого говна, нету.
Ну вообще в микропердолинге, например, приблизительно так и происходит. Всё зависит от платформы и компилятора.
А что сейчас поменялось? Сишка так и продолжает невозбранно срать в память, ub на ub и ub погоняет. В крестахс этим проще, там контейнеры и умные указатели, этот язык на 90% избавился от проблем 80ых, в отличие от Сишки.
А в расте так вообще срать в память можно только в ансейф блоках, и то со своими нюансами. При этом пристальное внимание при тестах можно сосредоточить именно там и поэтому вероятность критических багов в целом снижается чуть ли не к 0.
>Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету.
.section .rodata
Сразу видно смузихлеба, который пишет на своем языке хеллоу ворлды, а не нормальные проекты. Раст не защищает от утечек, он предоставляет RAII.
http://huonw.github.io/blog/2016/04/memory-leaks-are-memory-safe/
https://doc.rust-lang.org/nomicon/leaking.html
Я вообще мимо другой анон. Моя единственная претензия к расту это раздутость. У меня один проект занимает что то около 1.3 Гб (target) и еще 400 метров rls-овских файлов, ну и небольшое примечание: это хеллоу ворлд, для отрисовки одного единственного треугольника с градиентом. Как я понимаю это все скомпилированные зависимости, то есть дальше размер проекта будет расти только от моих собственных файлов. Но если я захочу сделать еще один проект, который рисует квадраты, то у меня будет два проекта по ~1.7 Гб, и так далее....
Ага, только вот утечка памяти сама по себе не эксплуатабельна. Ты не можешь дойти до состояния исполнения произвольного кода имея лишь мемори лик, в отличие от переполнений и мисменеджмента работы с указателями, что раст элиминирует накорню (не считая ансейф, но я уже высказался по этому поводу).
Да, attack surface меньше, тем не менее, раст не такой идеальный каким его многие описывают. Мне кажется, если не было фанатичной рекламы раста из всех щелей, то не было бы хейта в сторону раста и относились бы к нему спокойнее. Ну а так, мне кажется, что уже стоит начинать изучать раст, тем кто хочет в системщину, не обязательно писать, но уже даже мелкомягкие и мейнтейнеры линукса уже начинают работать с растом. Хотя, кмк, сишка все также незаменима на микроконтроллерах и embedded.
Скопировало, спасибо.
Вот только теперь на стороне клиента ругается: Unexpected end of JSON input at JSON.parse (<anonymous>)
Что-то не нравится в сформированной строке.
Небольшое дополнение.
Есть функция вывода JSON объекта без форматирования - cJSON_PrintUnformatted.
_Server: Got packet with message: "isStagotip"
_Server: Packet type: 1
{"isStagotip":"false"} // сформировано
_Server: Buf: {"isStagotip":"false"} // отправлено
Но ошибка та же - неожиданный конец JSON сообщения.
Не пойму пока, что не нравится парсеру.
Жисон сообщение чем-то оканчивается?
На сишной стороне подобный пакет был без труда распарсен:
{"ssid":"test_ssid","pwd":"test_pwd"}
ws_pkt.len = strlen(...) делаешь?
Да, дело было в этом параметре.
Спасибо. Пойду дальше биться об стену.
Вот няша.
>.section .rodata
чувак спрашивал, про касты указателей в указатели на константы, ты пишешь что-то ОЧЕНЬ implementation defined, и то, что в данном случае не имеет вообще никакого отношения к сути вопроса.
>А что сейчас поменялось?
Язык обновили, баги исправили. Ты же тоже не пишешь на первой версии раста. Вот и C скакнул вперёд. А вы со своими спорами напоминаете мне кукареки смузихлёбов против PHP, вроде и дельная критика, а на деле выясняется что относится она к первым детским стандартам, а на том языке к которому критика относится уже никто не пишет много лет. В итоге слышу звон, да не знаю где он.
Ну тут никаких утечек памяти ненужно. 1,3 гига - видимо предполагает что она уже везде где только можно протекла.
>Как я понимаю это все скомпилированные зависимости
У раста нет нормального компилятора который берёт только то что используется кодом? Такая штука даже в делфях была, даже в паскале. Мол используешь мат функцию дискриминанта, в своём коде. Вот эти 16 строк и берёшь. В итоге даже жирные проекты не превышали 1.2 мегабайта. Неужели это какие-то забытые техники? Или там какое-то другое устройство бинарников?
>Неужели это какие-то забытые техники?
В общем да
Никогда не забывайте, что intN_t из stdint.h -- это optional типы данных. В некот. реализациях они могут НЕ поддерживаться.
И в каких они не поддерживаются?
Очевидные сборки С99 под микруху
>Ну вообще в микропердолинге, например, приблизительно так и происходит. Всё зависит от платформы и компилятора.
В микропердолинге приходится нестандартными макросами и прагмами пояснять в какой именно флеш ты хочешь чтобы была переменная.
Иди кури мат. часть. Константные данные записываются в .rdata (read-only data). Так уже лет 10, если не больше.
Чем инициализация переменной через #define отличается от инициализации с const?
> инициализация переменной через #define
Слишком жирно и уже было, заходи в другой раз.
Нет, братан, это ты иди кури матчасть.
Пикрил:
константная целочисленная переменная sosatb, равная числу 1337, находится по адресу 0x7fffffffdf7c. При инспектировании адреса видно:
а) Этот адрес лежит в пределах лэйаута стэка - команда vmmap stack дает ренж адресов стэка, как видишь, адрес константной переменной лежит в этом ренже.
б) При обращении по адресу 0x7fffffffdf7c, видно значение 0x539 на стэке, что равно 1337 в десятичной системе исчисления.
Вывод - константная переменная находится непосредственно на стэке (нет никакого указателя на .rodata сегмент, как видишь), засим семантика языка С хэндлит такие ситуации, но никак не перемещение константных переменных в .rodata
Если тебе интересно что хранится в .rodata, могу дать пример - строковые литералы. То бишь, условный char* literal = "yayayoyo"; улетает в .rodata
На будущее, советую проверять подобные утверждения в отладчике, дабы не вводить в заблуждение маслят. Бобра!
Вперед меня успел посадить чела в лужу
#define это по сути find & replace
До начала компиляции при условном макросе #define a b все а в текущем файле заменяются на b, ДО начала компиляции. Это не является переменной, скорее как магическое число (именно поэтому абьюз дефайнов превращает отладку в ад).
В случае с const, все происходит не ДО начала компиляции, а непосредственно ВО ВРЕМЯ компиляции, под переменную выделяется память, соответственно, у нее есть адрес.
Понял, спасибо.
>Это не является переменной, скорее как магическое число
Текстовый макрос. Какое еще число, наркоман.
Как перестать тестировать вложенные циклы "на лету" и начать жить? Не могу в голове построить как оно будет работать, приходится шажками допиливать условия. Больше практики?
>Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё.
Для полной ясности. Глобальные константы
char yoba[] = "yoba";
const float pi = 4;
будут размещены компилятором/компоновщиком в секции ro data, если таковая поддерживается.
Эта секция при исполнении помещается/отобращается в память read only, при наличии поддержки в ядре.
Ты не знаешь что такое magic values?
#define MACRO 1337
...
int var = MACRO;
MACRO просто заменяется на 1337 во всех местах в текущем файле. Если макрос привязан к числу, то MACRO - магическое число без адреса в памяти, так как не является переменной. В чем проблема?
>char yoba[] = "yoba";
Это не константа, это обычная строка, не литерал. И если эта строка вне стэкового фрейма какой-либо из функций (то бишь глобальная), то такая строка улетит в .data сегмент, куда можно, разумеется, писать. Литерал же в любом случае улетает в .rodata, неважно глобальный он или же находится в стэковом фрейме одной из функций, которая его объявила.
>const float pi = 4;
Да, тут ты прав. Если эта константа глобальная, она улетит в .rodata. Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент, так как она не там в таком случае.
> это обычная строка
> С
> обычная строка
> С
Ясно понятно всё с твоей компетенцией.
Вы заебали выдавать детали реализации за истину.
> Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент
Все зависит от компилятора, от флагов оптимизации, а в случае с float еще и от использования fpu или sse для плавающей точки. Алсо, .rodata - это линуксы. В винде оно может улететь в конец .text, в .rdata, да и в .data даже с какими-то компиляторами. В каком-нибудь ARM-коде оно может лежать в виде литерала прямо после функции, а функция, естественно, в .text.
>пук среньк
найс обосрался, анон
В моей компетенции можешь не сомневаться, а доебываться до слов - признак слабого ума и отсутствия контраргументаций
указывают на ошибку
@
ряяяяяя не доёбывайтесь до слов
Умный человек, которым ты не являешься, в случае ошибки признаёт ошибку и просит прощения за ошибку.
Обосрался ты, маня, ведь в данном случае данные (инт) лежит в .text секции кода и уже после подгружается в стек. И так всегда было. Не до конца ты вкурил видимо, ну ничего, заглядывай к нам в асм тред, научим тебя.
Непонятно, для каких конкретных жизненных задач может понадобиться непременно СПИСОК ВСЕХ UB БЕЗ РЕГИСТРАЦИИ И SMS. Сдается мне, у тебя какой-то реферат, сам смысл которого в том, чтоб ты, как раз таки, сам выколупывал крупицы знаний, и ты пришел с этим на двач. Аноны?
Блок схема или расписывать на листочке как деление столбиком, не волнуйся это не овощной вариант, вложенные циклы контринтуитивны по дефолту
А вообще, UB - это то, что не определено стандартом, но и не запрещено. От компилятора к компилятору, так сказать.
Сосунок, ты думаешь я не знаю, что такое строка в Си? Что это нуль-терминированный массив символов? Камон, я писал драйвера и кастомный кернел с половиной кода на асме еще до того, как твой батя твою мамку тобою запузырил, не пытайся маняврировать, ты выглядишь нелепо. Единственное, что ты пытался сделать, это доебаться до слов, чтобы выйти из нелепой для себя ситуации.
Керберос свой не писал случайно? Поделись а тота хуйня заебала отваливаться, деда =)
Маня, у тебя этот конст находится в стэковом фрейме функции и при обращении по адресу нет никакого адреса ни в какую секцию, а есть просто голое значение инта, че ты несешь? У тебя перед глазами вывод отладчика, а ты маняврируешь.
Более того, в .text секции хранится код, там пермишены read & execute, причем здесь переменные, ебалай? Они там не хранятся.
Если ты, уебок тупой, перепутал это с .data/rodata, то тоже нет, для этого переменная на пикриле должна быть глобальной, а не локальной. Проверь в отладчике.
Нихуя не знаешь и еще пытаешься выебываться. Пиздуй учить матчасть, щенок.
>(инт) лежит
>.text секции
Лучший троллинг тупостью, лол
студентишка, плиз
Похоже придётся. Как раз то, как я сейчас кодю, и есть овощной вариант.
>пуксреньк
Что ж вы такие сливные, я вам вывод отладчика на реальной программе даю с доказательствами, а вы маняврируете, лол :-) За мной аргументы и факты, за вами кукареканье. Так не интересно.
Ребёнок, ну прекрати проецировать и копипастить. Ты ведь даже 2/3 из написанного не понимаешь. Каждая твоя строчка пропитана жалким негативом, что выдаёт в тебе закомплексованного юношу. Нельзя так себя вести, не красиво. Соблюдай нормы приличия, ты всё-таки не в подворотне или /b.
Просто подумай (хотя бы в один прогон) над всем алгоритмом циклов до того как начнёшь писать даже основной.
Я предоставил факты, вывод отладчика не врет. Спор против доказанных фактов - признак долбоеба и слабохарактерного червяка. С моей стороны пока были только факты и доказательства, вы пытаетесь здесь маняврировать и троллить тупостью, камон. Раскройте глаза/откройте сами отладчик и проверьте, это не так сложно. Гораздо проще, чем пытаться кого-то задеть на анонимной борде (лол) и спорить в лоб с доказательствами, не имея своих.
Ебать рвет умника. Иди кури мет.)
mov DWORD PTR var$[rsp], 1337
mov DWORD PTR var$[rsp+4], 228
mov DWORD PTR var$[rsp+8], 1488
К сожалению, это наследие для обратной совместимости. Древние реализации имели другой синтаксис объявлений, а при отстутсвии объявления компилятор молча предполагал, что все аргументы int, и возвращаемое значение тоже int. Такие ошибки мега трудно дебажить, особенно если один из аргументов/возвращаемого значения является укащателем, который обрежется компилятором до 32битного инта (особенно на 64битной системе).
И да, -Wall, как ни парадоксально, ловит не все. Попробуй добавить во флаги компиляции явное указание стандарта не ниже C99 (а лучше сразу C18, хуле), либо попробуй явно включить предупреждения - Wimplicit-declaration
Обсуждение этой проблемы есть здесь
https://stackoverflow.com/questions/434763/are-prototypes-required-for-all-functions-in-c89-c90-or-c99
Как сделать виндовс-окошко в этой вашей пораше?
для гуя укатывайся в какой-нибудь сисярп, Сишечка для лампового системного программирования, а не для формашлепства.
CreateWindowEx
Мне надо на осмноае Си исходника з\апилить приложення
Opengl или win 32, для обоих доков миллионы, шизоидов сверху не слушай.
Да що это такое ваше системное программирование я хуй пойму. Это получается все эти ваши ебомбаные ядра линупса и другие дрочева для взаимодействия оси с железом или даже что повыше? И какие показатели заработной платы у всей цей хуебты для условного джуна-мидла на it рынке ммм? И сколько вы по времени в это всё вкатывались до уровня достойной зп? Можно ли жить на одной шишечке без крестов или с ними получаемые мной сабжики вырастут по экспоненте?
В странах СНГ системщики маловостребованы и им хуево платят.
Забугром системщики зарабатыват больше жс-макак, как это и полагается.
Анон, помоги ебану (мне) найти доки на сишную обёртку тессеракта, или хотя бы на крестовую
А что это за забугор такой ты мне скажи а то я хз. Вот я в Финке живу це забугор уже или ещё нет? Знаю типа из россиюшки который катает 1 неделю в месяц по всем кокотельным своего города, редачит там что-то на сишке пару часов и получает за это 200к в месяц.
Ты или тралль-абсрактушок-пиздабол или что-то перепутал.
По котельным катаются вот эти ребята:
https://2ch.hk/wrk/res/1998066.html
И прогают там не на С, а на диалекте паскаля (ST), а то и вовсе мышкой (LD, FBD).
Это то, что мне рассказывает знакомый. Как там на самом деле - я без понятия. Может он аптекарем работает.
>тралль
0 мотивации. Просто интересно узнать на хороший ли путь я встал.
Ну, если цель - попасть в железячный интырпрайз вроде телекома или прочих нвидий или на худой конец - прошивки для индезита писать в конторе-подрядчике - то да.
Если разрабатывать аналоговнет в засаленной ниишке с тащмайором за спиной и подпиской о невыезде - то нет
В юзерленде это разработка демонов, какие-нибудь движки баз данных, что-то для виртуализации/эмуляции. Плотют за такое хорошо (100-200), если компания крупная, в других хз. На шишечке самое то писать ядрышки и демоны, а в проекте покрупнее быстро вляпаешься в плюсы.
Яснооо. А как обстоят дела с временем вката? Как многие любят писать ~10 лет или получше? Сейчас Прату читаю, там хоть какая-то база для этого будет?
>А как обстоят дела с временем вката?
Если ты нуб и тебе интересно низкоуровневое программирование/системщина, то надо самообучаться лет пять (в т.ч. копать чужой код), чтобы нахуячить приличный код для резюме и ответить на каверзные вопросы. Дальше еще 5-10 лет настоящих задач, чтобы стать профи. Повышение зряплаты при этом зависит от галеры.
>Прата
Не читал.
США, Израиль и Германия. Про другие не скажу, ибо не знаю.
Стоит ли читать книгу по устаревшему стандарту?(Керниган, Ричи 2 издание) или лучше поискать что-то поновее. Хочу вникнуть в азы си и перекатиться на плюсы.
Лучше сразу кресты, Страуструпа почитай или Прата. Азы у них одинаковые
Да там немного осталось, за пару дней осилю и за си++ уже детально возьмусь. Просто на си лабы писал и если что на крестах можно как на си писать(вроде)
Анончики, помогите пожалуйста.
Я знаю что этот вопрос уже всех заебал, но все же.
КАК нарисовать линию или там кружочек?
graphics.h??
Я знаю что этот вопрос уже всех заебал, но все же.
КАК нарисовать линию или там кружочек?
graphics.h??
Надо оконное приложение создавать. Оно на каждой платформе по-своему делается, либо кросплатформенную либу использовать.
Для сего тебе? Если что то серьезное, возьми opengl
Почему у меня все переменные типа дабл, а после операций с ними получается 0.000000? В каком месте происходит data conversion?
Ок, там не в этом дело.
>%d
>unsigned int/53
Простите, сегодня перечитал свой вопрос, никакой дополнительной информации не предоставил.
Итак:
Win10
Code::Blocks + очевидный MinGW (шел вместе с CodeBlocks, должен быть последний).
* Из чтения разной документации пришел к выводу что больше всего мне подходит SDL2.
В гугле полно видео от индусов, но нихера не работает.
>все переменные типа дабл
CreateWindowEx и весь стандартный win32 gui app skeleton, который можно без проблем спиздить в гугле. По WM_PAINT ты просто BeginPaint/LineTo/ArcTo/EndPaint и все.
SDL тебе никаким образом тут не поможет, она про растровую графику, свои кружочки тебе придется по точечкам рисовать. OpenGL как бы умеет в линии, но это функциональность давно deprecated, а в современном OpenGL линии принято рисовать длинными и тонкими треугольниками. Поэтому из всех вариантов GDI - самый простой способ.
>GDI
Там разве не кресты? В гугле жалуются что не компилится под чистым си, там же классы.
Это говорят про GDI+ (хотя GDI+ тоже можно, если заморочиться), а я говорю про GDI. Ничего серьезного на GDI давно не делают, но оно по-прежнему поддерживается, работает в любой винде, и достаточно просто в использовании: https://pastebin.com/raw/7nu7GzsP
Как начать понимать чужой код на си? Я открыл случайный проект на гитхабе, а там куча папок и хрен знает что за каждая отвечает. Что мне нужно гуглить, чтобы понимать(хотя бы почему так располагаются файлы и где главная функция)?
Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
Где его можно посмотреть?
Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
TL;DR ищу гайд для написания lite аналога partition wizard с нуля.
>Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
>Где его можно посмотреть?
Форматирование это по сути создание базы данных на носителе. Посмотреть начиная с педевикии и списка источников.
> Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
Вручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера - это кремнием в транзисторах контроллера USB зашито.
Короч, тебе танненбаума "архитектура компьютера" внутривенно 2 раза в день до появления понимания.
А partition wizard тебе рано писать.
Всем спасибо, нашел WinBGIm, все просто и заебись.
> ручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера
Вручную сорт оф можно. Гугли, например, какой-нибудь AVR USB bitbanging.
Анончик, клянусь, несколько часов ищу хоть какую-то инфу про gdi, но ничего.
Где хоть пример есть на си?
Спасибо!
другой анон
В посте, на который ты отвечаешь?
Анон, послушай меня, самый простой способ и стаковерфлоу со мной согласен это bgi turbo c через dosbox.
В свое время я так и писал простенькую графику, рад в 21м веке узнать что нихуяшеньки не изменилось.
Новичку в си другого выбора не дано, то что тут выложено в gdi через указатели с нулем инфы и спецификаций. И то хуй найдешь.
Удачи вам.
добавил в compiler options:
-Wall -Wextra -pedantic -Wno-unused-parameter -std=c11
добавил в linker options:
-luser32 -lgdi32
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
>skipping incompatible ... when searching for
А такое чтобы сразу работало есть?
Ах тыж питрасян :))
Через CMD скомпилилось без ошибок, а через ide хуй.
Stackoverflow говорит что я пытаюсь создасть -64 приложение на -32 библиотеке. Но это мне ни о чем не говорит. ПАМАГИТИ.
>OpenGL как бы умеет в линии, но это функциональность давно deprecated
Линии прекрасно рисуются и в Вулкане, и в DX12, сажедебил
Читать чужой код всегда стрёмно, а впопенсорс тем более, просто читай и кровавыми руками пытайся разобраться
Поясните за IDE. VS же считается топом? А норм она в самом начале изучения языка? Вчера полчаса ебался с scanf_s поэтому интересно какие косяки могут быть впереди. Codeblocks не выношу из-за ущербного интерфейса и ужасной настройки внешнего вида из-за которой я не могу сделать себе ламповый чёрный интерфейс. И почему вообще в разных IDE абсолютно идентичный код может давать разный вывод? Как это доджить?
> dosbox
Ну если тебе просто кружочек нарисовать, то самый простой способ - это JS и <canvas>, там даже устанвливать ничего не нужно. Я думал, мы о чем-то практически применимом разговариваем.
> в 21м веке узнать что нихуяшеньки не изменилось
В 21 веке завезли сишный апи для Skia, например. Признайся, ты просто не хочешь изучать ничего нового.
> с нулем инфы и спецификаций
MSDN более чем достаточно, там не только описания функций есть, но и вводные статьи, вот потыкай: https://docs.microsoft.com/en-us/windows/win32/gdi/windows-gdi Но для неосиляторов раньше специальная книжка была Feng Yuan "Windows Graphics Programming".
> VS же считается топом
Для серьезных проектов. Для хелловорлдов - что угодно, хоть вимы, хоть вскоды и саблаймы, хоть clion.
> Вчера полчаса ебался с scanf_s
Один запрос в гугле, первый результат. Или можно смириться и писать, как хочет MS.
> какие косяки могут быть впереди
Некоторые возможности из C11 поддерживаются только с бубном. Например, надо запустить VS Installer и доустановить там clang.
> И почему вообще в разных IDE абсолютно идентичный код может давать разный вывод?
IDE тут не при чем. Это проблемы твоего кода. Нормально пиши - нормально будет.
>первый результат
Да вот нифига, я несколько ссылок пролистал где подсказывали отлючать проверку через дефайн, а надо было в настройках проекта. Но ебался я с тем, как указывать размер буфера для ввода.
>Поясните за IDE
Нинужно. Нотепад++ достаточно
А компилить чем?
Руками в асм переводить
Типичный двачер - справляется руками.
>современный уровень
>сейчас даже амуда искаропки в 4ггц+ идет
gcc, clang, алло
https://2ch.hk/pr/res/1711268.html
> Для Си умельцы скорее всего тоже либ уже налепили.
Зачастую, кстати, у С-дедов такие библиотеки дают лучшую производительность, чем у С++-миллениалов. Быстрее только на чистом ассемблере. Деды в целом и это могут, но долго это. Поэтому на чистом ассемблере пишут только местами: ту логику/вычисления, которая исполняется 85-99% от общего времени.
> Для Си умельцы скорее всего тоже либ уже налепили.
Зачастую, кстати, у С-дедов такие библиотеки дают лучшую производительность, чем у С++-миллениалов. Быстрее только на чистом ассемблере. Деды в целом и это могут, но долго это. Поэтому на чистом ассемблере пишут только местами: ту логику/вычисления, которая исполняется 85-99% от общего времени.
ну да, сишная
для гейбдева
это довольно просто
было бы странно если бы libc была не на си
по фактам
Пожалуйста, пользуйтесь 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/