Этого треда уже нет.
Это копия, сохраненная 26 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1,9 Мб, 2000x2610Тред, посвященный прародителю всех С-подобных языков и по совместительству единственному идеальному и всесторонне годному средству программирования как на системном, так и на прикладном уровне.
Пожалуйста, пользуйтесь https://ideone.com/#, https://wandbox.org/ или https://pastebin.com/ для вставки кода, если он длиной больше нескольких строк или содержит [i] или ∗.
Что читать:
- Brian Kernighan, Dennis Ritchie "The C Programming Language": http://www.cypress.com/file/56651/download
- Stephen Prata "C Primer Plus, 6th Edition" (2014): относительно свежая, знает про C89/C99/C11, описывает различия, объемная (около тысячи страниц), годная, с вопросами, упражнениями и ответами. Читать после K&R или до.
- Zed A. Shaw "Learn C the Hard Way" (2015): годное пособие для гуманитариев для гуманитариев!
- Немного примеров хорошего стиля: http://www.oualline.com/books.free/style/index.html
- ООП, например: http://www.cs.rit.edu/~ats/books/ooc.pdf
- Стандарт ISO/IEC 9899:1999 (C99): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (драфт)
- Стандарт ISO/IEC 9899:2011 (C11): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (драфт)
- Черновик стандарта ISO/IEC 9899:202x (C2x): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2479.pdf (февраль 2020, с диффами)
Чем компилировать:
- Очевидный GCC.
- clang: оче годно, батя рекомендует.
- Intel C++ Compiler: оптимизации, тысячи их.
- Visual Studio Community Edition: внезапно этим стало можно пользоваться, особенно с тулсетом clang/C2. Поддержка C11 на уровне "есть все, что тебе понадобится в реальном проекте плюс кривая библиотека". Анализатор кода в комплекте.
- Pelles C (шиндоуз онли): поучиться, вкатиться в C11 (стандарт полностью реализован, имеются в том числе threads.h и прочие stdatomic.h), но количество багов в оптимизаторе и редкие апдейты напрочь отбивают желание собирать этим что-то сколько-нибудь серьезное.
- TCC: очень маленький компилятор с багами и поддержкой C99. С ключом -run умеет компилировать код в память и запускать его, что позволяет писать скрипты прямо на сишечке.
Что еще почитать:
http://c-faq.com/
FAQ из comp.lang.c. Древний, но все еще актуален.
Samuel P. Harbison, Guy L. Steele Jr. "C: A Reference Manual, 5th Edition" (2002)
Ебаный пересказ стандартов C89 и C99 (включая стандартную библиотеку). Для не осиливающих стандарт в оригинале. Читать в качестве подготовки к собеседованиям (есть задачник с ответами) и для ознакомления с масштабами пиздеца перед написанием своего парсера/компилера.
Peter Van Der Linden "Expert C Programming. Deep C Secrets" (1994)
"Си: грязные истории". Смехуечки, немного объяснений, чем обусловлены особенности языка, всем известные подводные камни кто там ругал косяки в JS? у нас в сишечке их гораздо больше, просто они лучше спрятаны, немного байтоебли и непонятно откуда взявшаяся глава про старинные плюсы. Читать в качестве сказки на ночь (на пару вечеров хватит).
Richard M. Reese "Understanding and Using C Pointers. Core Techniques for Memory Management" (2013) - почитать, вкатиться в указатели.
Ben Klemens "21st Century C: C Tips from the New School" (2012)
Paul Deitel, Harvey Deitel "C for Programmers with an Introduction to C11" (2013)
Stephen G. Koch@n "Programming in C (3rd Edition или 4th Edition, если найдется)" (2014)
MISRA Ltd. "Guidelines for the Use of the C Language in Critical Systems" (2013)
Набор рекомендаций по написанию надежного кода на C (промышленный стандарт). Читать - однозначно, следовать - вдумчиво и без фанатизма. Также можно посмотреть https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard и http://web.archive.org/web/20190213011655/homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf
Еще более длинный список: http://www.iso-9899.info/wiki/Books#Learning_C
https://github.com/kozross/awesome-c
Онлайн-утилиты:
- https://godbolt.org/ - Compiler Explorer позволяет посмотреть выхлоп компиляторов для введенного куска кода (больше полусотни разных версий компиляторов).
- http://cdecl.org/ - С Gibberish ↔ English помогает читать сложные сишные декларации.
Прошлые треды:
- №55: http://arhivach.ng/thread/543511/
- №56: http://arhivach.ng/thread/563333/
- №57: http://arhivach.ng/thread/563334/ >>1680461 (OP)
Пожалуйста, пользуйтесь https://ideone.com/#, https://wandbox.org/ или https://pastebin.com/ для вставки кода, если он длиной больше нескольких строк или содержит [i] или ∗.
Что читать:
- Brian Kernighan, Dennis Ritchie "The C Programming Language": http://www.cypress.com/file/56651/download
- Stephen Prata "C Primer Plus, 6th Edition" (2014): относительно свежая, знает про C89/C99/C11, описывает различия, объемная (около тысячи страниц), годная, с вопросами, упражнениями и ответами. Читать после K&R или до.
- Zed A. Shaw "Learn C the Hard Way" (2015): годное пособие для гуманитариев для гуманитариев!
- Немного примеров хорошего стиля: http://www.oualline.com/books.free/style/index.html
- ООП, например: http://www.cs.rit.edu/~ats/books/ooc.pdf
- Стандарт ISO/IEC 9899:1999 (C99): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (драфт)
- Стандарт ISO/IEC 9899:2011 (C11): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf (драфт)
- Черновик стандарта ISO/IEC 9899:202x (C2x): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2479.pdf (февраль 2020, с диффами)
Чем компилировать:
- Очевидный GCC.
- clang: оче годно, батя рекомендует.
- Intel C++ Compiler: оптимизации, тысячи их.
- Visual Studio Community Edition: внезапно этим стало можно пользоваться, особенно с тулсетом clang/C2. Поддержка C11 на уровне "есть все, что тебе понадобится в реальном проекте плюс кривая библиотека". Анализатор кода в комплекте.
- Pelles C (шиндоуз онли): поучиться, вкатиться в C11 (стандарт полностью реализован, имеются в том числе threads.h и прочие stdatomic.h), но количество багов в оптимизаторе и редкие апдейты напрочь отбивают желание собирать этим что-то сколько-нибудь серьезное.
- TCC: очень маленький компилятор с багами и поддержкой C99. С ключом -run умеет компилировать код в память и запускать его, что позволяет писать скрипты прямо на сишечке.
Что еще почитать:
http://c-faq.com/
FAQ из comp.lang.c. Древний, но все еще актуален.
Samuel P. Harbison, Guy L. Steele Jr. "C: A Reference Manual, 5th Edition" (2002)
Ебаный пересказ стандартов C89 и C99 (включая стандартную библиотеку). Для не осиливающих стандарт в оригинале. Читать в качестве подготовки к собеседованиям (есть задачник с ответами) и для ознакомления с масштабами пиздеца перед написанием своего парсера/компилера.
Peter Van Der Linden "Expert C Programming. Deep C Secrets" (1994)
"Си: грязные истории". Смехуечки, немного объяснений, чем обусловлены особенности языка, всем известные подводные камни кто там ругал косяки в JS? у нас в сишечке их гораздо больше, просто они лучше спрятаны, немного байтоебли и непонятно откуда взявшаяся глава про старинные плюсы. Читать в качестве сказки на ночь (на пару вечеров хватит).
Richard M. Reese "Understanding and Using C Pointers. Core Techniques for Memory Management" (2013) - почитать, вкатиться в указатели.
Ben Klemens "21st Century C: C Tips from the New School" (2012)
Paul Deitel, Harvey Deitel "C for Programmers with an Introduction to C11" (2013)
Stephen G. Koch@n "Programming in C (3rd Edition или 4th Edition, если найдется)" (2014)
MISRA Ltd. "Guidelines for the Use of the C Language in Critical Systems" (2013)
Набор рекомендаций по написанию надежного кода на C (промышленный стандарт). Читать - однозначно, следовать - вдумчиво и без фанатизма. Также можно посмотреть https://www.securecoding.cert.org/confluence/display/c/SEI+CERT+C+Coding+Standard и http://web.archive.org/web/20190213011655/homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf
Еще более длинный список: http://www.iso-9899.info/wiki/Books#Learning_C
https://github.com/kozross/awesome-c
Онлайн-утилиты:
- https://godbolt.org/ - Compiler Explorer позволяет посмотреть выхлоп компиляторов для введенного куска кода (больше полусотни разных версий компиляторов).
- http://cdecl.org/ - С Gibberish ↔ English помогает читать сложные сишные декларации.
Прошлые треды:
- №55: http://arhivach.ng/thread/543511/
- №56: http://arhivach.ng/thread/563333/
- №57: http://arhivach.ng/thread/563334/ >>1680461 (OP)
>>711268 (OP)
Я один не использую все эти typedef, #define и прочие операторы которые просто присваивают псевдонимы типам и константам?
Не думаю что эти функции особо нужны в ЯП. Поясните, пожалуйста, прав ли я или нет. Если нет то какое практическое преминение может быть этим typedef и define
Я один не использую все эти typedef, #define и прочие операторы которые просто присваивают псевдонимы типам и константам?
Не думаю что эти функции особо нужны в ЯП. Поясните, пожалуйста, прав ли я или нет. Если нет то какое практическое преминение может быть этим typedef и define
>>711439
Чтобы не размазывать в пределах модуля ololoverysometype тысячу раз, а писать какое-нибудь короткое ovstype
Чтобы не размазывать в пределах модуля ololoverysometype тысячу раз, а писать какое-нибудь короткое ovstype
>>711439
макросы, макросики
макросы, макросики
>>711439
Вот будешь передавать в функцию указатель на колбек, принимающий и возвращающий указатели, и особенно указатели на массивы - поймешь. Нет, ты, возможно, даже напишешь это правильно с первого раза, но вот читать этот код когда-нибудь потом будет сложно даже тебе самому. Алсо, тайпдефы позволяют абстрагироваться от особенностей системы (например, размера unsigned long), позволяют документировать код, не используя комментарии (unsigned int color vs. rgba color в аргументах), позволяют избавиться от блядского struct.
Это единственный в Си нормальный способ объявления констант, это условная компиляция, это возможность гарантированного инлайна простого кода (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
};
> Если нет то какое практическое преминение может быть этим 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
};
114 Кб, 822x638День добрый, подскажите скрин изкниги П. Дейтел, Х.Дейтел - С для программистов с введением в С11 - 2016 , первый выделенный printf работет нормально, второй вместо подчеркиваний цифры какие то печатал. пока я d на s не поменял и звёздочку не убрал. puts просто ошибку выдавало в С-free 5.0. Причем код в книжке и в исходниках одинаковый. Это опечатки или проблема в С-free + mingw5&
>>712935
Это опечатки. Везде должно быть printf, c %s ты все правильно сделал, хотя смысл этих конструкций от меня ускользает, делать printf("%s", "строка") совершенно незачем. Это вся книга такая?
Это опечатки. Везде должно быть printf, c %s ты все правильно сделал, хотя смысл этих конструкций от меня ускользает, делать printf("%s", "строка") совершенно незачем. Это вся книга такая?
>>713183
Да ты что! Это с двумя константными строками?
Да ты что! Это с двумя константными строками?
>>713183
С кем воюешь, шизоид? Погбеб выкопал и сухпаёк уже собрал, на случай ядерной атаки?
С кем воюешь, шизоид? Погбеб выкопал и сухпаёк уже собрал, на случай ядерной атаки?
>>713148
Странно что эти опечатки в исходниках повторяются которые с книгой шли, книгу тут анон выкладывал в ввиде картинки.
Странно что эти опечатки в исходниках повторяются которые с книгой шли, книгу тут анон выкладывал в ввиде картинки.
>>713562
Если бы было printf(user_data), тогда да, за это бить надо, пока не дойдет. Но в книге совершенно другой случай.
Если бы было 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 в каждом месте, где требуется определить знаковость?
>>713861
Ладно, для третьего вопроса пока есть такой говнокод:
#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)
Очень надеюсь, что есть что-то лучше.
Ладно, для третьего вопроса пока есть такой говнокод:
#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)
Очень надеюсь, что есть что-то лучше.
>>713717
Правильно делают. Нормальный человек понимает что пишет, опечатки наоборот помогают учить язык. А дауны макаки бездумно перепечатывают, а потом ноют "пачиму ниработаит".
Правильно делают. Нормальный человек понимает что пишет, опечатки наоборот помогают учить язык. А дауны макаки бездумно перепечатывают, а потом ноют "пачиму ниработаит".
Сап, двач. Есть ли где-нибудь годный сборник ВСЕХ UB? Ну, или хотя бы просто всех UB, связанных с целочисленной арифметикой и побитовыми операциями?
>>715236
В стандарте.
В стандарте.
>>715364
Uncle Bob
Uncle Bob
>>715364
Просто съеби
Просто съеби
50 Кб, 300x300uint32_t testvalue = (((72000000 / 64) x (5 / 1000)) - 1);
Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
Как избавиться от (5 / 1000)?
В переменную заносится какая-то дичь - testvalue is: 4294967295
Понятно, что это из-за результата деления в виде float.
>>715236
В прошлом тредике что-то постили еще: >>1696945 →
>>715432
Скобки раскрой, нахуй ты их вообще расставил?
> сборник ВСЕХ UB
В прошлом тредике что-то постили еще: >>1696945 →
>>715432
Скобки раскрой, нахуй ты их вообще расставил?
67 Кб, 308x300>>715438
uint32_t testValue = (1125000 * (N / 1000)) - 1;
где N - изменяющееся число, от 1 до 20.
>Скобки раскрой, нахуй ты их вообще расставил?
uint32_t testValue = (1125000 * (N / 1000)) - 1;
где N - изменяющееся число, от 1 до 20.
16 Кб, 400x300>>715449
Для красоты.
Как правильно преобразовать выражение, чтобы, сука, получить результат, как при решении на кулькуляторе?
Для красоты.
Как правильно преобразовать выражение, чтобы, сука, получить результат, как при решении на кулькуляторе?
>>715526
Нахуй там плавающая точка, если результат все равно обрезается до инта как раз после деления?
Нахуй там плавающая точка, если результат все равно обрезается до инта как раз после деления?
>>715526
Спасибо, работает.
Спасибо, работает.
>>715489
Нахуй ты пальцы постишь? Как думаешь что в целочисленных типах подставляется вместо X/1000 при x<1000?
Нахуй ты пальцы постишь? Как думаешь что в целочисленных типах подставляется вместо X/1000 при x<1000?
Допустим у нас объявлена структура и мы создали эту структуру в какой-то функции, вопрос: нужно ли использовать 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) ???
}
>>716721
Нет, такие переменные называются автоматическими, и они автоматически перестают существовать при выходе из функции. Но проще всего думать по-другому: если ты сам что-то выделил или открыл (с помощью malloc или там fopen), то ты сам и должен вызвать очистку. Тут ты никаких malloc не вызывал, поэтому и free сделать не можешь.
> нужно ли использовать free() или она удалится из памяти по завершению функции?
Нет, такие переменные называются автоматическими, и они автоматически перестают существовать при выходе из функции. Но проще всего думать по-другому: если ты сам что-то выделил или открыл (с помощью malloc или там fopen), то ты сам и должен вызвать очистку. Тут ты никаких malloc не вызывал, поэтому и free сделать не можешь.
>>716736
Да, структура (а точнее её часть) создаётся calloc' ом. Думал это не существенно.
Пасиб).
П.С. удаляется структура через особую ф-цию если что, и free используется только для части с calloc.
>открыл (с помощью malloc или там fopen)
Да, структура (а точнее её часть) создаётся calloc' ом. Думал это не существенно.
Пасиб).
П.С. удаляется структура через особую ф-цию если что, и free используется только для части с calloc.
>>716779
Мануал почитать, не?
Мануал почитать, не?
>>716779
void foo(void) { int automatic_local; }
void bar(void) { static int non_automatic_local; }
void baz(void) { extern int non_local_non_automatic; }
void foo(void) { int automatic_local; }
void bar(void) { static int non_automatic_local; }
void baz(void) { extern int non_local_non_automatic; }
>Кстати поясните нахуя МЦСТ свой ёбаный путь, когда, например, VIA делает процы на x86-x64? В чём суть?
Потому что штеуд запретил навсегда лицензировать хуй86 кому бы то ни было еще кроме лизочки писечки и собственно via.
Если бы штеуд разрешал пилить х86 этим бы не то что МЦСТ этим бы 3/4 производителей чипов бы занимались шутка ли такое-то легаси.
>>719231
Ну ведь есть не только хуй86. Тут даже десктопные пека теперь будут на самой популярной архитектуре "скоро". Что скажешь?
Ну ведь есть не только хуй86. Тут даже десктопные пека теперь будут на самой популярной архитектуре "скоро". Что скажешь?
Поясните более подробно за указатели и адреса молю.
Чем отличается
int c
от int c
Такая непонятная хуйня уже весь мозг себе сломал.
Чем отличается
int c
от int c
Такая непонятная хуйня уже весь мозг себе сломал.
>>720449
я листва дo сих пoр. пoэтoму oбъясни мне, мoлю. или дай хoтя бы ссылку на какoй-нибудь мануал пo ним.
я листва дo сих пoр. пoэтoму oбъясни мне, мoлю. или дай хoтя бы ссылку на какoй-нибудь мануал пo ним.
>>720459
Ничем.
Ничем.
>>720449
хули там понимать, за 1 час можно понять всю суть указателей
хули там понимать, за 1 час можно понять всю суть указателей
>>720573
В шапке всё есть.
В шапке всё есть.
>>720585
двач проглотил звёздочки просто которые должны были показать разницу между ними.
двач проглотил звёздочки просто которые должны были показать разницу между ними.
>>721388
Вопрос то у меня не по ней, а конкретно по libcurl.
Вопрос то у меня не по ней, а конкретно по libcurl.
>>719818
Есть именно что хуй 86, убивший за 30 лет нахуй всех своих конкурентов - Power, Alpha, SPARC.
Если ты про арм - то он не конкурент, даже в самых своих мощных реализациях от яблока и квалкома он кукурузнее самых неудачных фуфыксов.
Есть именно что хуй 86, убивший за 30 лет нахуй всех своих конкурентов - Power, Alpha, SPARC.
Если ты про арм - то он не конкурент, даже в самых своих мощных реализациях от яблока и квалкома он кукурузнее самых неудачных фуфыксов.
>>721857
arm убьёт x86, можете скринить. А потом будет RISC-V.
Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать, да и бум мобилок ускоряет заколачивание гроба.
arm убьёт x86, можете скринить. А потом будет RISC-V.
Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать, да и бум мобилок ускоряет заколачивание гроба.
>>721977
Не убьет.
Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона.
В то время как бэкенд по прежнему крутится на могучих х86 зивонах и никаким немощным рукам их там не потеснить - когда доходит до дела - нужна честная моща пер коре а не кукуруза с многоядерным потанцевалом и проблемой рожающих бабищ в 99% реальных задач.
Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
х86 ассемблер может быть сколь угодно громоздким - микроархитектурка решает и ставит рекорды производительности на ядро.
Дошло до того что зеоны ебут уже который год считавшихся непобедимыми динозавров от IBM (POWER и Z).
> arm убьёт x86
Не убьет.
> бум мобилок ускоряет заколачивание гроба
Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона.
В то время как бэкенд по прежнему крутится на могучих х86 зивонах и никаким немощным рукам их там не потеснить - когда доходит до дела - нужна честная моща пер коре а не кукуруза с многоядерным потанцевалом и проблемой рожающих бабищ в 99% реальных задач.
> Никому нафиг не нужен в будущем громоздкий x86, который уже невозможно допиливать
Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
х86 ассемблер может быть сколь угодно громоздким - микроархитектурка решает и ставит рекорды производительности на ядро.
Дошло до того что зеоны ебут уже который год считавшихся непобедимыми динозавров от IBM (POWER и Z).
>>722014
Да и, собственно, с появлением дохуядерных эпичей от лизки и дохуядерных платинов от штеуда, арм на серверах закопан нахуй окончтельно.
Да и, собственно, с появлением дохуядерных эпичей от лизки и дохуядерных платинов от штеуда, арм на серверах закопан нахуй окончтельно.
Пацаны, че за хуйня. Работаю над кодом вместе с libusb.
Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.
Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)
Там есть функция set_control и set_debug. Последняя немного устарела и поэтому используется первая.
Чувак жалуется, что в моей программе implicit declaration of function ‘libusb_set_option’ (первый пик).
Как блять так, версия либы у нас одна, одна система и причем у меня это работает (второй пик)
>>722014
Новые армы в бенчах уже показывают сравнимый с интелами результат: https://www.macrumors.com/guide/arm-macs/ - и это при в разы меньшем tdp. У интелов же - родовая травма в виде сложного декодера и малого числа именованных регистров, из-за чего им крайне сложно повышать число инструкций на такт. Ты забыл, так я напомню - во времена Haswell интелы росли в однопотоке на 3-5% на поколение. И мы сейчас вполне можем вернуться в это страшное время.
Новые армы в бенчах уже показывают сравнимый с интелами результат: https://www.macrumors.com/guide/arm-macs/ - и это при в разы меньшем tdp. У интелов же - родовая травма в виде сложного декодера и малого числа именованных регистров, из-за чего им крайне сложно повышать число инструкций на такт. Ты забыл, так я напомню - во времена Haswell интелы росли в однопотоке на 3-5% на поколение. И мы сейчас вполне можем вернуться в это страшное время.
>>722062
Я уже молчу, каким отбитым имбецилом надо быть, чтобы не видеть разницы игрушки от компьютера с набором софта за 40 лет. Ах да, это же пердоля с таким же ноусофтом и пердольными игрушками. Вот откуда рак и деградация лезет, из этого отстойника скама человеческого.
>2020
>хвалить обоссанную ноусофт консоль
Я уже молчу, каким отбитым имбецилом надо быть, чтобы не видеть разницы игрушки от компьютера с набором софта за 40 лет. Ах да, это же пердоля с таким же ноусофтом и пердольными игрушками. Вот откуда рак и деградация лезет, из этого отстойника скама человеческого.
>>722014
Скринь.
Ну а теперь сравни гешефт с продажи одного условного сервака для бекенда и десятков тысяч мобильников, которые этот сервак будут использовать. Сравни число произведённых процов каждой архитектуры для данного наборчика и осознай, что в недалёком будущем камни на x86 будут производить 1.5 фабрики на весь мир. А за количественными переменами последуют и качественные.
Ага, что вкупе с обратной совместимостью, а также всякими непрозрачными архитектурными перделками превратило типичный проц от, допустим, интела в никому не понятный ОГРОМНЫЙ чёрный ящик с кучей бекдоров, какими-то встроенными микро-ос и прочим хламом. А агрессивные попытки все это заставить быстрее работать оборачиваются очередными уязвимостями.
>Не убьет.
Скринь.
>Никак не влияет - 90% мобильного софта тонкие клиенты, а 90% успешных мобильных игорей - донатное дрочево без графона...
Ну а теперь сравни гешефт с продажи одного условного сервака для бекенда и десятков тысяч мобильников, которые этот сервак будут использовать. Сравни число произведённых процов каждой архитектуры для данного наборчика и осознай, что в недалёком будущем камни на x86 будут производить 1.5 фабрики на весь мир. А за количественными переменами последуют и качественные.
>Еще во времена мотороллы 68000 изобрели такую штуку как микрокод.
Ага, что вкупе с обратной совместимостью, а также всякими непрозрачными архитектурными перделками превратило типичный проц от, допустим, интела в никому не понятный ОГРОМНЫЙ чёрный ящик с кучей бекдоров, какими-то встроенными микро-ос и прочим хламом. А агрессивные попытки все это заставить быстрее работать оборачиваются очередными уязвимостями.
>>722096
Ну да, ну да - смартфон нинужон, дубль два. Конец уже сейчас предсказуем - нынешний айпад про станет новым форматом железа, и у жужжащих ящиков пропадет ещё половина рынка. Потом вендоры АРМ и ПОСов подтянутся и интелов станет ещё меньше. Слона съесть несложно, ежели по частям.
Ну да, ну да - смартфон нинужон, дубль два. Конец уже сейчас предсказуем - нынешний айпад про станет новым форматом железа, и у жужжащих ящиков пропадет ещё половина рынка. Потом вендоры АРМ и ПОСов подтянутся и интелов станет ещё меньше. Слона съесть несложно, ежели по частям.
>>722096
Какой, нахуй, софт за 40 лет? Сейчас уже 95% реально используемого людьми софта либо open-source, либо скомпилировано под кучу других платформ, помимо windows+x86. Хоть на чайнике запускай.
>с набором софта за 40 лет
Какой, нахуй, софт за 40 лет? Сейчас уже 95% реально используемого людьми софта либо open-source, либо скомпилировано под кучу других платформ, помимо windows+x86. Хоть на чайнике запускай.
>>722053
#include <libusb/libusb.h> не?)
Вот ее объявление: https://github.com/libusb/libusb/blob/14a302a2f55cb2e619158854f94845f2ca2c8214/libusb/libusb.h#L2084
#include <libusb/libusb.h> не?)
Вот ее объявление: https://github.com/libusb/libusb/blob/14a302a2f55cb2e619158854f94845f2ca2c8214/libusb/libusb.h#L2084
>>722108
Зделой объявление функции перед мейном.
Зделой объявление функции перед мейном.
>>722107
Вот двачую. Игорей конца 90 уже хер где запустишь, разве что в эмуляторе, что съедает хваленую производительность хуй86.
>Какой, нахуй, софт за 40 лет?
Вот двачую. Игорей конца 90 уже хер где запустишь, разве что в эмуляторе, что съедает хваленую производительность хуй86.
>>722108
Если ты установишь эту либу на систему, она будет подключена как
[code]
#include <libusb-1.0/libusb.h>
[/code]
.
Если ты установишь эту либу на систему, она будет подключена как
[code]
#include <libusb-1.0/libusb.h>
[/code]
.
Нужен кто-то, кто мог бы решить ряд задач из университетского курса. Процессы, нити. С деньгами постараюсь не обидеть, обсудим.
Если кого-то заинтересовало - пишите в тележку
@twoomer
Если кого-то заинтересовало - пишите в тележку
@twoomer
Тред живой?
Помогите найти простые примеры программ и игр на си, а то я пробовал выдает только c++ и c#
>>724521
Движок игры Дум (1993 год) напиан на Си, например.
А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой.
С++ - идеальный варик для ГЕЙдева.
Движок игры Дум (1993 год) напиан на Си, например.
А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой.
С++ - идеальный варик для ГЕЙдева.
>>724521
Луа, гну сциентифик лайбрари. Первое это полноценный язык, занимающий всего пару тысяч строк кода. Второе образец того, как должна была выглядеть лаба1.с - реализация различных математических алгоритмов типа оптимизации, линейкит итд.
Луа, гну сциентифик лайбрари. Первое это полноценный язык, занимающий всего пару тысяч строк кода. Второе образец того, как должна была выглядеть лаба1.с - реализация различных математических алгоритмов типа оптимизации, линейкит итд.
>>724624
Имплаинг дум - сложная игра
https://github.com/ljbade/wolf4sdl
>Вы нормальные? Он же просил простые игры, ПРОСТЫЕ!
Имплаинг дум - сложная игра
https://github.com/ljbade/wolf4sdl
>>724593
Если подключить Lua или иную скриптопарашу, а сами си использовать онли для низкоуровневых кишочков, то не так уж и больно.
>А так - писать сложную игру на Си со сложной графикой - это как пытаться съесть кита чайной ложкой
Если подключить Lua или иную скриптопарашу, а сами си использовать онли для низкоуровневых кишочков, то не так уж и больно.
>>724653
все равно, все это попытка высрать баржу, гораздо более здраво писать такие вещи на С++ (или Сишарпе, смотря какой API хочешь и вообще какие требования к игре)
все равно, все это попытка высрать баржу, гораздо более здраво писать такие вещи на С++ (или Сишарпе, смотря какой API хочешь и вообще какие требования к игре)
Нравится Си тем что язык не сложный, небольшой, не нужно изучать постоянно всякие фреймворки как в JS или Java. Вот только сомневаюсь что смогу найти работу. Для системных программистов высокие требования. ВО, а его у меня нет. Большой опыт работы, которого у меня тоже нет. Мало вакансий. Что делать?
>>724718
Если ВО - не варик, то учи сам + пили личные проекты, офк нетривиальные. Это единственный выход.
А вообще - байтослесарям сложно найти работу в странах СНГ. Они больше ценятся забугром, там и embedded software engineer получает не меньше, чем жс-макака. В СНГ, увы, ситуация далеко не такая.
Если ВО - не варик, то учи сам + пили личные проекты, офк нетривиальные. Это единственный выход.
А вообще - байтослесарям сложно найти работу в странах СНГ. Они больше ценятся забугром, там и embedded software engineer получает не меньше, чем жс-макака. В СНГ, увы, ситуация далеко не такая.
>>724736
Пичалька
Пичалька
>>724718
Не нужно только до того момента пока ты тыкаешься в хеловорлды и линкедлисттуториал.с, в реальности же даже в современную микруху ты со знанием голого си не потыкаешься.
>не нужно изучать 3рд пати хуйню
Не нужно только до того момента пока ты тыкаешься в хеловорлды и линкедлисттуториал.с, в реальности же даже в современную микруху ты со знанием голого си не потыкаешься.
>>724903
Сравнение неподходящее. Какие то небольшие либы сравниваешь с монструозными фреймворками.
Сравнение неподходящее. Какие то небольшие либы сравниваешь с монструозными фреймворками.
>>724919
Это конкретно в примере с бытовой микрухой может оказатсья КАКАЯ-ТО НЕБОЛЬШАЯ ЛИБА. И ты забываешь, что именно монструозность сишных фреймворков в прошлом, — вроде того же опенгла, старых директексов, снящихся в страшных снах людям вин32 и прочего, — стала от части причиной появления менее монструозных фреймворков на более современных языках. То что эту хуйню перестали использовать не значит что этого никогда не было. И не значит что не существует до сих пор поддерживаемых на них продуктов
>какие-то небольшие либы
Это конкретно в примере с бытовой микрухой может оказатсья КАКАЯ-ТО НЕБОЛЬШАЯ ЛИБА. И ты забываешь, что именно монструозность сишных фреймворков в прошлом, — вроде того же опенгла, старых директексов, снящихся в страшных снах людям вин32 и прочего, — стала от части причиной появления менее монструозных фреймворков на более современных языках. То что эту хуйню перестали использовать не значит что этого никогда не было. И не значит что не существует до сих пор поддерживаемых на них продуктов
Алсо проиграл с луа с сурсом в сто строк пиздец
>>724933
И давно DirectX, у которого API на COM, стал сишным фреймворком? А вот опенгл нихуя не монструозный, полноценную реализацию OpenGL 1.x с софтварным рендером можно целиком написать в одно рыло, и код, как пользовательский, так и самой либы, будет понятен, в отличие от крестов в том же DirectX.
На самом деле проблема геймдева на Си заключается в менеджменте памяти в основном. Когда большие мальчики обмазываются всякими RAII и автоматическими указателями, когда они даже не знают, сколько раз выделилась память для их строчек, и сколько раз эти строчки при конкатенации скопировались, ты по-прежнему вынужден ебаться с goto cleanup и маллоками на каждый чих. И это слегка демотивирует. Чтобы как-то обойти эту проблему, ты тащишь статические буферы везде, куда сможешь дотянуться, что создает кучу других, еще более веселых проблем.
> старых директексов
И давно DirectX, у которого API на COM, стал сишным фреймворком? А вот опенгл нихуя не монструозный, полноценную реализацию OpenGL 1.x с софтварным рендером можно целиком написать в одно рыло, и код, как пользовательский, так и самой либы, будет понятен, в отличие от крестов в том же DirectX.
На самом деле проблема геймдева на Си заключается в менеджменте памяти в основном. Когда большие мальчики обмазываются всякими RAII и автоматическими указателями, когда они даже не знают, сколько раз выделилась память для их строчек, и сколько раз эти строчки при конкатенации скопировались, ты по-прежнему вынужден ебаться с goto cleanup и маллоками на каждый чих. И это слегка демотивирует. Чтобы как-то обойти эту проблему, ты тащишь статические буферы везде, куда сможешь дотянуться, что создает кучу других, еще более веселых проблем.
>>725172
COM - сишный API. Лично юзал DirectX из сишного кода.
>И давно DirectX, у которого API на COM, стал сишным фреймворком?
COM - сишный API. Лично юзал DirectX из сишного кода.
>>725257
Технически, это сишный АПИ (функции с cdecl типом вызова, экспортируемые из DLL) + набор соглашений.
Технически, это сишный АПИ (функции с cdecl типом вызова, экспортируемые из DLL) + набор соглашений.
>>725268
Потому что на Си написан? Хотя я сомневаюсь, скорее всего на плюсах. Никакой это не сишный апи. Вот libc в линуксе да, чисто сишный.
Потому что на Си написан? Хотя я сомневаюсь, скорее всего на плюсах. Никакой это не сишный апи. Вот libc в линуксе да, чисто сишный.
>>725210
Да, юзать COM еще туда-сюда из сишки можно. Если MS не забыла для тебя кроме варианта class написать в хедере все эти struct и STDMETHOD, обмазав толстым слоем макросов (посмотри, в заголовках директикса отдельный #ifdef для сишки... пока еще есть или уже нету в последних версиях?). С реализацией своих объектов начинается боль, особенно когда у тебя несколько интерфейсов. Да, их тоже можно на си писать, можно хоть на ассемблере писать, но это будет больно, это будет тонна однотипных реализаций QI/AddRef/Release, которые нельзя объединить, потому что офсеты lpVtbl в структуре у разных интерфейсов разные. При этом на крестах вся эта боль почти целиком уходит. Поэтому COM - крестовый.
Да, юзать COM еще туда-сюда из сишки можно. Если MS не забыла для тебя кроме варианта class написать в хедере все эти struct и STDMETHOD, обмазав толстым слоем макросов (посмотри, в заголовках директикса отдельный #ifdef для сишки... пока еще есть или уже нету в последних версиях?). С реализацией своих объектов начинается боль, особенно когда у тебя несколько интерфейсов. Да, их тоже можно на си писать, можно хоть на ассемблере писать, но это будет больно, это будет тонна однотипных реализаций QI/AddRef/Release, которые нельзя объединить, потому что офсеты lpVtbl в структуре у разных интерфейсов разные. При этом на крестах вся эта боль почти целиком уходит. Поэтому COM - крестовый.
>>725210
Алсо, я забыл добавить. Я вот юзал std::string из сишного кода (на лету генерировал обертки, превращающие __thiscall в __stdcall). Он стал от этого сишным?
> Лично юзал DirectX из сишного кода.
Алсо, я забыл добавить. Я вот юзал std::string из сишного кода (на лету генерировал обертки, превращающие __thiscall в __stdcall). Он стал от этого сишным?
Черная живет материя!
https://github.com/openssl/openssl/pull/12089
https://github.com/openssl/openssl/pull/12089
596 Кб, 880x495>>726247
Место для чёрных это backspace.
Кстати, забавляют эти потуги белых людей решать за чёрных людей, что для них оскорбительно, а что нет. Это же вроде расизм, разве нет?
Место для чёрных это backspace.
Кстати, забавляют эти потуги белых людей решать за чёрных людей, что для них оскорбительно, а что нет. Это же вроде расизм, разве нет?
>>711268 (OP)
Хочу, чтобы у меня на всех окнах было одинаковое верхнее меню (File, Edit, View, ...), но GTK почему-то не разрешает мне это сделать. Как фиксить?
Хочу, чтобы у меня на всех окнах было одинаковое верхнее меню (File, Edit, View, ...), но GTK почему-то не разрешает мне это сделать. Как фиксить?
>>725888
Лол, у нас на работе ради прикола переименовали master-slave на master-pokemon. Но это ещё до всей этой хуйни было.
Лол, у нас на работе ради прикола переименовали master-slave на master-pokemon. Но это ещё до всей этой хуйни было.
>>711268 (OP)
https://pastebin.com/gRC0UScq
Где я проебался с выравниванием, что atoi падает с сегфолтом?
В omp parallel нельзя выделять выравненную память?
https://pastebin.com/gRC0UScq
Где я проебался с выравниванием, что atoi падает с сегфолтом?
В omp parallel нельзя выделять выравненную память?
>>726556
Блять, я сонный ебаный не передавал количество тредов при запуске. C господа, отбой.
Блять, я сонный ебаный не передавал количество тредов при запуске. C господа, отбой.
Как удалить строку из файла силами C? Занести все строки файла в оперативную память, пересоздать файл и занести их обратно?
>>726773
Закинуть кусок файла после строки в память, удалить строку (и после не забыть fseek выставить на последний байт перед удаленной строкой), записать ранее сохраненный кусок по SEEK_CRT.
Закинуть кусок файла после строки в память, удалить строку (и после не забыть fseek выставить на последний байт перед удаленной строкой), записать ранее сохраненный кусок по SEEK_CRT.
>>726779
Прости хоспаде. ничего не удаляй, просто выстави fseek на первый байт той строки и пиши.
>удалить строку
Прости хоспаде. ничего не удаляй, просто выстави fseek на первый байт той строки и пиши.
>>726773
Правильный способ от олда:
1. создал временный файл
2. читаешь по символу, считаешь строки, пишешь во временный
3. fflush
4. rename(временный, оригинал)
Правильный способ от олда:
1. создал временный файл
2. читаешь по символу, считаешь строки, пишешь во временный
3. fflush
4. rename(временный, оригинал)
>>727670
tmpfile() тебе дали и tmpnam() еще.
tmpfile() тебе дали и tmpnam() еще.
>>728937
fgets(указатель на массив, кол-во читаемых символов, stdin)
Только он вносит символ перевода строки в строку, а не выкидывает его оттуда. Можешь либо свою функцию написать, либо обёртку для fgets, которая выкидывает символ перевода строки и очищает входной поток.
fgets(указатель на массив, кол-во читаемых символов, stdin)
Только он вносит символ перевода строки в строку, а не выкидывает его оттуда. Можешь либо свою функцию написать, либо обёртку для fgets, которая выкидывает символ перевода строки и очищает входной поток.
https://pastebin.com/jC1PBdsX
а за такое ебут в жёпы?
а за такое ебут в жёпы?
>>729004
Лол, зачем ты проверяешь неравенство с NULL? Можно же просто булевоское значение указателя взять.
Лол, зачем ты проверяешь неравенство с NULL? Можно же просто булевоское значение указателя взять.
>>729004
копипастил слегка недописанный код,
вот так лучше - https://pastebin.com/uUy3jV95
>>729013
Куда ходить?
копипастил слегка недописанный код,
вот так лучше - https://pastebin.com/uUy3jV95
>>729013
>булевоское значение указателя
Куда ходить?
>>729019
1) у вскякого арифметического типа (указателя, например) есть будевское значение. Если указатель не нулл, он true.
2) ты не проверяешь ошибки выделения памяти. это хуёво.
3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
4) ваще, какое-странное решение отмечать конец массива строк пустой строкой. Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом? в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
1) у вскякого арифметического типа (указателя, например) есть будевское значение. Если указатель не нулл, он true.
2) ты не проверяешь ошибки выделения памяти. это хуёво.
3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
4) ваще, какое-странное решение отмечать конец массива строк пустой строкой. Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом? в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
>>729115
Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
> используй strncpy
Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
>>729141
чёт обосрался я. запишем в конец буфера ещё нолик в любом случае.
>Ту самую, которая не терминирует строку нулем, если исходная строка не влезла в буфер?
чёт обосрался я. запишем в конец буфера ещё нолик в любом случае.
>>729115
Вроде это ебота от платформы зависит. null не всегда равно 0x00.
Согласен. Но это нахуй никому не нужный привет_мир на две-три сотни лайнов.
Что и в п.2
Мне так местные посоветовали.
Хорошая идея, пока лучшая.
Тогда маленький мемори-лик, да. Но строки будут непустыми.
Внезапно для меня realloc() может вернуть указатель с другим значением. Не знаю с чем это связано, но очевидно не с brk(), так как после фиксированной n строки значение указателя меняется(алсо меняются и указатели на строки). Я потому сюда и закинул эту хуиту, уж больно уродливо вышло.
>Если указатель не нулл, он true.
Вроде это ебота от платформы зависит. null не всегда равно 0x00.
>2) ты не проверяешь ошибки выделения памяти. это хуёво.
Согласен. Но это нахуй никому не нужный привет_мир на две-три сотни лайнов.
>3) лучше не использовать strcpy. используй strncpy/ понятно, что это у тебя наверняка лаба1, но не стоит приучаться оставлять такие очевидные уязвимости.
Что и в п.2
>4) ваще, какое-странное решение отмечать конец массива строк пустой строкой.
Мне так местные посоветовали.
>Если он у тебя уже организован как массив указателей на строки, почему бы тебе не сделать просто последний указатль нулом?
Хорошая идея, пока лучшая.
>в твоём текущем коде, напрмер, возникают забавности, если попытаться добавить пустую строку.
Тогда маленький мемори-лик, да. Но строки будут непустыми.
>5) зачем ты второй раз считаешь количество строк? ты же его уже знаешь.
Внезапно для меня realloc() может вернуть указатель с другим значением. Не знаю с чем это связано, но очевидно не с brk(), так как после фиксированной n строки значение указателя меняется(алсо меняются и указатели на строки). Я потому сюда и закинул эту хуиту, уж больно уродливо вышло.
>>729201
короч, null pointer константа по стандарту - арифметическая константа, имеющая значение 0. или таковая, приведённая к типу (void звёздочка). чёт, я не смог прм точную цитату в стандарте про обратное преобразование лул, но все другие источники говорят, что булевское значение указателя true тогда и только тогда кода он не null pointer.
>>729201
ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
короч, null pointer константа по стандарту - арифметическая константа, имеющая значение 0. или таковая, приведённая к типу (void звёздочка). чёт, я не смог прм точную цитату в стандарте про обратное преобразование лул, но все другие источники говорят, что булевское значение указателя true тогда и только тогда кода он не null pointer.
>>729201
>realloc() может вернуть указатель с другим значением
ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
>>729201
Нет. Это в стандарте языка, здесь от платформы ничего не зависит.
if (ptr == NULL) пишут только зеленые касатики, прошаренные бати знают, что первое - говнокод, и кошерно писать if (!ptr)
>Вроде это ебота от платформы зависит. null не всегда равно 0x00.
Нет. Это в стандарте языка, здесь от платформы ничего не зависит.
if (ptr == NULL) пишут только зеленые касатики, прошаренные бати знают, что первое - говнокод, и кошерно писать if (!ptr)
>>729273
Его нет. if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0. Операторы сравнения != и == сами автомагически умеют сравнивать указатель с нулевым указателем такого же типа, каким бы не было представление. И уже у операторов сравнения на выходе инт.
>>729355
Не говнокод ни разу. Исключительно вопрос выбранного стиля. Явное сравнение лучше читается, плюс некоторые пишут выражения вида if ((ptr = func()) != NULL), в них без != NULL нельзя - будет варнинг. Из этого выражения явное сравнение ради консистентности растекается и на if (ptr != NULL), и на if (ptr == NULL).
> я не смог прм точную цитату в стандарте про обратное преобразование лул
Его нет. if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0. Операторы сравнения != и == сами автомагически умеют сравнивать указатель с нулевым указателем такого же типа, каким бы не было представление. И уже у операторов сравнения на выходе инт.
>>729355
Не говнокод ни разу. Исключительно вопрос выбранного стиля. Явное сравнение лучше читается, плюс некоторые пишут выражения вида if ((ptr = func()) != NULL), в них без != NULL нельзя - будет варнинг. Из этого выражения явное сравнение ради консистентности растекается и на if (ptr != NULL), и на if (ptr == NULL).
>>729389
по маняопределению.
не видел такого в стандарте. там только написано, что арифметические типы имеют булевское значение true если не равны нулю. Указатели же неявно преобразуются к арифметическому типу. Про нулл поинтер сказано, что он - нулевая арифметическая константа или результат её приведения к типу войд звёздочка. Явно про обратное преобразование не сказано.
>if (expr) по определению делоет if (expr != 0), и !expr тоже преобразуется до expr == 0
по маняопределению.
не видел такого в стандарте. там только написано, что арифметические типы имеют булевское значение true если не равны нулю. Указатели же неявно преобразуются к арифметическому типу. Про нулл поинтер сказано, что он - нулевая арифметическая константа или результат её приведения к типу войд звёздочка. Явно про обратное преобразование не сказано.
>>729355
Зеленый жир, плиз.
Писать надо:
if (NULL == expression)
потому что expression может быть длинное, функция, и смотреть в конец неудобно и не наглядно, код плохой получается. А когда в начале, сразу видно что и как.
> if (ptr == NULL) пишут только зеленые
Зеленый жир, плиз.
Писать надо:
if (NULL == expression)
потому что expression может быть длинное, функция, и смотреть в конец неудобно и не наглядно, код плохой получается. А когда в начале, сразу видно что и как.
>>729273
Добра тебе, мелкобуквенный гений. А я просто приучил себя к указателям, как собаку Павлова.
>>729389
Кстати вспомнил, почему так и начал писать, т.к. раньше тоже !ptr юзал. Энивей какой-нибудь -pedantic варнинг родит.
>ну так ты один раз посчитай количество элементов потом прибавь к новому указателю это значение + 1, лол
Добра тебе, мелкобуквенный гений. А я просто приучил себя к указателям, как собаку Павлова.
>>729389
>в них без != NULL нельзя - будет варнинг
Кстати вспомнил, почему так и начал писать, т.к. раньше тоже !ptr юзал. Энивей какой-нибудь -pedantic варнинг родит.
>>729698
Нет, я снова обманывать, с таким сетом флагов
gcc молчит.
>Энивей какой-нибудь -pedantic варнинг родит.
Нет, я снова обманывать, с таким сетом флагов
>-Wall -Wextra -std=c99 -pedantic
gcc молчит.
>>729503
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 и там много всего еще. Но заметь, никаких преобразований.
>>729536
Толсто.
> по маняопределению.
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 и там много всего еще. Но заметь, никаких преобразований.
>>729536
> Писать надо:
> if (NULL == expression)
Толсто.
Не смог нагуглить, как сделать вывод в консоль,чтоб сверху или снизу выводилась строка состояния, а в остальных строках выводились данные из другого потока и чтоб они не перезаписывали строку состояния в идеале чтоб данные прокручивались а строка состояния была на своем месте
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
По сути мне надо чтоб одна строка уменьшила размер консоли и не обновлялась
Как это гуглить хотя бы?
>>730267
нашел, ncurses
нашел, ncurses
Объясните, в каких случаях принято делать структуру с указателями на функции? Чем обычное объявление функций хуже?
>>730399
1) колбеки в чяужую библиотеку
2) массив функций, вызов по номеру без свитч-кейс без регистрации
3) реализация опенгл под шинду - там по умолчанию изкаробки только фичи из конца девяностых, за нулевыми и десятыми с их шейдерами нужно добывать как руду у драйвера через указатели на функции..
1) колбеки в чяужую библиотеку
2) массив функций, вызов по номеру без свитч-кейс без регистрации
3) реализация опенгл под шинду - там по умолчанию изкаробки только фичи из конца девяностых, за нулевыми и десятыми с их шейдерами нужно добывать как руду у драйвера через указатели на функции..
Привет, анон. Есть какой-то известный быстрый алгоритм для перевода дробной части, записанной в бинарном виде, в строку с десятичной записью? Дробная часть может быть 128 бит, так что, видимо, конвертация в double и печать в строку не катит.
>>733128
Я как-то из интереса попытался на асме написать функцию вывода числа типа 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 и нуля обрабатывать отдельно
Я как-то из интереса попытался на асме написать функцию вывода числа типа 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 и нуля обрабатывать отдельно
>>733499
Блядское форматирование. Фикс.
0,1101 = (1/2) + (1/4) + (1/16) = 0.5 + 0.25 + 0.0625 = (1000×5 + 100×5^2 + 5^4)×10^(-4)
Блядское форматирование. Фикс.
0,1101 = (1/2) + (1/4) + (1/16) = 0.5 + 0.25 + 0.0625 = (1000×5 + 100×5^2 + 5^4)×10^(-4)
>>733607
Можно вкратце, что не так?
Можно вкратце, что не так?
>>733607
Ну, вообще да, с денормализованными числами так не выйдет.
Ну, вообще да, с денормализованными числами так не выйдет.
>>733499
Это да, это понятно, но как это сделать без длинной арифметики (число бит для дробной части у меня большое)?
Я помню, что, например, для перевода из восьмеричной системы в десятичную был довольно элегантный и легковесный алгоритм (в то время как перевод в лоб требовал длинную арифметику для деления и умножения).
>>733607
Ну, тем не менее, это релевантно для чисел с фиксированной точкой, с которыми я и мучаюсь.
Это да, это понятно, но как это сделать без длинной арифметики (число бит для дробной части у меня большое)?
Я помню, что, например, для перевода из восьмеричной системы в десятичную был довольно элегантный и легковесный алгоритм (в то время как перевод в лоб требовал длинную арифметику для деления и умножения).
>>733607
Ну, тем не менее, это релевантно для чисел с фиксированной точкой, с которыми я и мучаюсь.
>>733892
Никак, смирись и пили длинную арифметику. Не так уж это и сложно, можешь в столбик считать, как в школе.
> но как это сделать без длинной арифметики
Никак, смирись и пили длинную арифметику. Не так уж это и сложно, можешь в столбик считать, как в школе.
>>734007
Эх, печаль. Я не спорю, что не сложно, просто для 128 бит это выглядит как оверхед. Ладно, поищу, может, есть ли portable-реализация __int128_t.
Эх, печаль. Я не спорю, что не сложно, просто для 128 бит это выглядит как оверхед. Ладно, поищу, может, есть ли portable-реализация __int128_t.
>>734065
Мне казалось, что даже для float нужен как минимум int512, для хранения 5^n. Хотя, наверняка есть способ попроще.
Мне казалось, что даже для float нужен как минимум int512, для хранения 5^n. Хотя, наверняка есть способ попроще.
Какую книгу можно почитать, новую, по последним стандартам Си? Кернигана и прату читал, но уже прошло много времени, подзабыл ось. Что-то новенького хочется. Подскажите.
>>734324
Дейтелов мб?
Дейтелов мб?
>>711268 (OP)
Есть ли какие то подводные у:
typedef struct {...} struct_name;
Всегда ли можно писать так?
Есть ли какие то подводные у:
typedef struct {...} struct_name;
Всегда ли можно писать так?
>>734855
Единственный подводный - связанные структуры данных (элементы списков, деревьев), для которых ты не сможешь использовать тип, определяемый тайпдефом, внутри этого тайпдефа: typedef struct { ??? ∗next_node; int value; } linked_list_node; ну ты понял. Потому что этот тип на момент использования еще не существует. А вот у typedef struct foo { ... } foo; или typedef struct foo foo; struct foo {}; подводных нет. Второй вариант более многословный, зато позволяет при необходимости быстро отделить интерфейс от реализации: просто оставляешь тайпдеф как есть в .h, а структуру уносишь в .c, и если у тебя все манипуляции идут через указатель на foo, то пользовательский код никогда не узнает, что там внутри.
Единственный подводный - связанные структуры данных (элементы списков, деревьев), для которых ты не сможешь использовать тип, определяемый тайпдефом, внутри этого тайпдефа: typedef struct { ??? ∗next_node; int value; } linked_list_node; ну ты понял. Потому что этот тип на момент использования еще не существует. А вот у typedef struct foo { ... } foo; или typedef struct foo foo; struct foo {}; подводных нет. Второй вариант более многословный, зато позволяет при необходимости быстро отделить интерфейс от реализации: просто оставляешь тайпдеф как есть в .h, а структуру уносишь в .c, и если у тебя все манипуляции идут через указатель на foo, то пользовательский код никогда не узнает, что там внутри.
>>734882
Про связанные списки я знал, а вот за разделение интерфейса и реализации спасибо, не знал.
Про связанные списки я знал, а вот за разделение интерфейса и реализации спасибо, не знал.
>>734886
тащемта, opaque pointers обеспечивают идеальную инкапсуляцию, абсолютно непробиваемую
тащемта, opaque pointers обеспечивают идеальную инкапсуляцию, абсолютно непробиваемую
Как сделать чтобы в выводе консоли изменялись лишь некоторые данные?
Ну допустим Я вывел
Таблица
Счёт: ++variable
И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.
Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
Ну допустим Я вывел
Таблица
Счёт: ++variable
И я хочу чтобы таблица и счёт оставались в выводе, а вот variable постоянно перезаписывалась при увелечнии.
Циклом while каждый раз с нуля выводить всё это маразм мне кажется. Так как это сделать чтобы лишь выбранная часть данных вывода редактировалась?
52 Кб, 512x331>>735128
Вот скрин консольной таблицы из интернета чтобы анонам понятнее было.
Вот допустим это всё вывод моей программы. И мне нужно только чтобы подчёкнутое красным число 10 изменялось, допустим 9 или 11 12 13. При этом чтобы всё таблица не перевыводилась с нуля. Как это сделать?
Вот скрин консольной таблицы из интернета чтобы анонам понятнее было.
Вот допустим это всё вывод моей программы. И мне нужно только чтобы подчёкнутое красным число 10 изменялось, допустим 9 или 11 12 13. При этом чтобы всё таблица не перевыводилась с нуля. Как это сделать?
>>735180
спасибo анчoус.
спасибo анчoус.
>>734345
Я насчитал минимум в 44 байта
Я насчитал минимум в 44 байта
Аноны, без шуток, Сишечка может умереть лет через, скажем, 50? Знаю, тупой вопрос, да и мне к тому времени уже будет похуй, но чисто теоретически интересно.
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Или на ней столько разного софта написано, что легче скинуть очередной Чиксулуб на Землю и выпилить нахер всю цивилизацию, нежели заменить сишечку в системщине?
Вроде пытаются высрать новые, модные, молодежные япы вроде раста, которые пытаются и рыбку съесть, и на хуй сесть, и через N лет заменить старичков С/С++, но чёто как-то хз... Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
>>736782
Проблема с таким далёким будущим — мы даже не можем предсказать, не будет ли через 50 лет ассемблер ниже уровнем чем си, лол.
А вообще, сейчас есть тенденция запихать побольше ядер (т.к. частоты наращивать не получается) и единственное что можно гарантировать — будут востребованы языки хорошо умеющие в мультитрединг. И это явно не си, но и аналоговнет, что называется.
Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст), но переписывать работающий софт который всех и так устраивает — это тупость.
Проблема с таким далёким будущим — мы даже не можем предсказать, не будет ли через 50 лет ассемблер ниже уровнем чем си, лол.
А вообще, сейчас есть тенденция запихать побольше ядер (т.к. частоты наращивать не получается) и единственное что можно гарантировать — будут востребованы языки хорошо умеющие в мультитрединг. И это явно не си, но и аналоговнет, что называется.
>Ведь софта, написанный на С/С++ вряд ли куда-то денется/будет переписываться.
Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст), но переписывать работающий софт который всех и так устраивает — это тупость.
>>736782
Нет, не может, C - это lingua franca программирования.
Нет, не может, C - это lingua franca программирования.
>>736814
Не все так однозначно. Много "безопасных" программ юзают туеву хучу сишных либ. Пример, за котором далеко не надо ходить, Дискорд. Написан на джаваскрипте, гуй - Электрон, но если ты откроешь memory layout процесса - ты увидишь кучу so(в случае с Линуксом)/dll(в случае с виндой), которые написаны на Сях. И там может быть дыра, так что даже такое якобы безопасное приложение уязвимо к атакам на память.
Учитывая, что даже в 2к20 продолжают писать на сях, а не только поддерживать тонну легаси, то хз-хз... При моей жизни Си точно не умрёт.
>Есть смысл новый писать не на сях
Не все так однозначно. Много "безопасных" программ юзают туеву хучу сишных либ. Пример, за котором далеко не надо ходить, Дискорд. Написан на джаваскрипте, гуй - Электрон, но если ты откроешь memory layout процесса - ты увидишь кучу so(в случае с Линуксом)/dll(в случае с виндой), которые написаны на Сях. И там может быть дыра, так что даже такое якобы безопасное приложение уязвимо к атакам на память.
Учитывая, что даже в 2к20 продолжают писать на сях, а не только поддерживать тонну легаси, то хз-хз... При моей жизни Си точно не умрёт.
>>736886
Ну, разница в том, что у тебя вместо 30-ти 0-day CVE будет 15-20, это на самом-то неплохой прогресс как ни крути. А с другой стороны это хорошо так поднимет цены на рынке эксплоитов, хех.
Понятное дело, что они не умрут, на них в конце концов кода куда больше чем на каком нибудь коболе, который все ещё жив спустя 30+ лет умирания, только вот имхо — область точно сузится до переносимого ассемблера. Единственный прогноз, который вообще возможно сделать на эту тему.
Ну, разница в том, что у тебя вместо 30-ти 0-day CVE будет 15-20, это на самом-то неплохой прогресс как ни крути. А с другой стороны это хорошо так поднимет цены на рынке эксплоитов, хех.
Понятное дело, что они не умрут, на них в конце концов кода куда больше чем на каком нибудь коболе, который все ещё жив спустя 30+ лет умирания, только вот имхо — область точно сузится до переносимого ассемблера. Единственный прогноз, который вообще возможно сделать на эту тему.
>>736908
Си и так переносимый ассемблер, алло. Это то, что делает Си неубиваемым ЯПом.
>переносимого ассемблера
Си и так переносимый ассемблер, алло. Это то, что делает Си неубиваемым ЯПом.
>>736975
А ещё на сях и плюсах написано куча софта, который спокойно можно написать и на чём нибудь другом, приём, вас плохо слышно.
Ядром, кодеками и драйверами всё как бы не ограничивается, всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
А ещё на сях и плюсах написано куча софта, который спокойно можно написать и на чём нибудь другом, приём, вас плохо слышно.
Ядром, кодеками и драйверами всё как бы не ограничивается, всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
>>736979
Это едва ли не половина всего софта, написанного на сях.
>всякие юзерлевел хуитки вроде игор, 2/3д редакторов, синтезаторы звуков, либы для гуя и тд итп.
Это едва ли не половина всего софта, написанного на сях.
>>736999
Почти все. Я си с плюсами не различаю в этом вопросе, т.к. любой плюсовый геймдев стоит на куче сишных либ от опенгла до всяких физических движков.
Из именно игр — вроде как автор factorio говорил что она на чистом си написана.
Почти все. Я си с плюсами не различаю в этом вопросе, т.к. любой плюсовый геймдев стоит на куче сишных либ от опенгла до всяких физических движков.
Из именно игр — вроде как автор factorio говорил что она на чистом си написана.
>>737011
После 2000 года все перешли на С++
Ясно
Physx, bullet, havok - все С++.
После 2000 года все перешли на С++
>Я си с плюсами не различаю в этом вопросе
Ясно
>физических движков.
Physx, bullet, havok - все С++.
>>736782
Через 30 лет произойдет коболизация си.
Выжившие сишники будут поддерживать ядро пинус для марсоходов.
Через 30 лет произойдет коболизация си.
Выжившие сишники будут поддерживать ядро пинус для марсоходов.
>>736814
Предсказать, что будет через 50 лет, в принципе невозможно. Разве можно было предсказать хоть примерное развитие современного телекома и программирования в 1970 году? Уильям Гейтс со своими 640 кб оперативы и то позже был.
Сейчас тенденции на смены парадигм. Например, развитие супер параллельных процессоров, нейро-процессоров. Пока диковинка, но за 10 лет может стать чем-то обыденным. Изменения в концепциях написание программ, уход в виртуализацию всего и вся, куча всего ещё.
Нет, не думаю, что C/C++ сохранится. Слишком уж динозавр из другого мира.
Предсказать, что будет через 50 лет, в принципе невозможно. Разве можно было предсказать хоть примерное развитие современного телекома и программирования в 1970 году? Уильям Гейтс со своими 640 кб оперативы и то позже был.
Сейчас тенденции на смены парадигм. Например, развитие супер параллельных процессоров, нейро-процессоров. Пока диковинка, но за 10 лет может стать чем-то обыденным. Изменения в концепциях написание программ, уход в виртуализацию всего и вся, куча всего ещё.
Нет, не думаю, что C/C++ сохранится. Слишком уж динозавр из другого мира.
>>737051
На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Плюсы очень спорное решение на самом деле.
>После 2000 года все перешли на С++
На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Плюсы очень спорное решение на самом деле.
>>737196
Разговор про игоры. Игорей, особенно крупных, на Си давно не пишут.
Разговор про игоры. Игорей, особенно крупных, на Си давно не пишут.
>>737195
Лол, даже ссаный кобол уже лет 30 умирает, но никак не сдохнет, хотя кода на нем написано в десятки тысяч раз меньше, чем на С/С++
И подноготная всей этой параши будет как всегда на С/С++
Скорее джаваскрипт сдохнет в вебе (нет), чем С/С++ в системщине и подноготной всея мира ойти технологий
>Нет, не думаю, что C/C++ сохранится
Лол, даже ссаный кобол уже лет 30 умирает, но никак не сдохнет, хотя кода на нем написано в десятки тысяч раз меньше, чем на С/С++
>развитие супер параллельных процессоров, нейро-процессоров
И подноготная всей этой параши будет как всегда на С/С++
Скорее джаваскрипт сдохнет в вебе (нет), чем С/С++ в системщине и подноготной всея мира ойти технологий
>>737223
Кобол уже 30 лет назад сдох, просто где-то до сих под используется древний софт на древних компах или их эмуляторах.
Само собой, сишечка полностью не сдохнет. Хотя бы потому, что ядра ОС и кучи системного софта на ней написаны, которые работают хорошо, исправно, и свои задачи прекрасно выполняют.
Но само программирование может драматически измениться с тем, как поменяются парадигмы программирования.
Тупо сишечка и плюсы плохо предназначены для многопоточного программирования. А эволюция очевидно идёт в направлении супер-многопоточного программирования. Потому что возможности одного ядра давно исчерпаны, по мелочам как-то оптимизируют, зато вот возможностей для увеличения количества ядер очень и очень много. Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер (блядь, кто-нибудь в 70-е годы мог предсказать микро-сд карты на сотни гигабайт за копейки?), но для этого надо принципиально менять парадигмы программирования и платформы.
Это неизбежно произойдёт. Но как именно это будет выглядеть невозможно предсказать.
Кобол уже 30 лет назад сдох, просто где-то до сих под используется древний софт на древних компах или их эмуляторах.
Само собой, сишечка полностью не сдохнет. Хотя бы потому, что ядра ОС и кучи системного софта на ней написаны, которые работают хорошо, исправно, и свои задачи прекрасно выполняют.
Но само программирование может драматически измениться с тем, как поменяются парадигмы программирования.
Тупо сишечка и плюсы плохо предназначены для многопоточного программирования. А эволюция очевидно идёт в направлении супер-многопоточного программирования. Потому что возможности одного ядра давно исчерпаны, по мелочам как-то оптимизируют, зато вот возможностей для увеличения количества ядер очень и очень много. Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер (блядь, кто-нибудь в 70-е годы мог предсказать микро-сд карты на сотни гигабайт за копейки?), но для этого надо принципиально менять парадигмы программирования и платформы.
Это неизбежно произойдёт. Но как именно это будет выглядеть невозможно предсказать.
>>735075
А надо сразу уточнять тогда, здесь провидцев нет.
А надо сразу уточнять тогда, здесь провидцев нет.
>>737294
Пруф? Пока выглядит как высер, не обессудь.
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Пруф? Пока выглядит как высер, не обессудь.
>>737196
Фантазии. Отдельные чудаки могут писать на чем угодно, но стандарт индустрии - с++ и с#.
>На самом деле нет, и после 2010 масса проектов или их частей стартовала на чистом Си без плюсов.
Фантазии. Отдельные чудаки могут писать на чем угодно, но стандарт индустрии - с++ и с#.
>>737294
Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
Отлично приспособлены, ничуть не хуже любого другого языка.
>Ничто не мешает в будущем иметь не то, что тысячи, а реально даже миллионы ядер
Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
>Тупо сишечка и плюсы плохо предназначены для многопоточного программирования.
Отлично приспособлены, ничуть не хуже любого другого языка.
>>737306
С гигагерцами ПОКА есть проблемы, количество транзисторов на кристалл до сих пор растёт по экспоненте.
https://youtu.be/c01BlUDIlK4
>Физика мешает, так же как и мешает иметь процессоры на миллионы гигагерц.
С гигагерцами ПОКА есть проблемы, количество транзисторов на кристалл до сих пор растёт по экспоненте.
https://youtu.be/c01BlUDIlK4
>>736814
Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело.
Раст не даёт той безопастности, о которой ты говоришь и думаешь.
Всё так, а ещё большая тупость - менять коней на переправе.
>будут востребованы языки хорошо умеющие в мультитрединг.
Проблема не только в языках, mpc - это вообще говоря другая область, говоря проще не в языке тут вообще дело.
>Есть смысл новый писать не на сях если есть аналоги получше (например, если у тебя главная цель — это безопасность, то почему бы и не взять раст)
Раст не даёт той безопастности, о которой ты говоришь и думаешь.
>но переписывать работающий софт который всех и так устраивает — это тупость.
Всё так, а ещё большая тупость - менять коней на переправе.
>>737305
Во влажных фантазиях M$-фанбоев, клепающих миллионный по счёту три-в-ряд.
> стандарт индустрии - с#
Во влажных фантазиях M$-фанбоев, клепающих миллионный по счёту три-в-ряд.
>>737362
В середине нулевых был достигнут современный уровень, 3.5 GHz, на процессоре пентиум-4. Дальше он не рос, производительность увеличивалась за счёт качества архитектуры, а не тактовой частоты. Зачастую тактовая частота снижалась, а потом заново увеличивалась.
А вот количество транзисторов до сих пор растёт по экспоненте. Усложняли ядра, добавляли кеш-память, добавляют ядра. AMD уже разродился процом на 64 ядра. На видеокартах тысячи примитивных ядер, есть ai-ускорители на тысячи ядер.
Ничто не мешает в принципе сделать и миллион ядер. Пока немного не хватает технологий для этого. Но развитие идёт к тому, чтобы поддерживать массовую параллельность. А от языка требуется, чтобы он нативно удобно поддерживал массовую параллельность, как в гошечке это есть.
>С гигагерцами ПОКА есть проблемы
В середине нулевых был достигнут современный уровень, 3.5 GHz, на процессоре пентиум-4. Дальше он не рос, производительность увеличивалась за счёт качества архитектуры, а не тактовой частоты. Зачастую тактовая частота снижалась, а потом заново увеличивалась.
А вот количество транзисторов до сих пор растёт по экспоненте. Усложняли ядра, добавляли кеш-память, добавляют ядра. AMD уже разродился процом на 64 ядра. На видеокартах тысячи примитивных ядер, есть ai-ускорители на тысячи ядер.
Ничто не мешает в принципе сделать и миллион ядер. Пока немного не хватает технологий для этого. Но развитие идёт к тому, чтобы поддерживать массовую параллельность. А от языка требуется, чтобы он нативно удобно поддерживал массовую параллельность, как в гошечке это есть.
>>711268 (OP)
Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART? Мне нужен элементарный flow controi, т.к. апапартной поддержки нет, а софтварный XON/XOFF очевидно не подходит из-за "бинарности" отправляемого файла. Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе если бы не это, то уже давно навасянил бы какое-то кастомное простое говно
Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART? Мне нужен элементарный flow controi, т.к. апапартной поддержки нет, а софтварный XON/XOFF очевидно не подходит из-за "бинарности" отправляемого файла. Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе если бы не это, то уже давно навасянил бы какое-то кастомное простое говно
>>737433
Вот это уровень дискуссии, высрал хуйню, потом почувствовал себя затралленым — и начал репортить)0
Можно засчитывать слив питушку.
Вот это уровень дискуссии, высрал хуйню, потом почувствовал себя затралленым — и начал репортить)0
Можно засчитывать слив питушку.
Мочер, а ты сам-то хоть читаешь что трешь?
>>737692
zmodem
>Анон, какой протокол лучше всего заюзать чтобы отправлять бинарные файлы по UART
>Главное требование - поддержка протокола многими существующими утилитами на винде/линуксе
zmodem
>>737662
А ты видео то смотрел? С увеличением кол-ва ядер увеличивается сложность алгоритмов, затраты на планировку и вообще при таком количестве ядер, все алгоритмы поломаются и просто перестанут работать без должных оптимизаций.
> Ничто не мешает в принципе сделать и миллион ядер
А ты видео то смотрел? С увеличением кол-ва ядер увеличивается сложность алгоритмов, затраты на планировку и вообще при таком количестве ядер, все алгоритмы поломаются и просто перестанут работать без должных оптимизаций.
>>738583
в треде о том и разговор, что в ситуации, когда рост производительности идёт в многопоточном плане, без роста однопоточной производительности, нужно а) использовать другие алгоритмы б) использовать инструменты, языки и стили программирования которые (лучше) позволяют автоматически параллелизовывать написанное. Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
>все алгоритмы поломаются и просто перестанут работать без должных оптимизаций
в треде о том и разговор, что в ситуации, когда рост производительности идёт в многопоточном плане, без роста однопоточной производительности, нужно а) использовать другие алгоритмы б) использовать инструменты, языки и стили программирования которые (лучше) позволяют автоматически параллелизовывать написанное. Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
>>738613
Звучит правдоподобно.
>Ну тип, если функцианальник и часто испольешь мапы в своём коде, его легко автоматически параллелизовать. А если любишь циклы в стиле си - сосёшь дупу на единственном из килоядер.
Звучит правдоподобно.
>>737875
Слишком сложно или нет? я хуй его знает, загуглил готовые реализации - вроде очень много кода
Слишком сложно или нет? я хуй его знает, загуглил готовые реализации - вроде очень много кода
>>738713
bitches dunno bout mah #pragma omp for
bitches dunno bout mah #pragma omp for
>>738613
То это говно на списках создает кучу cache miss'ов и прочего говна. А если заюзал pragma omp parallel for, то все просто и понятно
>Ну тип, если функцианальник и часто испольешь мапы в своём коде
То это говно на списках создает кучу cache miss'ов и прочего говна. А если заюзал pragma omp parallel for, то все просто и понятно
>>738583
В том-то и задача языка, чтобы сделать программирование таких алгоритмов и задач лёгким и непринуждённым.
Си слишком дубовый, слишком явный и низкоуровневый. Иногда это хорошо, для каких-то системных задач, но иногда нет.
Возможности для конкурентности сильно ограничены из-за этого.
В Го отдельный тред-поток исполнения запускается просто оперетором "go", удобные каналы и агрегаторы каналов (селекты). Не нужно думать, что там внутри, не нужно детально прорабатывать схему распараллеливания, не нужно всяких #pragma-костылей. Просто запускается отдельный поток. Ты уже просто думаешь на языке потоков и корутин. В си так просто не получится. И сам язык внутри для таких задач не предназначен.
Если язык не предназначен, то значит разработчик будет максимально избегать подобных подходов.
Это просто один из примеров. Го мне не нравится, но эта концепция явно хорошая и удобная, думаю будет заимствована языками следующего поколения.
В том-то и задача языка, чтобы сделать программирование таких алгоритмов и задач лёгким и непринуждённым.
Си слишком дубовый, слишком явный и низкоуровневый. Иногда это хорошо, для каких-то системных задач, но иногда нет.
Возможности для конкурентности сильно ограничены из-за этого.
В Го отдельный тред-поток исполнения запускается просто оперетором "go", удобные каналы и агрегаторы каналов (селекты). Не нужно думать, что там внутри, не нужно детально прорабатывать схему распараллеливания, не нужно всяких #pragma-костылей. Просто запускается отдельный поток. Ты уже просто думаешь на языке потоков и корутин. В си так просто не получится. И сам язык внутри для таких задач не предназначен.
Если язык не предназначен, то значит разработчик будет максимально избегать подобных подходов.
Это просто один из примеров. Го мне не нравится, но эта концепция явно хорошая и удобная, думаю будет заимствована языками следующего поколения.
Котаны, мне нужно передать в функцию указатель на буфер с данными типа uint8_t. А в функции я хочу изменить значение этого указателя так, чтобы он изменился и на верхнем уровне. Т.е. я хочу сделать
uint8_t* p_frame = NULL;
func(p_frame);
И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
uint8_t* p_frame = NULL;
func(p_frame);
И чтобы после вызова func указатель p_frame изменился на тот, который я укажу внутри функции. Как это можно сделать?
>>739221
-вернуть адрес из функции:
uint_t func(uint8_t); //прототип
p_frame=func(p_frame);
-передать указатель на адрес:
func(uint8_t); //прототип
func(&p_frame);
В обоих случаях потребуется изменять декларацию функции. А вот как без изменений - хз.
-вернуть адрес из функции:
uint_t func(uint8_t); //прототип
p_frame=func(p_frame);
-передать указатель на адрес:
func(uint8_t); //прототип
func(&p_frame);
В обоих случаях потребуется изменять декларацию функции. А вот как без изменений - хз.
>>739221
Так себе подход, очень опасный в плане выстрелов в ногу
Сделай либо p_name = func(p_frame); либо
func(p_frame, &p_name);
Так себе подход, очень опасный в плане выстрелов в ногу
Сделай либо p_name = func(p_frame); либо
func(p_frame, &p_name);
>>739186
Скорее всего да, лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?: и непонятно чего ты хочешь
Скорее всего да, лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?: и непонятно чего ты хочешь
>>739269
Я уже возвращаю длину буфера этой же функцией, просто я упростил для примера
Мне нужно именно чтобы p_frame принял значение, вычисленное внутри. Больше мне ничего от функции не надо, только адрес буфера в памяти и длина буфера. В лоб можно было бы конечно передавать указатель на длину буфера как аргумент, а возвращать адрес. Я подумаю над этим.
А в чем опасность? Запутаюсь потом на верхнем уровне в указателях?
> p_name = func(p_frame)
Я уже возвращаю длину буфера этой же функцией, просто я упростил для примера
> func(p_frame, &p_name);
Мне нужно именно чтобы p_frame принял значение, вычисленное внутри. Больше мне ничего от функции не надо, только адрес буфера в памяти и длина буфера. В лоб можно было бы конечно передавать указатель на длину буфера как аргумент, а возвращать адрес. Я подумаю над этим.
А в чем опасность? Запутаюсь потом на верхнем уровне в указателях?
>>739221
Верни число обработанных байт и прибавь потом к указателю.
&p передавать не оче хорошо, потому что компилятор свалит p на стек.
Верни число обработанных байт и прибавь потом к указателю.
&p передавать не оче хорошо, потому что компилятор свалит p на стек.
>>739282
Ну я про такое вот индексирование в духе lea.
Всё что слева от знака вопроса - кондишн.
передать нужный индекс.
>Скорее всего да,
Ну я про такое вот индексирование в духе lea.
>лучше уж явно выдели скобками порядок операторов, потому что у && приоритет больше чем у ?:
Всё что слева от знака вопроса - кондишн.
>и непонятно чего ты хочешь
передать нужный индекс.
>>738797
нормальный компилятор со статическим анализатором видит, что у тебя список - не список(не нужна динамическая вставка т проч) и переделывает в массив. Плюс, ВНЕЗАПНО, мап может работать и на массивах и вообще на любых коллекциях. Далее, если у тебя на каждый кусок приличное независимое вычисление (вместо последовательности мапов ты сделал мап композиции функциий, кэш мисс твой нивелируется).
>То это говно на списках создает кучу cache miss'ов и прочего говна
нормальный компилятор со статическим анализатором видит, что у тебя список - не список(не нужна динамическая вставка т проч) и переделывает в массив. Плюс, ВНЕЗАПНО, мап может работать и на массивах и вообще на любых коллекциях. Далее, если у тебя на каждый кусок приличное независимое вычисление (вместо последовательности мапов ты сделал мап композиции функциий, кэш мисс твой нивелируется).
>>739525
Эту мантру повторяют со времен Коммон Лиспа. До сих пор компиляторы тупят.
>нормальный компилятор ... видит ... переделывает
Эту мантру повторяют со времен Коммон Лиспа. До сих пор компиляторы тупят.
>>738839
Опять ньюфаги путают Concurrency и Parallelism. Иди кури мат. часть, а потом высирай тонны текста на двачах.
Опять ньюфаги путают Concurrency и Parallelism. Иди кури мат. часть, а потом высирай тонны текста на двачах.
Анон, объясни, почему язык строился вокруг такой ебанутой системы типов? Как можно было додуматься до этого монстра: unsigned long long int, а не стартовать изначально с типов фиксированной длинны (которые и записываются гораздо короче)?
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?
Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
Мне просто интересно, чем это было вызвано. Да, я понимаю, что тогда был целый зоопарк платформ, где были и байты по шесть бит, и слова по три байта, но всё равно не понятно, чем в этом случае принципиально хуже иметь по дефолту условный int32_t?
Еще куча других вопросов подобных. Например, почему нет отдельных операторов логических и арифметических сдвигов до сих пор, блять, хотя языку уже давно не первый десяток лет, но это уже другая история.
>>738613
Найс аутотренинг. А нахуя ты свое /go/вно то здесь пиаришь? У меня и с плюсами процессоры не простаивают, есть корутины и тредпулы. Для Си умельцы скорее всего тоже либ уже налепили.
Найс аутотренинг. А нахуя ты свое /go/вно то здесь пиаришь? У меня и с плюсами процессоры не простаивают, есть корутины и тредпулы. Для Си умельцы скорее всего тоже либ уже налепили.
>>739807
А чего ты хочешь от переносимого ассемблера? 0 абстракции в случае с си — это же фича, лол.
А чего ты хочешь от переносимого ассемблера? 0 абстракции в случае с си — это же фича, лол.
>>739817
Так тут как раз и не 0 абстракции. Если бы типы были привязаны к байтам/словам/dword и прочее, то да. Но вместо этого преподносится лажа какая-то с замысловатыми плавающими ограничениями на размер. В итоге это нихрена не переносимый ассемблер. Но одной платформе int один, на другой - иного размера.
Так тут как раз и не 0 абстракции. Если бы типы были привязаны к байтам/словам/dword и прочее, то да. Но вместо этого преподносится лажа какая-то с замысловатыми плавающими ограничениями на размер. В итоге это нихрена не переносимый ассемблер. Но одной платформе int один, на другой - иного размера.
>>739807
Что тебе мешает пользоваться типами из stdint.h, которые тебе гарантируют одинаковый размер переменной на всех платформах?
Что тебе мешает пользоваться типами из stdint.h, которые тебе гарантируют одинаковый размер переменной на всех платформах?
>>739839
Ничто не мешает. Вопрос, почему это не по дефолту, а по дефолту какой-то франкенштейн.
Ничто не мешает. Вопрос, почему это не по дефолту, а по дефолту какой-то франкенштейн.
>>739842
По причинам которые ты не знаешь, а администрация языка перед тобой отчитываться не будет. Кем ты себя возомнил, чучело?
По причинам которые ты не знаешь, а администрация языка перед тобой отчитываться не будет. Кем ты себя возомнил, чучело?
>>739842
Потому что гладиолус.
Почему в Си нет проверки границ массивов, хотя эта операция ничего не стоит по рантайму и дает защиту от глупых ошибок? Потому что такой язык как Си дает тебе МИНИМАЛЬНУЮ абстракцию над голыми инструкциями, которые исполняет процессор. Читай, язык полностью полагается на программиста, ты сам выбираешь способ отстрелить себе ногу к хуям собачьим обрабатывать данные, выбирать типы переменных, работать с памятью и т.п. Минимум ограничений - кредо этих языков.
Тупо? Бесспорно. Но парадокс - на С/С++ (особеноо на С) держится весь мир компьютерных технологий, вся подноготная 98% технологий крутится на этих языках. Это как рак, который пустил метастазы до того, как его успели убить. Теперь хуй убьют, лол.
Потому что гладиолус.
Почему в Си нет проверки границ массивов, хотя эта операция ничего не стоит по рантайму и дает защиту от глупых ошибок? Потому что такой язык как Си дает тебе МИНИМАЛЬНУЮ абстракцию над голыми инструкциями, которые исполняет процессор. Читай, язык полностью полагается на программиста, ты сам выбираешь способ отстрелить себе ногу к хуям собачьим обрабатывать данные, выбирать типы переменных, работать с памятью и т.п. Минимум ограничений - кредо этих языков.
Тупо? Бесспорно. Но парадокс - на С/С++ (особеноо на С) держится весь мир компьютерных технологий, вся подноготная 98% технологий крутится на этих языках. Это как рак, который пустил метастазы до того, как его успели убить. Теперь хуй убьют, лол.
>>739932
Тащемта, да.
Тащемта, да.
>>739935
Имелось в виду, что при современных мощностях сравнение - ничтожная операция по рантайм футпринту, отсутствие которого может привести к багу, который можно превратить в произвольное исполнение кода. Сам выбирай что важнее, учитывая современное железо.
Имелось в виду, что при современных мощностях сравнение - ничтожная операция по рантайм футпринту, отсутствие которого может привести к багу, который можно превратить в произвольное исполнение кода. Сам выбирай что важнее, учитывая современное железо.
>>739932
Ну так-то да. Си - это по сути кроссплатформенный ассемблер, а в языке ассемблера не место большому количеству абстракций (разве что над голыми битами, лол).
Ну так-то да. Си - это по сути кроссплатформенный ассемблер, а в языке ассемблера не место большому количеству абстракций (разве что над голыми битами, лол).
>>739943
И что с чем сравнивать, если у тебя функция принимает указатель неизвестно на который алимент массива?
Если передавать "дескрипторы" вместо указателей, как в Эльбрусах, то это не совсем ничтожные расходы.
>при современных мощностях сравнение - ничтожная операция
И что с чем сравнивать, если у тебя функция принимает указатель неизвестно на который алимент массива?
Если передавать "дескрипторы" вместо указателей, как в Эльбрусах, то это не совсем ничтожные расходы.
>>739958
Современное железо это компенсирует с лихвой. Сишка нужна в эмбедщине, где жетские ограничения ресурсов - бесспорно. Но в мощнейших махинах это только открывает огромный attack surface.
Хотя альтернатив нет. Мы не живем в мире с розовыми пони, где высирают такое чудо техники, как Раст, и который быренько за 5 лет заменяет все наследние С/С++. Реальность куда более жестока и несправедлива.
С другой стороны, мб это и к лучшему, потому что UB - это весело, хоть и небезопасно. Сама возможность произвольно исполнить код на машине, а тем более удаленной, будоражит меня. И без С/С++ наследия это вряд ли было частью реальности.
Современное железо это компенсирует с лихвой. Сишка нужна в эмбедщине, где жетские ограничения ресурсов - бесспорно. Но в мощнейших махинах это только открывает огромный attack surface.
Хотя альтернатив нет. Мы не живем в мире с розовыми пони, где высирают такое чудо техники, как Раст, и который быренько за 5 лет заменяет все наследние С/С++. Реальность куда более жестока и несправедлива.
С другой стороны, мб это и к лучшему, потому что UB - это весело, хоть и небезопасно. Сама возможность произвольно исполнить код на машине, а тем более удаленной, будоражит меня. И без С/С++ наследия это вряд ли было частью реальности.
76 Кб, 772x835>>739967
Железо ничего никогда не компенсирует, оно просто может выполнить кое-что параллельно за счет большей стоимости разработки и большей потребляемой мощности.
>Современное железо это компенсирует с лихвой.
Железо ничего никогда не компенсирует, оно просто может выполнить кое-что параллельно за счет большей стоимости разработки и большей потребляемой мощности.
>>739975
И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов? Офк они не такие быстрые, как они, порой софт, написанный на них, ползет как дерьмо, но порой и нет. И ничего, юзают. В 80ых такое было нереально и засим вся прикладуха писалась на сях. Даже в 90ых годах это было нередкостью, хотя та же безопасная в плане памяти джава с рождения жестко хайпанула. А все из-за тогдашних мощностей. Сейчас это частично нивелируется современным железом, поэтому каждый второй софт на прикладном уровне высран на скриптопараше вроде жса (привет обрыганскому Электрону)
И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов? Офк они не такие быстрые, как они, порой софт, написанный на них, ползет как дерьмо, но порой и нет. И ничего, юзают. В 80ых такое было нереально и засим вся прикладуха писалась на сях. Даже в 90ых годах это было нередкостью, хотя та же безопасная в плане памяти джава с рождения жестко хайпанула. А все из-за тогдашних мощностей. Сейчас это частично нивелируется современным железом, поэтому каждый второй софт на прикладном уровне высран на скриптопараше вроде жса (привет обрыганскому Электрону)
>>739988
быстрофикс
В STL границы буферов таки чекаются, если делать это через кошерный метод at(), а не через оператор [], что есть сахар над арифметикой указателей без каких-либо проверок.
быстрофикс
В STL границы буферов таки чекаются, если делать это через кошерный метод at(), а не через оператор [], что есть сахар над арифметикой указателей без каких-либо проверок.
>>739988
Они проверяют потому, что (1) в них нет указателей, (2) они и так требуют много накладных расходов (удалены от железа).
>И именно поэтому все релевантные языка программирования, кроме С/С++, проверяют границы массивов?
Они проверяют потому, что (1) в них нет указателей, (2) они и так требуют много накладных расходов (удалены от железа).
>>739997
Мораль басни была в другом - на прикладном уровне всем похуй на сверхпердольные оптимизации. Почему? Да блять потому, что железо 2к20 года != железо 1987 года. Вот и все. В системщине - да, бесспорно, но системщиной мир компьютерных технологий не ограничивается.
В расте есть указатели, но там это проверяется, и при этом это системный ЯП. И только не заводи пластинку про unsafe, это смешно.
Мораль басни была в другом - на прикладном уровне всем похуй на сверхпердольные оптимизации. Почему? Да блять потому, что железо 2к20 года != железо 1987 года. Вот и все. В системщине - да, бесспорно, но системщиной мир компьютерных технологий не ограничивается.
>в них нет указателей
В расте есть указатели, но там это проверяется, и при этом это системный ЯП. И только не заводи пластинку про unsafe, это смешно.
>>740007
Только ведь и задачи 2020 != задачи 1987.
Пиши правильно: мне похуй, потому что я пишу хелловорлды.
> железо 2к20 года != железо 1987 года
Только ведь и задачи 2020 != задачи 1987.
> всем похуй на сверхпердольные оптимизации
Пиши правильно: мне похуй, потому что я пишу хелловорлды.
Блять, вопрос не про границы массива вообще был. Как использование unsigned long long вместо uint64_t влияет на производительность? Ебом токнулись? Вопрос в том, почему этл мерзкое решение задизайнили по дефолту? Мне просто интересны причины. В чисто исторических целях, так сказать.
>>740178
По факту ничем не отличается. По задумке — I'll зависит от платформы, uint64 всегда 64
По факту ничем не отличается. По задумке — I'll зависит от платформы, uint64 всегда 64
>>740178
Именно это - никак. А вот unsigned long может быть 32 или 64 бита, при этом твой код вполне переносим, потому что меньше 32 бит оно быть не может. А вот если напишешь uint64_t, и твой код на 32-битном проце будет тормозить из-за необходимости обеспечивать ненужную тебе по сути 64-битную арифметику путем ебли двух регистров одновременно. На самом деле в stdint есть int_fast типы и int_least типы, вот они норм, и их стоило запилить изначально. А фиксированные нужны, только если ты структуры упакованные в файл пишешь, или у тебя ограничения по памяти.
> Как использование unsigned long long вместо uint64_t влияет на производительность
Именно это - никак. А вот unsigned long может быть 32 или 64 бита, при этом твой код вполне переносим, потому что меньше 32 бит оно быть не может. А вот если напишешь uint64_t, и твой код на 32-битном проце будет тормозить из-за необходимости обеспечивать ненужную тебе по сути 64-битную арифметику путем ебли двух регистров одновременно. На самом деле в stdint есть int_fast типы и int_least типы, вот они норм, и их стоило запилить изначально. А фиксированные нужны, только если ты структуры упакованные в файл пишешь, или у тебя ограничения по памяти.
>>740184
ull* фикс
ull* фикс
>>740180
Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
>>740188
Потому что на тот момент, когда это делали, вариантов было меньше. Это сейчас у нас интов дохуя развелось больше, чем в stdint есть, а раньше или long, или short были алиасом для int.
Потому что на тот момент, когда это делали, вариантов было меньше. Это сейчас у нас интов дохуя развелось больше, чем в stdint есть, а раньше или long, или short были алиасом для int.
>>740191
Ну ты же знаешь, что на VAX int = long = 32 бита, а потом придумали long long, чтобы получить 64 бита без конфликта с существующими идентификаторами.
>Длинные названия типов, размер которых (хотя бы минимальный) непонятен из самого имени.
Ну ты же знаешь, что на VAX int = long = 32 бита, а потом придумали long long, чтобы получить 64 бита без конфликта с существующими идентификаторами.
>>711268 (OP)
С какими значениями -O, -march и/или -mtune нужно компилировать программу, чтобы бинарники работали на всех среднестатестических убунтах?
С какими значениями -O, -march и/или -mtune нужно компилировать программу, чтобы бинарники работали на всех среднестатестических убунтах?
>>740740
-march=nocona
-march=nocona
>>740007
Я не понял, зачем вам границы массива? Если надо размер, чтобы не пройти итератором за пределы массива, то для вас есть sizeof, если не надо, то с чего бы он был по дефолту? Как программа вообще узнает вышла она за границы массива или не вышла, если она просто читает из памяти подряд? Это типа надо границы массива помечать как-то в памяти что ли? Особой комбинацией нулей и едениц? Как вы вообще себе представляете границы массива в памяти?
Я не понял, зачем вам границы массива? Если надо размер, чтобы не пройти итератором за пределы массива, то для вас есть sizeof, если не надо, то с чего бы он был по дефолту? Как программа вообще узнает вышла она за границы массива или не вышла, если она просто читает из памяти подряд? Это типа надо границы массива помечать как-то в памяти что ли? Особой комбинацией нулей и едениц? Как вы вообще себе представляете границы массива в памяти?
>>741052
На самом деле bounds checking для отладки много где есть. Если писать говнокод или просто на отъебись - очень помогает.
fat pointers или таблицы, как для виртуальной памяти в процессорах.
> Я не понял, зачем вам границы массива?
На самом деле bounds checking для отладки много где есть. Если писать говнокод или просто на отъебись - очень помогает.
> Как вы вообще себе представляете границы массива в памяти?
fat pointers или таблицы, как для виртуальной памяти в процессорах.
>>741052
Да, проверка на выход за границу по длине.
Наверное потому работа с памятью одна из самых частых ошибок?
Да, проверка на выход за границу по длине.
> если не надо, то с чего бы он был по дефолту
Наверное потому работа с памятью одна из самых частых ошибок?
>>741057
Си не прощает ошибок в любом случае. Тем более когда ты работаешь напрямую с микроконтроллером.
>Наверное потому работа с памятью одна из самых частых ошибок?
Си не прощает ошибок в любом случае. Тем более когда ты работаешь напрямую с микроконтроллером.
>>741067
Никто его не хайпет кроме отдельных сектантов. Здесь вот один растошизик срет в С и С++ тредах.
Никто его не хайпет кроме отдельных сектантов. Здесь вот один растошизик срет в С и С++ тредах.
16 Кб, 608x499>>741067
Так и Си позволяет. Но Си еще много чего позволяет там, где в расте нужно писать заклинание на страницу, чтобы его величество компилятор дозволил.
> потому что он такие ошибки позволяет исключать
Так и Си позволяет. Но Си еще много чего позволяет там, где в расте нужно писать заклинание на страницу, чтобы его величество компилятор дозволил.
>>741083
Даладна.
А ещё можно просто код без ошибок писать. Вопрос только в том насколько распространено это юзается.
Даладна.
А ещё можно просто код без ошибок писать. Вопрос только в том насколько распространено это юзается.
>>741088
Да очень многие используют и статический анализ, и санитайзеры, и анальные стандарты типа мисры. Ты по опенсорсу-то не суди.
Да очень многие используют и статический анализ, и санитайзеры, и анальные стандарты типа мисры. Ты по опенсорсу-то не суди.
>>741111
Я читал, что пишут майки о сервелате, этого достаточно.
Я читал, что пишут майки о сервелате, этого достаточно.
>>741168
ну, сишка действительно четче по хардкору поясняет за хромосомное неумение, а не разматывает темплейты на двадцать экранов, но почему хардварный фейл к крестам ближе?
ну, сишка действительно четче по хардкору поясняет за хромосомное неумение, а не разматывает темплейты на двадцать экранов, но почему хардварный фейл к крестам ближе?
>>741052
У любого буфера есть размер при его аллокации. При любом доступе к памяти а-ля буффер + оффсет можно проверять туда ли пишут/оттуда ли читают или нет. Дешевая же операция, камон.
>>741071
Я не растошизик, но мелкософт очень хвалят раст и хотят на него переписывать винду, например. Максимум за 10 лет управятся. А вот Торвальдс ретроград, Линукс доталого будет на сишечке.
Но зато будет забавно, без дыр в памяти мир сер и скучен, есть в этом некая романтика, которую рано или поздно убьет технологический прогресс (надеюсь, когда я уже буду пенсионером)
У любого буфера есть размер при его аллокации. При любом доступе к памяти а-ля буффер + оффсет можно проверять туда ли пишут/оттуда ли читают или нет. Дешевая же операция, камон.
>>741071
Я не растошизик, но мелкософт очень хвалят раст и хотят на него переписывать винду, например. Максимум за 10 лет управятся. А вот Торвальдс ретроград, Линукс доталого будет на сишечке.
Но зато будет забавно, без дыр в памяти мир сер и скучен, есть в этом некая романтика, которую рано или поздно убьет технологический прогресс (надеюсь, когда я уже буду пенсионером)
>>741274
Ааа, да ты тот второй растошизик который форсит Rust у Microsoft. Ну так вот любые пруфы то мб будут? А я могу тебе прям сейчас ответить: раста не будет. Почему? Потому что им проще расширить компилятор С++ для фикса общих ошибок и спроектировать новый безопасный апи, чем они собственно и занимаются с огромным успехом. Кроме того, ты хоть осознаешь все масштабы операционной системы? А я тебе скажу, 6млн. исходных файлов. Можешь представить сколько там LOC? Я вот не могу.
Ааа, да ты тот второй растошизик который форсит Rust у Microsoft. Ну так вот любые пруфы то мб будут? А я могу тебе прям сейчас ответить: раста не будет. Почему? Потому что им проще расширить компилятор С++ для фикса общих ошибок и спроектировать новый безопасный апи, чем они собственно и занимаются с огромным успехом. Кроме того, ты хоть осознаешь все масштабы операционной системы? А я тебе скажу, 6млн. исходных файлов. Можешь представить сколько там LOC? Я вот не могу.
а может такое быть, чтобы strerror(errno) выдавал неправильный указатель? я просто смотрю в gdb, и там какая-то хуйня.
надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
надеюсь он внутри не вызвал функцию определённую мной - но они же должны их прятать, о публичных из posix у меня вроде нет - как это проверять?. ещё я в дебаггере не очень.
>>741274
Нет, нельзя, производительности придет конец.
>При любом доступе к памяти а-ля буффер + оффсет можно проверять
Нет, нельзя, производительности придет конец.
>>715435
Смотри: есть целые числа (инты, например) и дробные (float).
Целые числа всегда делятся нацело, т.е. 100/6=16, а твое 5/1000=0. Дробные числа делятся примерно так же, как в школе, т.е. 100.0f/6=16.666..., ну и для 5f/1000 аналогично.
У тебя в формуле правый множитель будет равен -1 (сам сообразишь почему).
Как избавиться? Внутри формулы юзай флоаты или даблы (в зависимости от требуемой точности), а потом кастуй к своему инту.
Смотри: есть целые числа (инты, например) и дробные (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, но это костыль костыля, как мне кажется. Как компилять либу на винде?
>>741274
Когда все проверяется в черном ящике каждый раз без исключения - эта а приори не оптимизированный код. segment-naebnulsa-safe контейнер - не экстрасенс какой-то, чтоб проанализировать вызывающий алгоритм на инвариативность условия, что индекс меньше размера, стало быть говно.
Когда все проверяется в черном ящике каждый раз без исключения - эта а приори не оптимизированный код. segment-naebnulsa-safe контейнер - не экстрасенс какой-то, чтоб проанализировать вызывающий алгоритм на инвариативность условия, что индекс меньше размера, стало быть говно.
>>741274
Да и хули толку, что рантайм ошибки не будет, если алгоритм все равно по факту обосрался с индексацией и задачу не выполнил? Все равно руками проверять, раз на то пошло.
Да и хули толку, что рантайм ошибки не будет, если алгоритм все равно по факту обосрался с индексацией и задачу не выполнил? Все равно руками проверять, раз на то пошло.
>>741274
Есть тяжелые структуры данных, вся жизнь которых сводится к хождению по индексам на индексы через индексы, и если всрать в реализацию безопасные массивы, время основных операций в такой системе вырастет не на какую-то там
а пропорционально, то есть в разы
Есть тяжелые структуры данных, вся жизнь которых сводится к хождению по индексам на индексы через индексы, и если всрать в реализацию безопасные массивы, время основных операций в такой системе вырастет не на какую-то там
>дешевая же операция, камон
а пропорционально, то есть в разы
374 Кб, 750x792Привет. Чарльз Петцольд в своей книге утверждает, что количество адресуемой памяти влияет на скорость процессора аргументируя тем что на пике. Читаю и не пойму что он имел в виду. Может кто шарит? Тред ассемблерщиков пустует, там решил не спрашивать.
>>741626
шиза какая-то
шиза какая-то
>>741300
Я не имел в виду только аллокацию памяти на куче, в мире микроконтроллеров это, в большинстве своем, непозволительная роскошь, ибо ресурсов маловато даже для обрыганского аллокатора памяти и менеджера кучи.
Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
Произошла аллокация статического 16-ти байтового буфера на стэке.
Как тогда раст позиционируется как системный яп и проникает потихоньку в эмбеддед? У него ведь не только тяжелый статический анализатор кода, а еще и рантайм проверки (в случае с МК могут быть нерелевантны, ибо там, как правило, не имеют дело с кучей)
https://www.youtube.com/watch?v=NQBVUjdkLAA
Я не имел в виду только аллокацию памяти на куче, в мире микроконтроллеров это, в большинстве своем, непозволительная роскошь, ибо ресурсов маловато даже для обрыганского аллокатора памяти и менеджера кучи.
Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
Произошла аллокация статического 16-ти байтового буфера на стэке.
>>Нет, нельзя, производительности придет конец.
Как тогда раст позиционируется как системный яп и проникает потихоньку в эмбеддед? У него ведь не только тяжелый статический анализатор кода, а еще и рантайм проверки (в случае с МК могут быть нерелевантны, ибо там, как правило, не имеют дело с кучей)
>>Ну так вот любые пруфы то мб будут?
https://www.youtube.com/watch?v=NQBVUjdkLAA
>>741726
ав-та-ма-ти-чис-ка-я
повтори
>Аллокация происходит и на стэке (читай, статическая аллокация). Пример: sub rsp, 0x10
ав-та-ма-ти-чис-ка-я
повтори
>>741626
Скорее всего у него там обосновано почему.
Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
Из каких-то таких соображений и появляются ограничения на поддержку памяти компьютерами. Вроде бы у тебя безграничная 64-х битная память, но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами. Во многие серверные платы ты тоже сколько угодно не вставишь.
В общем там недостаточно просто уметь адресовать.
Скорее всего у него там обосновано почему.
Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
Из каких-то таких соображений и появляются ограничения на поддержку памяти компьютерами. Вроде бы у тебя безграничная 64-х битная память, но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами. Во многие серверные платы ты тоже сколько угодно не вставишь.
В общем там недостаточно просто уметь адресовать.
>>741739
Совершенно не по этой причине, не из-за быстродействия. Просто чем больше бит, тем больше площадь адресной шины, а место на кристалле дорогое. К тому же разводить широкую шину сложнее. Поэтому адрес 64 бита, а реально бит в адресной шине меньше.
> но обычный ноут современный скорее всего будет ограничен где-нибудь 16 гигабайтами
Совершенно не по этой причине, не из-за быстродействия. Просто чем больше бит, тем больше площадь адресной шины, а место на кристалле дорогое. К тому же разводить широкую шину сложнее. Поэтому адрес 64 бита, а реально бит в адресной шине меньше.
>>741739
Бля, чем ей "сложнее управлять"? у тебя кэшлайны такие же, развелось дебилов. менеджеры памяти тоже нормальнве люди пишут, и количество имеющейся памяти не влияет на скорость элементарных операций.
>Вообще проблем масса. Как минимум процессору необходимо управлять всей этой памятью, загружать страницы в кеш, сбрасывать и т.п. Процессор и ОС отвечают за преобразование виртуальной памяти в физическую, чем больше память, тем сложнее ею управлять.
>
Бля, чем ей "сложнее управлять"? у тебя кэшлайны такие же, развелось дебилов. менеджеры памяти тоже нормальнве люди пишут, и количество имеющейся памяти не влияет на скорость элементарных операций.
Есть инфа, зачем в сетевой библиотеке функции, переводящие endianness, представлены парами htonl/ntohl и htons/ntohs? Разве это не операция с четным периодом, как xor?
>общаться в си треде где 90% постеров это ебанаты студентишки и бывшие трактористы из юнитфактори не написавшие в своей жизни ни строчки кода отличного от linkedlisttutorial.c по туториалу, для которых авторитет это не имя и опыт за ним, а кто за скока вкатился
кринж
>>711268 (OP)
Хочу вкатиться в Natural Language Processing, Data Visualisation и всякий статический анализ. Для себя, для будущего диплома. Знаю, придется переписывать половину pandas на Си и творить ебанутые вещи.
Хочу выучить C11. Есть время для этого хобби, два года, есть мрачная решимость не подходить ко гвидопыху даже с десятифутовым копьем.
Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Я, конечно, добаеб и земля мне пухом, но если анонс подскажет полезных библиотек/книжек, буду рад.
Хочу вкатиться в Natural Language Processing, Data Visualisation и всякий статический анализ. Для себя, для будущего диплома. Знаю, придется переписывать половину pandas на Си и творить ебанутые вещи.
Хочу выучить C11. Есть время для этого хобби, два года, есть мрачная решимость не подходить ко гвидопыху даже с десятифутовым копьем.
Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Я, конечно, добаеб и земля мне пухом, но если анонс подскажет полезных библиотек/книжек, буду рад.
>>742135
Ну, тащемта, это даже не ты ебанат, а эта тема вообще не имеет никакого развития, даже вкат в NLP И так далее сомнителен. Вкат в визулизацию — это вообще кекус, там задачи — написать скрипт чтобы разобрать массив данных, причём в большинстве случаев это разовая акция на порисерчить.
Чел, во-первых это не плюсы, и 11 от 99 отличаются на 1,5 фичи в языке и 3 новых хидера в стдлибе, а во вторых С11 не то, чтобы что то нужное и везде используется в лучшем случае 99.
Тащемта даже хачкель для анализа данных подходит лучше, на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область (которая вообще не то, чтобы сидьно про программирование, оно там вообще вторично).
А про ненависть к ооп — а что для тебя вообще ооп?
Ну, тащемта, это даже не ты ебанат, а эта тема вообще не имеет никакого развития, даже вкат в NLP И так далее сомнителен. Вкат в визулизацию — это вообще кекус, там задачи — написать скрипт чтобы разобрать массив данных, причём в большинстве случаев это разовая акция на порисерчить.
>C11
Чел, во-первых это не плюсы, и 11 от 99 отличаются на 1,5 фичи в языке и 3 новых хидера в стдлибе, а во вторых С11 не то, чтобы что то нужное и везде используется в лучшем случае 99.
> Люто ненавижу ООП-парашу, скриптобесие. Функциональщину уважаю, но Haskell оставлю на сладкое.
Тащемта даже хачкель для анализа данных подходит лучше, на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область (которая вообще не то, чтобы сидьно про программирование, оно там вообще вторично).
А про ненависть к ооп — а что для тебя вообще ооп?
дiдько, таки обiсрався на скрiншотi
>>742303
> нет подсветки
> хаки
> константы Ls Cd не капсом
> не проверяется возвращаемое значение write
>>742322
Гораздо хуже "while (ent = readdir"
вместо "while ((ent = readdir"
Анончегу пох на предупреждения или он их отключил.
Гораздо хуже "while (ent = readdir"
вместо "while ((ent = readdir"
Анончегу пох на предупреждения или он их отключил.
71 Кб, 1280x960>>742322
. спецом, шоб писать охуительно качественный человекочитаемый код хоть под распечатку на чб принтере
. на то и есть домашние проекты, чтоб доверять самому себе и не обмазываться бест практиками
. в чем космический смысл писать константы КАПСОМ, если можно просто с Капса?
. write писал еще когда nlSendStr не было, ща оберну
. спецом, шоб писать охуительно качественный человекочитаемый код хоть под распечатку на чб принтере
. на то и есть домашние проекты, чтоб доверять самому себе и не обмазываться бест практиками
. в чем космический смысл писать константы КАПСОМ, если можно просто с Капса?
. write писал еще когда nlSendStr не было, ща оберну
>>742161
Спасибо за мнение.
Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
ООП для меня просто школьная травма.
Бесконечные классы за гранью нормального, всякие get/set, и -1 балл на контрольной за printf вместо cout с охуительным объяснением "ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно". Пять лет прошло, а я злой как собака как вспомню.
Спасибо за мнение.
>на си ты просто будешь ебаться с памятью и ловить сегфолты вместо того, чтобы изучать эту область
Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
>А про ненависть к ооп — а что для тебя вообще ооп?
ООП для меня просто школьная травма.
Бесконечные классы за гранью нормального, всякие get/set, и -1 балл на контрольной за printf вместо cout с охуительным объяснением "ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно". Пять лет прошло, а я злой как собака как вспомню.
>>742457
Это и есть та самая меморимодел?
>, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Это и есть та самая меморимодел?
>>742457
Что за шиза?
>ты должен относиться к строке как к объекту, а не описывать форматированный вывод процедурно
Что за шиза?
>>742457
Ты же понимаешь, что это _абсолютно_ write-only подход, который практически невозможно поддерживать и развивать? Ты же сам 2 месяца не разберёшься в коде без полного погружения в это. Это даже хуже типичного говнокода от датасатанистов.
А при чём тут ООП-то? Когда тебе понадобится присобачить минимальную логику, начиная от отладочной информации или просто ассертов просто ради приблежиния к уровню self documenting code, и заканчивая серьёзными изменениями (например, строка превратилась в бинарный формат, который надо печатать форматированно), то ты и на ассемблере всё на гет/сет все публичные интерфейсы перепишешь, лол.
Таки да, всё нормально, порефакторишь то же, что сам понаписал и начнёшь спокойно юзать ооп, реальных производственных травм у тебя нет.
>>742634
Со стороны нормального программного дизайна это как раз таки нормальное замечание. На уровне лабы3 конечно похуй, но с практической стороны лучше иметь возможность тюнить даже такой функционал не меняя саму логику программы.
inb4: Ух, чую как злая шкила меня сейчас говном закидает, лол.
>Что с памятью-то ебаться? Сел, написал алгоритм, разобрался с типами данных, начертил примерную карту адресного пространства в памяти, прикинул, чтобы информация размещалась более-менее свободно для входного набора данных.
Ты же понимаешь, что это _абсолютно_ write-only подход, который практически невозможно поддерживать и развивать? Ты же сам 2 месяца не разберёшься в коде без полного погружения в это. Это даже хуже типичного говнокода от датасатанистов.
>всякие get/set
А при чём тут ООП-то? Когда тебе понадобится присобачить минимальную логику, начиная от отладочной информации или просто ассертов просто ради приблежиния к уровню self documenting code, и заканчивая серьёзными изменениями (например, строка превратилась в бинарный формат, который надо печатать форматированно), то ты и на ассемблере всё на гет/сет все публичные интерфейсы перепишешь, лол.
>ООП для меня просто школьная травма.
Таки да, всё нормально, порефакторишь то же, что сам понаписал и начнёшь спокойно юзать ооп, реальных производственных травм у тебя нет.
>>742634
Со стороны нормального программного дизайна это как раз таки нормальное замечание. На уровне лабы3 конечно похуй, но с практической стороны лучше иметь возможность тюнить даже такой функционал не меняя саму логику программы.
inb4: Ух, чую как злая шкила меня сейчас говном закидает, лол.
>>742708
Со стороны программного дизайна потоки в C++ - это полный пиздец, ничего хуже еще не придумывали.
> Со стороны нормального программного дизайна
Со стороны программного дизайна потоки в C++ - это полный пиздец, ничего хуже еще не придумывали.
142 Кб, 660x400>>742711
А что такое ООП, чел? В С вот реализация инкапсулируется от интерфейса с помощью хидеров, инкапсуляция — 1 из 3 принципов ООП, С — ООП язык на 1/3?
>>742723
Я же и не говорил обратного, но это хоть какая-то инкапсуляция. Ебашь на здоровье массивы байтов напрямую, кто же запрещает-то. Просто через пару лет догонишь что это хуйня а не подход.
А что такое ООП, чел? В С вот реализация инкапсулируется от интерфейса с помощью хидеров, инкапсуляция — 1 из 3 принципов ООП, С — ООП язык на 1/3?
>>742723
Я же и не говорил обратного, но это хоть какая-то инкапсуляция. Ебашь на здоровье массивы байтов напрямую, кто же запрещает-то. Просто через пару лет догонишь что это хуйня а не подход.
>>742728
ООП-язык - это язык с сахарком. В си сахарка нет. Вот в ObjC например есть.
> С — ООП язык на 1/3?
ООП-язык - это язык с сахарком. В си сахарка нет. Вот в ObjC например есть.
>>742732
Ну смотри, есть C++ а есть Obj-C. И там и там есть "сахарок", только реализует он всё примерно диаметрально противоположно. Кто из них ООП?
ООП — это, блядь, концепция. Ясен хуй, что никому не нравятся всякие там паттерны итд, но паттерны — это костыли для конкретного языка, а не ООП. ООП — это 3 ебучих принципа, ничего лучше которых никто не придумал (разве что про наследование можно поспорить).
Ну смотри, есть C++ а есть Obj-C. И там и там есть "сахарок", только реализует он всё примерно диаметрально противоположно. Кто из них ООП?
ООП — это, блядь, концепция. Ясен хуй, что никому не нравятся всякие там паттерны итд, но паттерны — это костыли для конкретного языка, а не ООП. ООП — это 3 ебучих принципа, ничего лучше которых никто не придумал (разве что про наследование можно поспорить).
>>742743
Нет. Только один: объекты обмениваются сообщениями. И он нихуя не применим на практике без проблем с производительностью. Поэтому ООП-ом каждый называет какие-то свои фантазии. Ну или то, что в вузике вдолбили.
> ООП — это 3 ебучих принципа
Нет. Только один: объекты обмениваются сообщениями. И он нихуя не применим на практике без проблем с производительностью. Поэтому ООП-ом каждый называет какие-то свои фантазии. Ну или то, что в вузике вдолбили.
>>742708
Со стороны нормального дизайна использовать сиаут для форматирования строки это пиздец.
>Со стороны нормального программного дизайна это как раз таки нормальное замечание.
Со стороны нормального дизайна использовать сиаут для форматирования строки это пиздец.
160 Кб, 640x960>>742728
Это когда оперируешь объектами классов их иерархией. И все это говно сильно зависит от контекста, плюс поддерживание инкапсуляции, один васян решил скрыть доступ, а второй городит огород чтобы нормально считать значение переменной или избавится от оверхеда проверки значения. Короче оч на любителя, как разведенки с прицепами. Но Qt для мордочек юзаю, да. Философия Перл/С здесь ближе, написал в документашке не лезь и все этого достаточно.
>А что такое ООП, чел
Это когда оперируешь объектами классов их иерархией. И все это говно сильно зависит от контекста, плюс поддерживание инкапсуляции, один васян решил скрыть доступ, а второй городит огород чтобы нормально считать значение переменной или избавится от оверхеда проверки значения. Короче оч на любителя, как разведенки с прицепами. Но Qt для мордочек юзаю, да. Философия Перл/С здесь ближе, написал в документашке не лезь и все этого достаточно.
>>742746
В понимании примерно всего коммьюнити — 3, и почти весь софт на планете пишется с их применением, поэтому Алан Кей идёт нахуй.
Даже в Objective-C завезли __attribute__((objc_direct)) что как бы намекает, что этот подход мертв.
>>742757
Читать умеешь?
>>742728
>>742759
А аналоги-то какие? Как в новомодных фп архитектурах просто использовать композицию вместо наследования и копипастить код из редюсера в редюсер стейта и создавать заново весь стейт (а лучше и контекст) при каджом изменении а потом гнать по скомпозированному дереву функций?
>Нет. Только один: объекты обмениваются сообщениями.
В понимании примерно всего коммьюнити — 3, и почти весь софт на планете пишется с их применением, поэтому Алан Кей идёт нахуй.
Даже в Objective-C завезли __attribute__((objc_direct)) что как бы намекает, что этот подход мертв.
>>742757
Читать умеешь?
>>742728
>Я же и не говорил обратного
>>742759
А аналоги-то какие? Как в новомодных фп архитектурах просто использовать композицию вместо наследования и копипастить код из редюсера в редюсер стейта и создавать заново весь стейт (а лучше и контекст) при каджом изменении а потом гнать по скомпозированному дереву функций?
>>742766
Слать на хуй ООП парадигму. Ну может комуто нравится когда в одной либе петух это класс птиц, а в другой динозавров.
>А аналоги-то какие?
Слать на хуй ООП парадигму. Ну может комуто нравится когда в одной либе петух это класс птиц, а в другой динозавров.
Мне в ООП нравится только инкапсуляция. Сам я пишу драйвера и системы управления железками разными, и вот именно это я всегда использую в си.
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.
Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
Я бы еще перегрузку функций использовал, но она какая-то костыльная в си11, да и боюсь я на си11 переходить, лол.
Честно говоря я вообще не понимаю ООП в Сипипи. Вот в шарпе с ООП все в порядке и там все понятно сразу. Там объектом является ваще все, даже небо, даже Аллах, даже DBNull. А в плюсах нужно постоянно сворачиать мозг, чтобы думать объектно в процедурном языке.
58 Кб, 527x791>>742797
Ага, если учитывать все кодировки и системы письма, то твой класс улетит в ебеня. Но обычно получается ни то ни се и все работают с байтовым буфером по своим потребностям.
Ага, если учитывать все кодировки и системы письма, то твой класс улетит в ебеня. Но обычно получается ни то ни се и все работают с байтовым буфером по своим потребностям.
>>742795
Инициализации железа. Вся работа с ногами и регистрами отдельно, логика системы отдельно.
Инициализации железа. Вся работа с ногами и регистрами отдельно, логика системы отдельно.
>>742797
Кстати, вот иллюстрация убогости С: надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s, программа упаде.
Кстати, вот иллюстрация убогости С: надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %s, программа упаде.
>>742804
Просто делаешь строки sprintfом
Просто делаешь строки sprintfом
Когда познакомился с плисами, а также Верилогом и прочими hdl, понял, что ООП это всего-навсего железки в коде.
>>742804
То компилятор скажет, что ты ошибся. Да, это работает только для printf-like функций, а если у тебя свой собственный формат спецификаторов или вообще его нет, тогда тебе никто не поможет.
> надо согласовывать форматные спецификаторы с типами параметров. Если ошибешься с %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" не помогает
>>713183
А если выводить через puts?
А если выводить через puts?
41 Кб, 528x498Какое же сложное это ваше программирование. Вот хочу смочь в С - а где мне компилировать? Ставить себе линух или на виртуальную машину и использовать gnu? Или тупо в вижуал студио на виндоусе для начала сойдет? Для чего нужно ставить clang и что это вообще такое?
123 Кб, 727x691>>743166
Вижуал студио сказал что не хочет работать без обновления,
а чтобы обновиться нужно залогиниться в учетку майкрософт, от которой я забыл пароль. Сбросил пароль - ввожу и тут он мне говорит что это старый пароль, хотя он не подходил. Видимо я уже менял пароль, и это старый старый пароль и он почему-то больше не подходит им. Вот нахуя программисты майкрософт создают такую еблю для пользователя?
Вижуал студио сказал что не хочет работать без обновления,
а чтобы обновиться нужно залогиниться в учетку майкрософт, от которой я забыл пароль. Сбросил пароль - ввожу и тут он мне говорит что это старый пароль, хотя он не подходил. Видимо я уже менял пароль, и это старый старый пароль и он почему-то больше не подходит им. Вот нахуя программисты майкрософт создают такую еблю для пользователя?
>>743166
что тебе делать, тебе тут говорить не должны; линукс - рай для творческого программирования
си компилирует gcc, который всегда во всех дистрах в репах; редачить можно в обвязке, а многие используют обычные редакторы с подсветкой
что тебе делать, тебе тут говорить не должны; линукс - рай для творческого программирования
си компилирует gcc, который всегда во всех дистрах в репах; редачить можно в обвязке, а многие используют обычные редакторы с подсветкой
>>743175
>Вот нахуя программисты майкрософт создают такую еблю для пользователя?
> Почему буквальный EvilCorp мне плохое зло зделол?
>>743166
На форточках я бы посоветовал использовать Code::Blocks + MinGW. Со студией хоть и проще начать работать, но в сравнении с CB её функционал для новичка является overkill, поэтому освоить её сложнее.
А вообще, учить человека программированию начиная с C - издевательство, так можно его превратить в Си-дебила. Типичный Си-дебил ничего, кроме императивных языков с Си-подобным синтаксисом освоить практически неспособен.
>Или тупо в вижуал студио на виндоусе для начала сойдет?
На форточках я бы посоветовал использовать Code::Blocks + MinGW. Со студией хоть и проще начать работать, но в сравнении с CB её функционал для новичка является overkill, поэтому освоить её сложнее.
А вообще, учить человека программированию начиная с C - издевательство, так можно его превратить в Си-дебила. Типичный Си-дебил ничего, кроме императивных языков с Си-подобным синтаксисом освоить практически неспособен.
>>743175
лол. в рот ебал эти эко-коко-системы.
есть ли какие-то форумы/движения/репозитории, которые продвигают идею что комп должен быть ВСЕЯДНЫМ ?
(без крайностей)
лол. в рот ебал эти эко-коко-системы.
есть ли какие-то форумы/движения/репозитории, которые продвигают идею что комп должен быть ВСЕЯДНЫМ ?
(без крайностей)
>>743166
Попробуй. Еще захочешь, базарю. На самом деле не нужно, используй удобную для себя систему.
Сойдет и для продолжения. Хотя лично я предпочитаю Clion, но на винде он обычно поверх студии ставится, лол. Не спрашивай.
С - компилируемый язык, так что для превращения твоих буквочек в программу нужен компилятор.
Дефолтный выбор для винды - msvc(visual studio сама его поставит), для линуксов\макоси - gcc.
Clang - это тоже компилятор, можно поставить в качестве альтернативы тем что выше и все будт заебца.
Не стоит вскрывать эту тему, но вы все равно будете спрашивать..
Clang - часть проекта llvm.org
Если коротко, то clang отвечает за фронтенд компилятора, за счет опен-соусности и хорошего api эту хуеверть используют в разных IDE для подсветочки кода, функций рефакторинга, пиздатых сообщений об ошибках и прочих кодоанализов. В связке с llvm превращается в черную магию, способную работать с кодом на любом этапе компиляции, сожрать твой разум, сделать новый язык программирования или даже перевести код с одного языка на другой, попутно забрав твою душу.
Ты был предубежден.
мимо-крестодебич, зашел в тред случайно.
>Ставить себе линух?
Попробуй. Еще захочешь, базарю. На самом деле не нужно, используй удобную для себя систему.
>Или тупо в вижуал студио на виндоусе для начала сойдет?
Сойдет и для продолжения. Хотя лично я предпочитаю Clion, но на винде он обычно поверх студии ставится, лол. Не спрашивай.
>Для чего нужно ставить clang?
С - компилируемый язык, так что для превращения твоих буквочек в программу нужен компилятор.
Дефолтный выбор для винды - msvc(visual studio сама его поставит), для линуксов\макоси - gcc.
Clang - это тоже компилятор, можно поставить в качестве альтернативы тем что выше и все будт заебца.
>что это вообще такое?
Не стоит вскрывать эту тему, но вы все равно будете спрашивать..
Clang - часть проекта llvm.org
Если коротко, то clang отвечает за фронтенд компилятора, за счет опен-соусности и хорошего api эту хуеверть используют в разных IDE для подсветочки кода, функций рефакторинга, пиздатых сообщений об ошибках и прочих кодоанализов. В связке с llvm превращается в черную магию, способную работать с кодом на любом этапе компиляции, сожрать твой разум, сделать новый язык программирования или даже перевести код с одного языка на другой, попутно забрав твою душу.
Ты был предубежден.
мимо-крестодебич, зашел в тред случайно.
>>743249
Это субъективно, но не стану спорить.
Как минимум какой-нибудь Scheme или Standard ML очень в тему, если приспичило углубиться в Computer Science. У редкого адепта K&R не выносят мозг рекурсивные алгоритмы, обычно используемые в ФП (бинарные деревья из книги они осилили с горем пополам).
>а что бывает кроме императивных языков? по-моему это самый удбный для понимания код. особенно для пддержки другими людьми.
Это субъективно, но не стану спорить.
Как минимум какой-нибудь Scheme или Standard ML очень в тему, если приспичило углубиться в Computer Science. У редкого адепта K&R не выносят мозг рекурсивные алгоритмы, обычно используемые в ФП (бинарные деревья из книги они осилили с горем пополам).
>>743242
Да я не совсем нулевой, в университете вроде бы сдал курс программирования, и даже численные методы на паскале на самом деле не помню чё там было, вроде C++, было похуй сдал и забыл так что сейчас думаю научиться хоть чему-то полезному, не важно какой синтаксис учить сначала мне кажется. Я не из тех кабанчиков которые через 1 месяц хотят устраиваться погромистами.
>>743264
Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Да я не совсем нулевой, в университете вроде бы сдал курс программирования, и даже численные методы на паскале на самом деле не помню чё там было, вроде C++, было похуй сдал и забыл так что сейчас думаю научиться хоть чему-то полезному, не важно какой синтаксис учить сначала мне кажется. Я не из тех кабанчиков которые через 1 месяц хотят устраиваться погромистами.
>>743264
Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
>>743242
Может лучше wsl или уже линукс?
>>743268
Тебе как обычному посону достаточно нажать кнопочку compile в ide или как ты там предпочитаешь.
Всю еблю и танцы с разными железками, преобразованием говнокода чтоб анубыстроблядь работало и прочие заботы берет на себя компилятор(тот же clang).
В 99% случаев думать о том что там под капотом происходит вообще не надо.
>На форточках я бы посоветовал использовать Code::Blocks + MinGW
>MinGW
Может лучше wsl или уже линукс?
>>743268
>Откуда вообще такие гигантские масштабы жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду?
Тебе как обычному посону достаточно нажать кнопочку compile в ide или как ты там предпочитаешь.
Всю еблю и танцы с разными железками, преобразованием говнокода чтоб анубыстроблядь работало и прочие заботы берет на себя компилятор(тот же clang).
В 99% случаев думать о том что там под капотом происходит вообще не надо.
>>743268
Можешь попробовать Code block портабельную сборку, на сайте у какогото инфоцыгана что ли видел, тредов 20 назад про неё спрашивал обосрали конечно но работает только вроде пути к компиляторам если не в С копируешь вручную надо поменять.
>жопоебли и танцов с бубнами, просто чтобы заставить железо выполнить твою команду? Хотя сюда наверное точно не стоит влезать, придёт время пойму.
Можешь попробовать Code block портабельную сборку, на сайте у какогото инфоцыгана что ли видел, тредов 20 назад про неё спрашивал обосрали конечно но работает только вроде пути к компиляторам если не в С копируешь вручную надо поменять.
>>743242
Откуда этот миф про первый язык?
Если айсикью недостает какой язык не дай человек на нём и застагнирует.
Откуда этот миф про первый язык?
Если айсикью недостает какой язык не дай человек на нём и застагнирует.
>>743242
Как раз си, и Книга Кернигана и Ритчи идеальны для вкатывания в проргаммирование вообще. Там же все с самых азов. Еще лучше если купить отладочную плату при этом.
Как раз си, и Книга Кернигана и Ритчи идеальны для вкатывания в проргаммирование вообще. Там же все с самых азов. Еще лучше если купить отладочную плату при этом.
>>743349
Блять, легче тогда devcpp поставить и не ебаться, для новичка топ - нет подсветки, простой в установке и идёт в комплекте с компилятором
Блять, легче тогда devcpp поставить и не ебаться, для новичка топ - нет подсветки, простой в установке и идёт в комплекте с компилятором
>>743391
В си есть указатели с ними проще списки понять. Какая то абстракция есть, другие всё стремятся "очеловечить" что ли Си как математика.
В си есть указатели с ними проще списки понять. Какая то абстракция есть, другие всё стремятся "очеловечить" что ли Си как математика.
>>743416
Как один из концов. Пацанское рвение прошариться в ламповом низкоуровневом коддинге утроит общую продуктивность занятий, даже если "КПД" не очень. А так, SICP правильнее.
Как один из концов. Пацанское рвение прошариться в ламповом низкоуровневом коддинге утроит общую продуктивность занятий, даже если "КПД" не очень. А так, SICP правильнее.
>>743445
ЛЕГЧЕ было бы просто новый аккаунт в макйрософте зарегистрировать и какать в визуальную студию, но нужно же блджад в пр в мертвый тред насрать
ЛЕГЧЕ было бы просто новый аккаунт в макйрософте зарегистрировать и какать в визуальную студию, но нужно же блджад в пр в мертвый тред насрать
>>743580
так двач тоже зашквар, значит для него это не проблема
так двач тоже зашквар, значит для него это не проблема
>>711268 (OP)
Расположение битовых полей в памяти.
Имеется некий пакет передачи, который нужно заполнить в правильной последовательности, например:
5 битов - адрес
3 бита - номер функции
10 битов - данные
7 битов - контрольная сумма
Ну и решил для удобства всё это сделать структурой с битовыми полями. На байтах всё выходило как надо(потому что биты в байтах, переменных и элементы в массиве всегда размещаются одним и тем же образом). Но когда я стал тоже делать битовыми полями, всё вышло через жопу. Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Расположение битовых полей в памяти.
Имеется некий пакет передачи, который нужно заполнить в правильной последовательности, например:
5 битов - адрес
3 бита - номер функции
10 битов - данные
7 битов - контрольная сумма
Ну и решил для удобства всё это сделать структурой с битовыми полями. На байтах всё выходило как надо(потому что биты в байтах, переменных и элементы в массиве всегда размещаются одним и тем же образом). Но когда я стал тоже делать битовыми полями, всё вышло через жопу. Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
>>743979
пили свой препроцессор, который использование таких структур переведет в соответствующие голые операции
пили свой препроцессор, который использование таких структур переведет в соответствующие голые операции
>>743979
Какой опытный путь, гуглить ты не пробовал?
В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
> Опытным путем я установил, что компилятор размещает битовые поля в памяти рандомным образом, вне зависимости от того, как они указаны в структуре.
Какой опытный путь, гуглить ты не пробовал?
В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
>>743979
Да. Ни обычные структуры, ни структуры с битфилдами нельзя отправлять через сеть в сыром виде, их можно только писать в файл, если этот файл будет прочитан той же программой на той же платформе. Для обмена данными надо писать (де)сериализатор, который возьмет байтики (или битики) из принятого буфера, распарсит их и запишет в поля структуры: myshit.smth = read_uint(&src); myshit.some_bitfield = bitstream_read(&bs, 5), ну типа того.
Да, многие пренебрегают этим, надеясь на то, что big endian их не коснется, и что исключения у флоатов выключены, и что что выраванивания у членов структуры и буфера с полученными данными правильные, и что -fms-bitfields их спасет. Но лучше не стоит.
> Я правильно понял, что в таких случаях лучше тупо пользоваться битовыми операциями без битовых полей?
Да. Ни обычные структуры, ни структуры с битфилдами нельзя отправлять через сеть в сыром виде, их можно только писать в файл, если этот файл будет прочитан той же программой на той же платформе. Для обмена данными надо писать (де)сериализатор, который возьмет байтики (или битики) из принятого буфера, распарсит их и запишет в поля структуры: myshit.smth = read_uint(&src); myshit.some_bitfield = bitstream_read(&bs, 5), ну типа того.
Да, многие пренебрегают этим, надеясь на то, что big endian их не коснется, и что исключения у флоатов выключены, и что что выраванивания у членов структуры и буфера с полученными данными правильные, и что -fms-bitfields их спасет. Но лучше не стоит.
>>743979
ПРОСТО ИСПОЛЬЗУЙ ЛОГИЧСКИЕ ОПЕРАЦИИ
ПРОСТО ИСПОЛЬЗУЙ ЛОГИЧСКИЕ ОПЕРАЦИИ
>>743979
Битовые поля хуёво стандартизированы. Поэтому лучше воздержаться от их использования.
Битовые поля хуёво стандартизированы. Поэтому лучше воздержаться от их использования.
>>744124
Они стандартизированы, просто каждый компилятор располагает их по разному в памяти.
>Поэтому лучше воздержаться от их использования.
Не все так однозначно.
Если ты работаешь с битовыми полями только в программе, то их можно использовать, они намного удобнее.
А если собираешься куда-то пересылать, то лучше тогда биты распределять в пакете передачи вручную с помощью битовых операций.
Тот же MISRA C не запрещает битовые поля, хотя как бы этот стандарт во всем придерживается, чтобы код не зависил от компилятора.
>Битовые поля хуёво стандартизированы.
Они стандартизированы, просто каждый компилятор располагает их по разному в памяти.
>Поэтому лучше воздержаться от их использования.
Не все так однозначно.
Если ты работаешь с битовыми полями только в программе, то их можно использовать, они намного удобнее.
А если собираешься куда-то пересылать, то лучше тогда биты распределять в пакете передачи вручную с помощью битовых операций.
Тот же MISRA C не запрещает битовые поля, хотя как бы этот стандарт во всем придерживается, чтобы код не зависил от компилятора.
>>744006
Изменял биты в полученном пакете передачи, а потом на бумажке отмечал, где находится то или иное битовое поле.
Потом, когда увидел такое говно, загуглил, оказалось, что расположение битовых полей в памяти отличается от компилятора к компилятору.
Да это я знаю, порядок байтов в массивах и структурах всегда одинаков - элементы в начале структуры/массива имеют младшие адреса. А биты в байте располагаются от старшего к младшему.
Речь про битовые поля, а они могут быть не кратны байту, и как расположит компилятор их в структуре это всегда загадка.
>Какой опытный путь
Изменял биты в полученном пакете передачи, а потом на бумажке отмечал, где находится то или иное битовое поле.
>, гуглить ты не пробовал?
Потом, когда увидел такое говно, загуглил, оказалось, что расположение битовых полей в памяти отличается от компилятора к компилятору.
>В зависимости от платформы расположение полей структуры в памяти может отличаться. В частности, на Windows порядок расположения следующий: поля в начале структуры имеют младшие адреса, а поля в конце структуры имеют старшие адреса.
Да это я знаю, порядок байтов в массивах и структурах всегда одинаков - элементы в начале структуры/массива имеют младшие адреса. А биты в байте располагаются от старшего к младшему.
Речь про битовые поля, а они могут быть не кратны байту, и как расположит компилятор их в структуре это всегда загадка.
587 Кб, 1024x576>>744180
охуенно
охуенно
>>711268 (OP)
Блин, а это говно:
разве обязательно читать?
Просто я прочёл справочник Шильдта(и иногда заглядываю в его при работе) и мне этого с головой хватает для проганья, не вижу смысла что-то ещё читать дополнительно.
Блин, а это говно:
>- Brian Kernighan, Dennis Ritchie "The C Programming Language":
разве обязательно читать?
Просто я прочёл справочник Шильдта(и иногда заглядываю в его при работе) и мне этого с головой хватает для проганья, не вижу смысла что-то ещё читать дополнительно.
>>711627
А теперь объясни, чем константы отличаются от дефайнов...
>> define
>Это единственный в Си нормальный способ объявления констант
А теперь объясни, чем константы отличаются от дефайнов...
>>744425
Пиши в файле:
const int nelem = 42;
int array[nelem];
И компилируй. Алсо, const не гарантирует, что переменная nelem не будет читаться там, где ее можно было оптимизировать до immediate-операнда в инструкции.
> чем константы отличаются от дефайнов
Пиши в файле:
const int nelem = 42;
int array[nelem];
И компилируй. Алсо, const не гарантирует, что переменная nelem не будет читаться там, где ее можно было оптимизировать до immediate-операнда в инструкции.
>>744425
Тем, что дефайн - это find & replace ДО начала компиляции. При абузе дефайнов ты охуеешь дебажить это говно, так как переменной как таковой нет, до процесса компиляции просто идет замена x на y, если макрос: #define x y
А константа - переменная, под которую выделяется место в read-only сегменте памяти. И при дебаге, в отличие от дефайнов, у тебя будет не много веселых магических чисел, а переменная с конкретным адресом в памяти.
Тем, что дефайн - это find & replace ДО начала компиляции. При абузе дефайнов ты охуеешь дебажить это говно, так как переменной как таковой нет, до процесса компиляции просто идет замена x на y, если макрос: #define x y
А константа - переменная, под которую выделяется место в read-only сегменте памяти. И при дебаге, в отличие от дефайнов, у тебя будет не много веселых магических чисел, а переменная с конкретным адресом в памяти.
>>744470
Не хочешь оптимизаций от компилятора для конкретной переменной - юзай ключевое слово volatile в таких случаях.
Не хочешь оптимизаций от компилятора для конкретной переменной - юзай ключевое слово 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
Почему первый вариант работает как надо а мой не считает нихуя?
>>747770
Загнал палучается в студию и понял что проблема в двойных кавычках хех мдаа понимаю.
Загнал палучается в студию и понял что проблема в двойных кавычках хех мдаа понимаю.
Сяч, я передаю указатель на char вот с таким кастом:
это означает, что он продублируется в ридонли дейта регион? он же не может в соответствующую секцию в бинаре прописаться?
> func((const char zvezda) buf)
это означает, что он продублируется в ридонли дейта регион? он же не может в соответствующую секцию в бинаре прописаться?
7 Кб, 629x218Господа, я горю нужен совет бывалых.
Надо передать фрейм через веб-сокет.
Бяда в том, что передающая функция принимает структуру вида пик1, а ws-клиент на другом конце ждёт объект JSON.
Как мне в Си сеариализовать в JSON объект? Либа - cJSON.
Надо отправить что-то вроде ({"isStagotip":"true"})
Надо передать фрейм через веб-сокет.
Бяда в том, что передающая функция принимает структуру вида пик1, а ws-клиент на другом конце ждёт объект JSON.
Как мне в Си сеариализовать в JSON объект? Либа - cJSON.
Надо отправить что-то вроде ({"isStagotip":"true"})
>>741626
Он пишет про процессорный кеш. В его лучшие года он был 8-16 килобайт, сейчас он даже в 10 поколении топ L1 512кб L2 18 L3 24.75 мб соответственно. Очевидно что процессор при считывании чего-то большого в памяти будет прогонять часть через L1 разбивая на кусочки меньше 512 килобайт. А это в свою очередь отдельные. Очевидно что в таком случае 4 гига прогнать проще и быстрее чем 128 гигов.
Но это лишь моё предположение, надо смотреть в каком контексте он это говорил.
Он пишет про процессорный кеш. В его лучшие года он был 8-16 килобайт, сейчас он даже в 10 поколении топ L1 512кб L2 18 L3 24.75 мб соответственно. Очевидно что процессор при считывании чего-то большого в памяти будет прогонять часть через L1 разбивая на кусочки меньше 512 килобайт. А это в свою очередь отдельные. Очевидно что в таком случае 4 гига прогнать проще и быстрее чем 128 гигов.
Но это лишь моё предположение, надо смотреть в каком контексте он это говорил.
>>747868
Нихуя не понятно, о чем ты спрашиваешь, но каст ничего никуда не копирует.
Нихуя не понятно, о чем ты спрашиваешь, но каст ничего никуда не копирует.
>>748118
Спасибо, но не то.
uint8_t buf[128] = { 0 };
httpd_ws_frame_t ws_pkt;
ws_pkt.payload = buf;
Как скастовать \ передрать объект JSON в буфер buf, который имеет тип uint8_t?
Спасибо, но не то.
uint8_t buf[128] = { 0 };
httpd_ws_frame_t ws_pkt;
ws_pkt.payload = buf;
Как скастовать \ передрать объект JSON в буфер buf, который имеет тип uint8_t?
Пока Сишники рофлят над растом, он потихоньку пробирается в Линукс, лол
,O$djd68fp7mzmBp3-wY--UwANUSmayh`il PUNCTUMgmaK5Nil PUNCTUMcoO:@m /T/#u" target="_blank" rel="nofollow noopener noreferrer">https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3X3v-wY--Uw ANUSmaiH_Xl PUNCTUMgmaS+@il PUNCTUMcjjmom /T/#u
,O$djd68fp7mzmBp3-wY--UwANUS
>>748685
почему мертвый?
мимоанон, не понимающий происходящей шумихи вокруг ржавого, который начинают хайпить компании вроде мозиллы и майков
почему мертвый?
мимоанон, не понимающий происходящей шумихи вокруг ржавого, который начинают хайпить компании вроде мозиллы и майков
>>747868
Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё. Вообще, нахуя тебе явный каст? Конверсия указателя в указатель на константу происходит неявно и вообще абсолютно легальна (то, что функция принимает указатель на константу, обычно означает, что она не будет менять передаваемые таким образом данные). Система типов в си - достаточно мудра и держит тебя в узде.
>ридонли дейта регион
Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё. Вообще, нахуя тебе явный каст? Конверсия указателя в указатель на константу происходит неявно и вообще абсолютно легальна (то, что функция принимает указатель на константу, обычно означает, что она не будет менять передаваемые таким образом данные). Система типов в си - достаточно мудра и держит тебя в узде.
>>748721
растошизик незаметен
растошизик незаметен
>>748721
Куча детских болезней.
Есть профит по сравнению с каким-нибудь JS, Java, Kotlin или PHP. Когда речь заходит о сравнениис C - все профиты пропадают.
В основном растошизики орут что раст круче при работе с памятью и что сложнее выстрелить себе в ногу при этом умалчивая факт того что это профиты перед стандартом C 1997 года!
Куча детских болезней.
Есть профит по сравнению с каким-нибудь JS, Java, Kotlin или PHP. Когда речь заходит о сравнениис C - все профиты пропадают.
В основном растошизики орут что раст круче при работе с памятью и что сложнее выстрелить себе в ногу при этом умалчивая факт того что это профиты перед стандартом C 1997 года!
>>748252
Help.
Help.
44 Кб, 550x403>>748252
Попробовал вот так: https://pastebin.com/08anHKqu
Но memcpy не корректно скопировало массивы.
_Server: Got packet with message: "isStagotip" // запрос от клиента
_Server: Packet type: 1
{
"isStagotip": "false" // содержимое *json
}
_Server: Buf: {isStagotip" // результат работы memcpy c массивом buf
:(
Попробовал вот так: https://pastebin.com/08anHKqu
Но memcpy не корректно скопировало массивы.
_Server: Got packet with message: "isStagotip" // запрос от клиента
_Server: Packet type: 1
{
"isStagotip": "false" // содержимое *json
}
_Server: Buf: {isStagotip" // результат работы memcpy c массивом buf
:(
>>748865
Это у него просто отладчика нет. Если исходники есть - можно source-level отладкой пользоваться, если нет - код обычно оптимизированный, и никаких отдельных переменных под const там уже нет.
Это у него просто отладчика нет. Если исходники есть - можно source-level отладкой пользоваться, если нет - код обычно оптимизированный, и никаких отдельных переменных под const там уже нет.
>>748725
Ну вообще в микропердолинге, например, приблизительно так и происходит. Всё зависит от платформы и компилятора.
>что const записывается в "read only" память. Нету такого говна, нету.
Ну вообще в микропердолинге, например, приблизительно так и происходит. Всё зависит от платформы и компилятора.
>>748786
А что сейчас поменялось? Сишка так и продолжает невозбранно срать в память, ub на ub и ub погоняет. В крестахс этим проще, там контейнеры и умные указатели, этот язык на 90% избавился от проблем 80ых, в отличие от Сишки.
А в расте так вообще срать в память можно только в ансейф блоках, и то со своими нюансами. При этом пристальное внимание при тестах можно сосредоточить именно там и поэтому вероятность критических багов в целом снижается чуть ли не к 0.
А что сейчас поменялось? Сишка так и продолжает невозбранно срать в память, ub на ub и ub погоняет. В крестахс этим проще, там контейнеры и умные указатели, этот язык на 90% избавился от проблем 80ых, в отличие от Сишки.
А в расте так вообще срать в память можно только в ансейф блоках, и то со своими нюансами. При этом пристальное внимание при тестах можно сосредоточить именно там и поэтому вероятность критических багов в целом снижается чуть ли не к 0.
>>748725
.section.rodata
>Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету.
.section.rodata
>>748903
Сразу видно смузихлеба, который пишет на своем языке хеллоу ворлды, а не нормальные проекты. Раст не защищает от утечек, он предоставляет 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 Гб, и так далее....
Сразу видно смузихлеба, который пишет на своем языке хеллоу ворлды, а не нормальные проекты. Раст не защищает от утечек, он предоставляет 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 Гб, и так далее....
>>749114
Ага, только вот утечка памяти сама по себе не эксплуатабельна. Ты не можешь дойти до состояния исполнения произвольного кода имея лишь мемори лик, в отличие от переполнений и мисменеджмента работы с указателями, что раст элиминирует накорню (не считая ансейф, но я уже высказался по этому поводу).
Ага, только вот утечка памяти сама по себе не эксплуатабельна. Ты не можешь дойти до состояния исполнения произвольного кода имея лишь мемори лик, в отличие от переполнений и мисменеджмента работы с указателями, что раст элиминирует накорню (не считая ансейф, но я уже высказался по этому поводу).
>>749125
Да, attack surface меньше, тем не менее, раст не такой идеальный каким его многие описывают. Мне кажется, если не было фанатичной рекламы раста из всех щелей, то не было бы хейта в сторону раста и относились бы к нему спокойнее. Ну а так, мне кажется, что уже стоит начинать изучать раст, тем кто хочет в системщину, не обязательно писать, но уже даже мелкомягкие и мейнтейнеры линукса уже начинают работать с растом. Хотя, кмк, сишка все также незаменима на микроконтроллерах и embedded.
Да, attack surface меньше, тем не менее, раст не такой идеальный каким его многие описывают. Мне кажется, если не было фанатичной рекламы раста из всех щелей, то не было бы хейта в сторону раста и относились бы к нему спокойнее. Ну а так, мне кажется, что уже стоит начинать изучать раст, тем кто хочет в системщину, не обязательно писать, но уже даже мелкомягкие и мейнтейнеры линукса уже начинают работать с растом. Хотя, кмк, сишка все также незаменима на микроконтроллерах и embedded.
>>748854
Скопировало, спасибо.
Вот только теперь на стороне клиента ругается: Unexpected end of JSON input at JSON.parse (<anonymous>)
Что-то не нравится в сформированной строке.
Скопировало, спасибо.
Вот только теперь на стороне клиента ругается: Unexpected end of JSON input at JSON.parse (<anonymous>)
Что-то не нравится в сформированной строке.
>>749220
>>749220
Небольшое дополнение.
Есть функция вывода 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"}
>>749220
Небольшое дополнение.
Есть функция вывода 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"}
>>748906
чувак спрашивал, про касты указателей в указатели на константы, ты пишешь что-то ОЧЕНЬ implementation defined, и то, что в данном случае не имеет вообще никакого отношения к сути вопроса.
>.section .rodata
чувак спрашивал, про касты указателей в указатели на константы, ты пишешь что-то ОЧЕНЬ implementation defined, и то, что в данном случае не имеет вообще никакого отношения к сути вопроса.
>>748903
Язык обновили, баги исправили. Ты же тоже не пишешь на первой версии раста. Вот и C скакнул вперёд. А вы со своими спорами напоминаете мне кукареки смузихлёбов против PHP, вроде и дельная критика, а на деле выясняется что относится она к первым детским стандартам, а на том языке к которому критика относится уже никто не пишет много лет. В итоге слышу звон, да не знаю где он.
>>749114
Ну тут никаких утечек памяти ненужно. 1,3 гига - видимо предполагает что она уже везде где только можно протекла.
>А что сейчас поменялось?
Язык обновили, баги исправили. Ты же тоже не пишешь на первой версии раста. Вот и C скакнул вперёд. А вы со своими спорами напоминаете мне кукареки смузихлёбов против PHP, вроде и дельная критика, а на деле выясняется что относится она к первым детским стандартам, а на том языке к которому критика относится уже никто не пишет много лет. В итоге слышу звон, да не знаю где он.
>>749114
Ну тут никаких утечек памяти ненужно. 1,3 гига - видимо предполагает что она уже везде где только можно протекла.
>>749114
У раста нет нормального компилятора который берёт только то что используется кодом? Такая штука даже в делфях была, даже в паскале. Мол используешь мат функцию дискриминанта, в своём коде. Вот эти 16 строк и берёшь. В итоге даже жирные проекты не превышали 1.2 мегабайта. Неужели это какие-то забытые техники? Или там какое-то другое устройство бинарников?
>Как я понимаю это все скомпилированные зависимости
У раста нет нормального компилятора который берёт только то что используется кодом? Такая штука даже в делфях была, даже в паскале. Мол используешь мат функцию дискриминанта, в своём коде. Вот эти 16 строк и берёшь. В итоге даже жирные проекты не превышали 1.2 мегабайта. Неужели это какие-то забытые техники? Или там какое-то другое устройство бинарников?
70 Кб, 544x277Никогда не забывайте, что intN_t из stdint.h -- это optional типы данных. В некот. реализациях они могут НЕ поддерживаться.
>>750776
Очевидные сборки С99 под микруху
Очевидные сборки С99 под микруху
>>748885
В микропердолинге приходится нестандартными макросами и прагмами пояснять в какой именно флеш ты хочешь чтобы была переменная.
>Ну вообще в микропердолинге, например, приблизительно так и происходит. Всё зависит от платформы и компилятора.
В микропердолинге приходится нестандартными макросами и прагмами пояснять в какой именно флеш ты хочешь чтобы была переменная.
>>748725
Иди кури мат. часть. Константные данные записываются в .rdata (read-only data). Так уже лет 10, если не больше.
Иди кури мат. часть. Константные данные записываются в .rdata (read-only data). Так уже лет 10, если не больше.
89 Кб, 894x675>>750958
Нет, братан, это ты иди кури матчасть.
Пикрил:
константная целочисленная переменная sosatb, равная числу 1337, находится по адресу 0x7fffffffdf7c. При инспектировании адреса видно:
а) Этот адрес лежит в пределах лэйаута стэка - команда vmmap stack дает ренж адресов стэка, как видишь, адрес константной переменной лежит в этом ренже.
б) При обращении по адресу 0x7fffffffdf7c, видно значение 0x539 на стэке, что равно 1337 в десятичной системе исчисления.
Вывод - константная переменная находится непосредственно на стэке (нет никакого указателя на .rodata сегмент, как видишь), засим семантика языка С хэндлит такие ситуации, но никак не перемещение константных переменных в .rodata
Если тебе интересно что хранится в .rodata, могу дать пример - строковые литералы. То бишь, условный char* literal = "yayayoyo"; улетает в .rodata
На будущее, советую проверять подобные утверждения в отладчике, дабы не вводить в заблуждение маслят. Бобра!
Нет, братан, это ты иди кури матчасть.
Пикрил:
константная целочисленная переменная sosatb, равная числу 1337, находится по адресу 0x7fffffffdf7c. При инспектировании адреса видно:
а) Этот адрес лежит в пределах лэйаута стэка - команда vmmap stack дает ренж адресов стэка, как видишь, адрес константной переменной лежит в этом ренже.
б) При обращении по адресу 0x7fffffffdf7c, видно значение 0x539 на стэке, что равно 1337 в десятичной системе исчисления.
Вывод - константная переменная находится непосредственно на стэке (нет никакого указателя на .rodata сегмент, как видишь), засим семантика языка С хэндлит такие ситуации, но никак не перемещение константных переменных в .rodata
Если тебе интересно что хранится в .rodata, могу дать пример - строковые литералы. То бишь, условный char* literal = "yayayoyo"; улетает в .rodata
На будущее, советую проверять подобные утверждения в отладчике, дабы не вводить в заблуждение маслят. Бобра!
>>751106
Вперед меня успел посадить чела в лужу
Вперед меня успел посадить чела в лужу
>>751063
#define это по сути find & replace
До начала компиляции при условном макросе #define a b все а в текущем файле заменяются на b, ДО начала компиляции. Это не является переменной, скорее как магическое число (именно поэтому абьюз дефайнов превращает отладку в ад).
В случае с const, все происходит не ДО начала компиляции, а непосредственно ВО ВРЕМЯ компиляции, под переменную выделяется память, соответственно, у нее есть адрес.
#define это по сути find & replace
До начала компиляции при условном макросе #define a b все а в текущем файле заменяются на b, ДО начала компиляции. Это не является переменной, скорее как магическое число (именно поэтому абьюз дефайнов превращает отладку в ад).
В случае с const, все происходит не ДО начала компиляции, а непосредственно ВО ВРЕМЯ компиляции, под переменную выделяется память, соответственно, у нее есть адрес.
>>751110
Понял, спасибо.
Понял, спасибо.
>>751110
Текстовый макрос. Какое еще число, наркоман.
>Это не является переменной, скорее как магическое число
Текстовый макрос. Какое еще число, наркоман.
Как перестать тестировать вложенные циклы "на лету" и начать жить? Не могу в голове построить как оно будет работать, приходится шажками допиливать условия. Больше практики?
>>748725
Для полной ясности. Глобальные константы
char yoba[] = "yoba";
const float pi = 4;
будут размещены компилятором/компоновщиком в секции ro data, если таковая поддерживается.
Эта секция при исполнении помещается/отобращается в память read only, при наличии поддержки в ядре.
>Блядь, какой-то долбойоб прокукарекал про то, что const записывается в "read only" память. Нету такого говна, нету. const - тупо квалификатор типа, запрещающий определённые операции (модификации) на уровне синтаксиса, вот и всё.
Для полной ясности. Глобальные константы
char yoba[] = "yoba";
const float pi = 4;
будут размещены компилятором/компоновщиком в секции ro data, если таковая поддерживается.
Эта секция при исполнении помещается/отобращается в память read only, при наличии поддержки в ядре.
>>751140
Ты не знаешь что такое magic values?
#define MACRO 1337
...
int var = MACRO;
MACRO просто заменяется на 1337 во всех местах в текущем файле. Если макрос привязан к числу, то MACRO - магическое число без адреса в памяти, так как не является переменной. В чем проблема?
Ты не знаешь что такое magic values?
#define MACRO 1337
...
int var = MACRO;
MACRO просто заменяется на 1337 во всех местах в текущем файле. Если макрос привязан к числу, то MACRO - магическое число без адреса в памяти, так как не является переменной. В чем проблема?
>>751149
Это не константа, это обычная строка, не литерал. И если эта строка вне стэкового фрейма какой-либо из функций (то бишь глобальная), то такая строка улетит в .data сегмент, куда можно, разумеется, писать. Литерал же в любом случае улетает в .rodata, неважно глобальный он или же находится в стэковом фрейме одной из функций, которая его объявила.
Да, тут ты прав. Если эта константа глобальная, она улетит в .rodata. Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент, так как она не там в таком случае.
>char yoba[] = "yoba";
Это не константа, это обычная строка, не литерал. И если эта строка вне стэкового фрейма какой-либо из функций (то бишь глобальная), то такая строка улетит в .data сегмент, куда можно, разумеется, писать. Литерал же в любом случае улетает в .rodata, неважно глобальный он или же находится в стэковом фрейме одной из функций, которая его объявила.
>const float pi = 4;
Да, тут ты прав. Если эта константа глобальная, она улетит в .rodata. Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент, так как она не там в таком случае.
>>751158
Вы заебали выдавать детали реализации за истину.
Все зависит от компилятора, от флагов оптимизации, а в случае с float еще и от использования fpu или sse для плавающей точки. Алсо, .rodata - это линуксы. В винде оно может улететь в конец .text, в .rdata, да и в .data даже с какими-то компиляторами. В каком-нибудь ARM-коде оно может лежать в виде литерала прямо после функции, а функция, естественно, в .text.
Вы заебали выдавать детали реализации за истину.
> Если не глобальная, просто хранится на стэке в стэковом фрейме функции, где была объявлена, без референса в .rodata сегмент
Все зависит от компилятора, от флагов оптимизации, а в случае с float еще и от использования fpu или sse для плавающей точки. Алсо, .rodata - это линуксы. В винде оно может улететь в конец .text, в .rdata, да и в .data даже с какими-то компиляторами. В каком-нибудь ARM-коде оно может лежать в виде литерала прямо после функции, а функция, естественно, в .text.
>>751257
найс обосрался, анон
В моей компетенции можешь не сомневаться, а доебываться до слов - признак слабого ума и отсутствия контраргументаций
>пук среньк
найс обосрался, анон
В моей компетенции можешь не сомневаться, а доебываться до слов - признак слабого ума и отсутствия контраргументаций
>>751328
указывают на ошибку
@
ряяяяяя не доёбывайтесь до слов
Умный человек, которым ты не являешься, в случае ошибки признаёт ошибку и просит прощения за ошибку.
указывают на ошибку
@
ряяяяяя не доёбывайтесь до слов
Умный человек, которым ты не являешься, в случае ошибки признаёт ошибку и просит прощения за ошибку.
>>751106
Обосрался ты, маня, ведь в данном случае данные (инт) лежит в .text секции кода и уже после подгружается в стек. И так всегда было. Не до конца ты вкурил видимо, ну ничего, заглядывай к нам в асм тред, научим тебя.
Обосрался ты, маня, ведь в данном случае данные (инт) лежит в .text секции кода и уже после подгружается в стек. И так всегда было. Не до конца ты вкурил видимо, ну ничего, заглядывай к нам в асм тред, научим тебя.
>>715236
Непонятно, для каких конкретных жизненных задач может понадобиться непременно СПИСОК ВСЕХ UB БЕЗ РЕГИСТРАЦИИ И SMS. Сдается мне, у тебя какой-то реферат, сам смысл которого в том, чтоб ты, как раз таки, сам выколупывал крупицы знаний, и ты пришел с этим на двач. Аноны?
Непонятно, для каких конкретных жизненных задач может понадобиться непременно СПИСОК ВСЕХ UB БЕЗ РЕГИСТРАЦИИ И SMS. Сдается мне, у тебя какой-то реферат, сам смысл которого в том, чтоб ты, как раз таки, сам выколупывал крупицы знаний, и ты пришел с этим на двач. Аноны?
>>751141
Блок схема или расписывать на листочке как деление столбиком, не волнуйся это не овощной вариант, вложенные циклы контринтуитивны по дефолту
Блок схема или расписывать на листочке как деление столбиком, не волнуйся это не овощной вариант, вложенные циклы контринтуитивны по дефолту
>>715236
А вообще, UB - это то, что не определено стандартом, но и не запрещено. От компилятора к компилятору, так сказать.
А вообще, UB - это то, что не определено стандартом, но и не запрещено. От компилятора к компилятору, так сказать.
>>751356
Сосунок, ты думаешь я не знаю, что такое строка в Си? Что это нуль-терминированный массив символов? Камон, я писал драйвера и кастомный кернел с половиной кода на асме еще до того, как твой батя твою мамку тобою запузырил, не пытайся маняврировать, ты выглядишь нелепо. Единственное, что ты пытался сделать, это доебаться до слов, чтобы выйти из нелепой для себя ситуации.
Сосунок, ты думаешь я не знаю, что такое строка в Си? Что это нуль-терминированный массив символов? Камон, я писал драйвера и кастомный кернел с половиной кода на асме еще до того, как твой батя твою мамку тобою запузырил, не пытайся маняврировать, ты выглядишь нелепо. Единственное, что ты пытался сделать, это доебаться до слов, чтобы выйти из нелепой для себя ситуации.
>>751405
Маня, у тебя этот конст находится в стэковом фрейме функции и при обращении по адресу нет никакого адреса ни в какую секцию, а есть просто голое значение инта, че ты несешь? У тебя перед глазами вывод отладчика, а ты маняврируешь.
Более того, в .text секции хранится код, там пермишены read & execute, причем здесь переменные, ебалай? Они там не хранятся.
Если ты, уебок тупой, перепутал это с .data/rodata, то тоже нет, для этого переменная на пикриле должна быть глобальной, а не локальной. Проверь в отладчике.
Нихуя не знаешь и еще пытаешься выебываться. Пиздуй учить матчасть, щенок.
Маня, у тебя этот конст находится в стэковом фрейме функции и при обращении по адресу нет никакого адреса ни в какую секцию, а есть просто голое значение инта, че ты несешь? У тебя перед глазами вывод отладчика, а ты маняврируешь.
Более того, в .text секции хранится код, там пермишены read & execute, причем здесь переменные, ебалай? Они там не хранятся.
Если ты, уебок тупой, перепутал это с .data/rodata, то тоже нет, для этого переменная на пикриле должна быть глобальной, а не локальной. Проверь в отладчике.
Нихуя не знаешь и еще пытаешься выебываться. Пиздуй учить матчасть, щенок.
>>751477
Что ж вы такие сливные, я вам вывод отладчика на реальной программе даю с доказательствами, а вы маняврируете, лол :-) За мной аргументы и факты, за вами кукареканье. Так не интересно.
>пуксреньк
Что ж вы такие сливные, я вам вывод отладчика на реальной программе даю с доказательствами, а вы маняврируете, лол :-) За мной аргументы и факты, за вами кукареканье. Так не интересно.
>>751455
Ребёнок, ну прекрати проецировать и копипастить. Ты ведь даже 2/3 из написанного не понимаешь. Каждая твоя строчка пропитана жалким негативом, что выдаёт в тебе закомплексованного юношу. Нельзя так себя вести, не красиво. Соблюдай нормы приличия, ты всё-таки не в подворотне или /b.
Ребёнок, ну прекрати проецировать и копипастить. Ты ведь даже 2/3 из написанного не понимаешь. Каждая твоя строчка пропитана жалким негативом, что выдаёт в тебе закомплексованного юношу. Нельзя так себя вести, не красиво. Соблюдай нормы приличия, ты всё-таки не в подворотне или /b.
>>751487
Просто подумай (хотя бы в один прогон) над всем алгоритмом циклов до того как начнёшь писать даже основной.
Просто подумай (хотя бы в один прогон) над всем алгоритмом циклов до того как начнёшь писать даже основной.
>>751506
Я предоставил факты, вывод отладчика не врет. Спор против доказанных фактов - признак долбоеба и слабохарактерного червяка. С моей стороны пока были только факты и доказательства, вы пытаетесь здесь маняврировать и троллить тупостью, камон. Раскройте глаза/откройте сами отладчик и проверьте, это не так сложно. Гораздо проще, чем пытаться кого-то задеть на анонимной борде (лол) и спорить в лоб с доказательствами, не имея своих.
Я предоставил факты, вывод отладчика не врет. Спор против доказанных фактов - признак долбоеба и слабохарактерного червяка. С моей стороны пока были только факты и доказательства, вы пытаетесь здесь маняврировать и троллить тупостью, камон. Раскройте глаза/откройте сами отладчик и проверьте, это не так сложно. Гораздо проще, чем пытаться кого-то задеть на анонимной борде (лол) и спорить в лоб с доказательствами, не имея своих.
>>751471
Ебать рвет умника. Иди кури мет.)
mov DWORD PTR var$[rsp], 1337
mov DWORD PTR var$[rsp+4], 228
mov DWORD PTR var$[rsp+8], 1488
Ебать рвет умника. Иди кури мет.)
mov DWORD PTR var$[rsp], 1337
mov DWORD PTR var$[rsp+4], 228
mov DWORD PTR var$[rsp+8], 1488
>>743254
К сожалению, это наследие для обратной совместимости. Древние реализации имели другой синтаксис объявлений, а при отстутсвии объявления компилятор молча предполагал, что все аргументы 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
К сожалению, это наследие для обратной совместимости. Древние реализации имели другой синтаксис объявлений, а при отстутсвии объявления компилятор молча предполагал, что все аргументы 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
>>752091
для гуя укатывайся в какой-нибудь сисярп, Сишечка для лампового системного программирования, а не для формашлепства.
для гуя укатывайся в какой-нибудь сисярп, Сишечка для лампового системного программирования, а не для формашлепства.
>>752091
CreateWindowEx
CreateWindowEx
>>752104
Мне надо на осмноае Си исходника з\апилить приложення
Мне надо на осмноае Си исходника з\апилить приложення
>>752091
Opengl или win 32, для обоих доков миллионы, шизоидов сверху не слушай.
Opengl или win 32, для обоих доков миллионы, шизоидов сверху не слушай.
Да що это такое ваше системное программирование я хуй пойму. Это получается все эти ваши ебомбаные ядра линупса и другие дрочева для взаимодействия оси с железом или даже что повыше? И какие показатели заработной платы у всей цей хуебты для условного джуна-мидла на it рынке ммм? И сколько вы по времени в это всё вкатывались до уровня достойной зп? Можно ли жить на одной шишечке без крестов или с ними получаемые мной сабжики вырастут по экспоненте?
>>752318
В странах СНГ системщики маловостребованы и им хуево платят.
Забугром системщики зарабатыват больше жс-макак, как это и полагается.
В странах СНГ системщики маловостребованы и им хуево платят.
Забугром системщики зарабатыват больше жс-макак, как это и полагается.
Анон, помоги ебану (мне) найти доки на сишную обёртку тессеракта, или хотя бы на крестовую
>>752406
А что это за забугор такой ты мне скажи а то я хз. Вот я в Финке живу це забугор уже или ещё нет? Знаю типа из россиюшки который катает 1 неделю в месяц по всем кокотельным своего города, редачит там что-то на сишке пару часов и получает за это 200к в месяц.
А что это за забугор такой ты мне скажи а то я хз. Вот я в Финке живу це забугор уже или ещё нет? Знаю типа из россиюшки который катает 1 неделю в месяц по всем кокотельным своего города, редачит там что-то на сишке пару часов и получает за это 200к в месяц.
>>752576
Ты или тралль-абсрактушок-пиздабол или что-то перепутал.
По котельным катаются вот эти ребята:
https://2ch.hk/wrk/res/1998066.html (
М)
И прогают там не на С, а на диалекте паскаля (ST), а то и вовсе мышкой (LD, FBD).
Ты или тралль-абсрактушок-пиздабол или что-то перепутал.
По котельным катаются вот эти ребята:
https://2ch.hk/wrk/res/1998066.html (
М)И прогают там не на С, а на диалекте паскаля (ST), а то и вовсе мышкой (LD, FBD).
>>752580
Это то, что мне рассказывает знакомый. Как там на самом деле - я без понятия. Может он аптекарем работает.
0 мотивации. Просто интересно узнать на хороший ли путь я встал.
Это то, что мне рассказывает знакомый. Как там на самом деле - я без понятия. Может он аптекарем работает.
>тралль
0 мотивации. Просто интересно узнать на хороший ли путь я встал.
>>752583
Ну, если цель - попасть в железячный интырпрайз вроде телекома или прочих нвидий или на худой конец - прошивки для индезита писать в конторе-подрядчике - то да.
Если разрабатывать аналоговнет в засаленной ниишке с тащмайором за спиной и подпиской о невыезде - то нет
Ну, если цель - попасть в железячный интырпрайз вроде телекома или прочих нвидий или на худой конец - прошивки для индезита писать в конторе-подрядчике - то да.
Если разрабатывать аналоговнет в засаленной ниишке с тащмайором за спиной и подпиской о невыезде - то нет
>>752318
В юзерленде это разработка демонов, какие-нибудь движки баз данных, что-то для виртуализации/эмуляции. Плотют за такое хорошо (100-200), если компания крупная, в других хз. На шишечке самое то писать ядрышки и демоны, а в проекте покрупнее быстро вляпаешься в плюсы.
В юзерленде это разработка демонов, какие-нибудь движки баз данных, что-то для виртуализации/эмуляции. Плотют за такое хорошо (100-200), если компания крупная, в других хз. На шишечке самое то писать ядрышки и демоны, а в проекте покрупнее быстро вляпаешься в плюсы.
>>752596
Яснооо. А как обстоят дела с временем вката? Как многие любят писать ~10 лет или получше? Сейчас Прату читаю, там хоть какая-то база для этого будет?
Яснооо. А как обстоят дела с временем вката? Как многие любят писать ~10 лет или получше? Сейчас Прату читаю, там хоть какая-то база для этого будет?
>>752675
Если ты нуб и тебе интересно низкоуровневое программирование/системщина, то надо самообучаться лет пять (в т.ч. копать чужой код), чтобы нахуячить приличный код для резюме и ответить на каверзные вопросы. Дальше еще 5-10 лет настоящих задач, чтобы стать профи. Повышение зряплаты при этом зависит от галеры.
Не читал.
>А как обстоят дела с временем вката?
Если ты нуб и тебе интересно низкоуровневое программирование/системщина, то надо самообучаться лет пять (в т.ч. копать чужой код), чтобы нахуячить приличный код для резюме и ответить на каверзные вопросы. Дальше еще 5-10 лет настоящих задач, чтобы стать профи. Повышение зряплаты при этом зависит от галеры.
>Прата
Не читал.
>>752576
США, Израиль и Германия. Про другие не скажу, ибо не знаю.
США, Израиль и Германия. Про другие не скажу, ибо не знаю.
Стоит ли читать книгу по устаревшему стандарту?(Керниган, Ричи 2 издание) или лучше поискать что-то поновее. Хочу вникнуть в азы си и перекатиться на плюсы.
>>753327
Да там немного осталось, за пару дней осилю и за си++ уже детально возьмусь. Просто на си лабы писал и если что на крестах можно как на си писать(вроде)
Да там немного осталось, за пару дней осилю и за си++ уже детально возьмусь. Просто на си лабы писал и если что на крестах можно как на си писать(вроде)
1 Кб, 276x263Анончики, помогите пожалуйста.
Я знаю что этот вопрос уже всех заебал, но все же.
КАК нарисовать линию или там кружочек?
graphics.h??
Я знаю что этот вопрос уже всех заебал, но все же.
КАК нарисовать линию или там кружочек?
graphics.h??
>>753470
Надо оконное приложение создавать. Оно на каждой платформе по-своему делается, либо кросплатформенную либу использовать.
Надо оконное приложение создавать. Оно на каждой платформе по-своему делается, либо кросплатформенную либу использовать.
42 Кб, 1366x768Почему у меня все переменные типа дабл, а после операций с ними получается 0.000000? В каком месте происходит data conversion?
>>753635
Ок, там не в этом дело.
Ок, там не в этом дело.
>>753605
>>753606
Простите, сегодня перечитал свой вопрос, никакой дополнительной информации не предоставил.
Итак:
Win10
Code::Blocks + очевидный MinGW (шел вместе с CodeBlocks, должен быть последний).
* Из чтения разной документации пришел к выводу что больше всего мне подходит SDL2.
В гугле полно видео от индусов, но нихера не работает.
>>753606
Простите, сегодня перечитал свой вопрос, никакой дополнительной информации не предоставил.
Итак:
Win10
Code::Blocks + очевидный MinGW (шел вместе с CodeBlocks, должен быть последний).
* Из чтения разной документации пришел к выводу что больше всего мне подходит SDL2.
В гугле полно видео от индусов, но нихера не работает.
>>753927
CreateWindowEx и весь стандартный win32 gui app skeleton, который можно без проблем спиздить в гугле. По WM_PAINT ты просто BeginPaint/LineTo/ArcTo/EndPaint и все.
SDL тебе никаким образом тут не поможет, она про растровую графику, свои кружочки тебе придется по точечкам рисовать. OpenGL как бы умеет в линии, но это функциональность давно deprecated, а в современном OpenGL линии принято рисовать длинными и тонкими треугольниками. Поэтому из всех вариантов GDI - самый простой способ.
CreateWindowEx и весь стандартный win32 gui app skeleton, который можно без проблем спиздить в гугле. По WM_PAINT ты просто BeginPaint/LineTo/ArcTo/EndPaint и все.
SDL тебе никаким образом тут не поможет, она про растровую графику, свои кружочки тебе придется по точечкам рисовать. OpenGL как бы умеет в линии, но это функциональность давно deprecated, а в современном OpenGL линии принято рисовать длинными и тонкими треугольниками. Поэтому из всех вариантов GDI - самый простой способ.
>>754137
Это говорят про GDI+ (хотя GDI+ тоже можно, если заморочиться), а я говорю про GDI. Ничего серьезного на GDI давно не делают, но оно по-прежнему поддерживается, работает в любой винде, и достаточно просто в использовании: https://pastebin.com/raw/7nu7GzsP
Это говорят про GDI+ (хотя GDI+ тоже можно, если заморочиться), а я говорю про GDI. Ничего серьезного на GDI давно не делают, но оно по-прежнему поддерживается, работает в любой винде, и достаточно просто в использовании: https://pastebin.com/raw/7nu7GzsP
Как начать понимать чужой код на си? Я открыл случайный проект на гитхабе, а там куча папок и хрен знает что за каждая отвечает. Что мне нужно гуглить, чтобы понимать(хотя бы почему так располагаются файлы и где главная функция)?
>>711268 (OP)
Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
Где его можно посмотреть?
Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
TL;DR ищу гайд для написания lite аналога partition wizard с нуля.
Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
Где его можно посмотреть?
Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
TL;DR ищу гайд для написания lite аналога partition wizard с нуля.
>>754252
Форматирование это по сути создание базы данных на носителе. Посмотреть начиная с педевикии и списка источников.
Вручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера - это кремнием в транзисторах контроллера USB зашито.
Короч, тебе танненбаума "архитектура компьютера" внутривенно 2 раза в день до появления понимания.
>Форматирование флешки (в NTFS, например) это просто запись некоторого двоичного кода (одинакового для всех флешек)?
>Где его можно посмотреть?
Форматирование это по сути создание базы данных на носителе. Посмотреть начиная с педевикии и списка источников.
> Алсо, как проводится запись на флешку? Я знаю что у usb 1 пин для получения данных, но как на него подавать напряжение (вручную) чтобы что-то писалось? Где это всё можно посмотреть?
Вручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера - это кремнием в транзисторах контроллера USB зашито.
Короч, тебе танненбаума "архитектура компьютера" внутривенно 2 раза в день до появления понимания.
>>754182
Всем спасибо, нашел WinBGIm, все просто и заебись.
Всем спасибо, нашел WinBGIm, все просто и заебись.
>>754270
Вручную сорт оф можно. Гугли, например, какой-нибудь AVR USB bitbanging.
> ручную ты никак не подашь напряжение даже на ассемблере даже на самом низком уровне драйвера
Вручную сорт оф можно. Гугли, например, какой-нибудь AVR USB bitbanging.
>>754182
Анончик, клянусь, несколько часов ищу хоть какую-то инфу про gdi, но ничего.
Где хоть пример есть на си?
Спасибо!
другой анон
Анончик, клянусь, несколько часов ищу хоть какую-то инфу про gdi, но ничего.
Где хоть пример есть на си?
Спасибо!
другой анон
>>754355
>>754353
Анон, послушай меня, самый простой способ и стаковерфлоу со мной согласен это bgi turbo c через dosbox.
В свое время я так и писал простенькую графику, рад в 21м веке узнать что нихуяшеньки не изменилось.
Новичку в си другого выбора не дано, то что тут выложено в gdi через указатели с нулем инфы и спецификаций. И то хуй найдешь.
Удачи вам.
>>754353
Анон, послушай меня, самый простой способ и стаковерфлоу со мной согласен это bgi turbo c через dosbox.
В свое время я так и писал простенькую графику, рад в 21м веке узнать что нихуяшеньки не изменилось.
Новичку в си другого выбора не дано, то что тут выложено в gdi через указатели с нулем инфы и спецификаций. И то хуй найдешь.
Удачи вам.
>>754182
добавил в compiler options:
-Wall -Wextra -pedantic -Wno-unused-parameter -std=c11
добавил в linker options:
-luser32 -lgdi32
А такое чтобы сразу работало есть?
добавил в 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
А такое чтобы сразу работало есть?
107 Кб, 1054x690>>754182
Ах тыж питрасян :))
Через CMD скомпилилось без ошибок, а через ide хуй.
Stackoverflow говорит что я пытаюсь создасть -64 приложение на -32 библиотеке. Но это мне ни о чем не говорит. ПАМАГИТИ.
Ах тыж питрасян :))
Через CMD скомпилилось без ошибок, а через ide хуй.
Stackoverflow говорит что я пытаюсь создасть -64 приложение на -32 библиотеке. Но это мне ни о чем не говорит. ПАМАГИТИ.
>>754097
Линии прекрасно рисуются и в Вулкане, и в DX12, сажедебил
>OpenGL как бы умеет в линии, но это функциональность давно deprecated
Линии прекрасно рисуются и в Вулкане, и в DX12, сажедебил
>>754239
Читать чужой код всегда стрёмно, а впопенсорс тем более, просто читай и кровавыми руками пытайся разобраться
Читать чужой код всегда стрёмно, а впопенсорс тем более, просто читай и кровавыми руками пытайся разобраться
Поясните за IDE. VS же считается топом? А норм она в самом начале изучения языка? Вчера полчаса ебался с scanf_s поэтому интересно какие косяки могут быть впереди. Codeblocks не выношу из-за ущербного интерфейса и ужасной настройки внешнего вида из-за которой я не могу сделать себе ламповый чёрный интерфейс. И почему вообще в разных IDE абсолютно идентичный код может давать разный вывод? Как это доджить?
>>754374
Ну если тебе просто кружочек нарисовать, то самый простой способ - это JS и <canvas>, там даже устанвливать ничего не нужно. Я думал, мы о чем-то практически применимом разговариваем.
В 21 веке завезли сишный апи для Skia, например. Признайся, ты просто не хочешь изучать ничего нового.
MSDN более чем достаточно, там не только описания функций есть, но и вводные статьи, вот потыкай: https://docs.microsoft.com/en-us/windows/win32/gdi/windows-gdi Но для неосиляторов раньше специальная книжка была Feng Yuan "Windows Graphics Programming".
>>754469
Для серьезных проектов. Для хелловорлдов - что угодно, хоть вимы, хоть вскоды и саблаймы, хоть clion.
Один запрос в гугле, первый результат. Или можно смириться и писать, как хочет MS.
Некоторые возможности из C11 поддерживаются только с бубном. Например, надо запустить VS Installer и доустановить там clang.
IDE тут не при чем. Это проблемы твоего кода. Нормально пиши - нормально будет.
> dosbox
Ну если тебе просто кружочек нарисовать, то самый простой способ - это JS и <canvas>, там даже устанвливать ничего не нужно. Я думал, мы о чем-то практически применимом разговариваем.
> в 21м веке узнать что нихуяшеньки не изменилось
В 21 веке завезли сишный апи для Skia, например. Признайся, ты просто не хочешь изучать ничего нового.
> с нулем инфы и спецификаций
MSDN более чем достаточно, там не только описания функций есть, но и вводные статьи, вот потыкай: https://docs.microsoft.com/en-us/windows/win32/gdi/windows-gdi Но для неосиляторов раньше специальная книжка была Feng Yuan "Windows Graphics Programming".
>>754469
> VS же считается топом
Для серьезных проектов. Для хелловорлдов - что угодно, хоть вимы, хоть вскоды и саблаймы, хоть clion.
> Вчера полчаса ебался с scanf_s
Один запрос в гугле, первый результат. Или можно смириться и писать, как хочет MS.
> какие косяки могут быть впереди
Некоторые возможности из C11 поддерживаются только с бубном. Например, надо запустить VS Installer и доустановить там clang.
> И почему вообще в разных IDE абсолютно идентичный код может давать разный вывод?
IDE тут не при чем. Это проблемы твоего кода. Нормально пиши - нормально будет.
>>754578
Да вот нифига, я несколько ссылок пролистал где подсказывали отлючать проверку через дефайн, а надо было в настройках проекта. Но ебался я с тем, как указывать размер буфера для ввода.
>первый результат
Да вот нифига, я несколько ссылок пролистал где подсказывали отлючать проверку через дефайн, а надо было в настройках проекта. Но ебался я с тем, как указывать размер буфера для ввода.
>>754654
Типичный двачер - справляется руками.
Типичный двачер - справляется руками.
>>754645
gcc, clang, алло
gcc, clang, алло
https://2ch.hk/pr/res/1711268.html (М)
>>739810
Зачастую, кстати, у С-дедов такие библиотеки дают лучшую производительность, чем у С++-миллениалов. Быстрее только на чистом ассемблере. Деды в целом и это могут, но долго это. Поэтому на чистом ассемблере пишут только местами: ту логику/вычисления, которая исполняется 85-99% от общего времени.
М)>>739810
> Для Си умельцы скорее всего тоже либ уже налепили.
Зачастую, кстати, у С-дедов такие библиотеки дают лучшую производительность, чем у С++-миллениалов. Быстрее только на чистом ассемблере. Деды в целом и это могут, но долго это. Поэтому на чистом ассемблере пишут только местами: ту логику/вычисления, которая исполняется 85-99% от общего времени.
>>721022
ну да, сишная
ну да, сишная
>>724593
для гейбдева
для гейбдева
>>724624
это довольно просто
это довольно просто
>>725291
было бы странно если бы libc была не на си
было бы странно если бы libc была не на си
>>729355
по фактам
по фактам
Тред утонул или удален.
Это копия, сохраненная 26 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.