[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 30720 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1607594481923.jpg -(78494 B, 341x500) Thumbnail displayed, click image for full size.
78494 No.183736  

Как быстро вкатиться в сишку до уровня модификации чужих кодов? Есть некоторые проекты на гитхабе, которые я хотел бы исправить как считаю нужным. Но я очень плохо знаю Си, в основном пишу на golang'е да питоне. Времени не очень много, хотелось бы чуть не завтра уже присылать пулреквесты.

>> No.183740  

>>183736
https://ru.wikibooks.org/wiki/Язык_Си_в_примерах
Си вообще простой для понимания язык, если умеешь программировать. Но программировать на нем сложно из-за того что можно ненароком отстрелить себе ногу указателем.

>> No.183834  

>>183736

>Как быстро вкатиться в сишку до уровня модификации чужих кодов?

K&R2

http://iso-9899.info/wiki/Books

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

Можешь устать потом свой форк поддерживать

>Времени не очень много, хотелось бы чуть не завтра уже присылать пулреквесты.

Об этом сложно говорить оптимистично

>>183740

http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avoided
Wikibooks говно чаще всего

>> No.187689  
File: 1615484410504.pdf -(5648293 B, 0x0) Thumbnail displayed, click image for full size.
5648293

Автор книги Robert C. Seacord

>is on the Advisory Board for the Linux Foundation and an expert on the ISO/IEC JTC1/SC22/WG14 international standardization working group for the C programming language. http://robertseacord.com/wp/
>> No.187691  

Если кто-то найдёт шапку с арисучана то можно будет сделать полноценный Си тред.

>> No.187693  

https://www.youtube.com/watch?v=3JTwA5IOq7I

>> No.187701  
File: 1615487921991.jpg -(269629 B, 1191x670) Thumbnail displayed, click image for full size.
269629

>>187692
А что там с памятью такого сложного, что нельзя изучить за вечер? От регистров сишечка абстрагирует, понять, как работают указатели и в чём разница между memcpy и memmove много времени не надо. Сишечка как раз предельно проста в плане теории (в отличии плюсов) и основное время обучения занимают алгоритмы, структуры данных и общая культура написания кода.

>> No.187702  

>>187701
Покажи мне свой код на C /я смотрю мне тут не рады :)

>> No.187703  

>>187694
Я кажется знаю почему удалили. Я хотел на твой пост ответить, но не твой вопрос. Потому что вопрос идиотский. Нет, не потому что ответ очевиден, это как раз было бы простительно, проблема в том, что твой вопрос не снабжён никакими сведениями, которые помогли бы дать ответ. А ведь как известно половина ответа, это хорошо заданный вопрос.

>>187692

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

Может, чтобы грамотно, однако для первых глав Кернигана и Ритчи хватит простого понимания отличия стека от кучи, точнее того как с ними работать. А дальше дело наживное. Справедливо было бы также добавить, что и на первых курсах университетов, такому также не учат. Зато есть охрененные таблицы на слайдах о том какой тип данных какое максимально большое число может себя вместить на конкретной, сцуко, архитектуре. Не то как это посчитать самому даже. Впрочем, говорю за свою шарагу^W университет.
Самообразование – это наш путь!

>> No.187704  
>Самообразование – это наш путь!

Вот поэтому я и говорю, если у тебя только теория из слайдов и не было толкового наставника, который лепил бы тебе "подзатыльники" ты будешь ловить *bufferoverflow всю оставшуюся жизнь. Те умные люди, кто это понял, перешли на python.

>> No.187705  
File: 1615489950701.pdf -(5708538 B, 0x0) Thumbnail displayed, click image for full size.
5708538

>>187704

> не было толкового наставника, который лепил бы тебе "подзатыльники" ты будешь ловить *bufferoverflow всю оставшуюся жизнь.

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

А вообще ещё есть статические анализаторы кода, ну и можно на чужих ошибках учиться.

>Те умные люди, кто это понял, перешли на python.

Хех, PEP7.

>> No.187706  

>>187703

>Самообразование – это наш путь!

Увы, да. Люто, бешено новерьчую о вузах. Касается всех предметов. Говорю за киевский вуз.

>> No.187707  
File: 1615490901642.jpg -(101178 B, 600x750) Thumbnail displayed, click image for full size.
101178

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

>перешли на python

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

>> No.187710  

>>187707

>Поэтому надо переходить на rust

Не надо пожалуйста продолжать. У раст есть свои недостатки, а именно свой форк llvm и херовая поддержка большинства платформ, компилятор Си написать существенно проще. Кодовая база на раст с трудом может быть поддержана в том состоянии, чтобы всё было безопасно, о чём есть пост майнтейнера генты.
https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/

>> No.187711  

>>187707

>он, скорее всего, ёбнутый

Скорее всего у него просто высокий уровень инженерного мастерства. У меня сейчас в доработке под руками борда на чистых сях. Без питонов, perl-ов и прочих php-bloat. Весом без капчи в 350кб. Видимо я ёбнутый.

>> No.187713  

>>187711
Если ты от этого ловишь кайф, то круто же.
Я вот как давно ёбнутый скажу, что если пить таблетки и не выёбываться, то все не так плохо будет.

Кстати, твоя борда никак вот с этим[0] стеком не связана ?
[0]: https://learnbchs.org/

>> No.187715  

>>187713
Нет. Я же сказал без BloatTM. А у тебя по ссылке микромускул )

>> No.187716  
File: 1615498395909.jpg -(42406 B, 736x414) Thumbnail displayed, click image for full size.
42406

>>187711

> У меня сейчас в доработке под руками борда на чистых сях.

Покажи исходники? Я тем же занимаюсь. Принимать GET/POST-запросы оказалось довольно просто, и делает всё это бинарий весом в 22 килобайта. Для компиляции достаточно tcc, который на дискетку умещается (код соответствует стандарту C89).

>> No.187740  

>>187716
Удваиваю. Было бы интересно поглядеть.

>> No.187746  
File: 1615542377964.png -(0 B, 226x256) Thumbnail displayed, click image for full size.

>>187716
>>187740
Я подумаю

>> No.187774  

>>187705

Забыл вот здесь написать, что это книга «C Traps and Pitfalls».
Немного старовата, но до сих пор применима. Она о том как делать НЕ НАДО. По этой теме ещё можно почитать здесь:
https://wiki.sei.cmu.edu/confluence/display/c

>> No.187785  

>>187711
Определённо. Я могу предположить только один смысл писать борду на си.

>> No.187787  

>>187774
Как НЕ НАДО делать. Говорит и показывает Брайан Кёрниган.
https://yewtu.be/8SUkrR7ZfTA
И заметки о книге, которую он упомянул.
https://wozniak.ca/blog/2018/06/25/1/index.html

>>183736
Си — не тот язык, в который можно «быстро вкатиться».

>> No.187821  
File: 1615588819360.jpg -(247845 B, 442x551) Thumbnail displayed, click image for full size.
247845

Нет ничего проще чем Си.
Чтобы понять основной синтаксис достаточно одной книги и никаких подвохов не будет. Я лично в свое время прочел "Программирование на языке Си Подбельский В.В., Фомин С.С.". Книга древняя, но и большинство компиляторов поддерживают по умолчанию древние стандарты. Даже не знаю чего там в новых стандартах добавили. Мне до сих пор компилятор ругается что я int i в for объявить не могу.
Да, нужно понимать распределение памяти, но что может быть проще чем понять линейное пространство памяти в байтах.
Если мне дать волю, то я бы всех учил Си как первому языку программирования.

>> No.187825  
File: 1615593102848.png -(1242462 B, 811x1155) Thumbnail displayed, click image for full size.
1242462

А есть что-то на русском и для тех у кого С это первый язык? Язык, в котором вообще непонятно что происходит?

>> No.187826  

>>187821
Столяров с тобой не согласен. Под статьёй длинное обсуждение подводных камней применения Сишки в учёбе.
http://www.stolyarov.info/pvt/anti_c

>> No.187828  

>>187825
на русском есть LuaRu и 1С

>> No.187838  
File: 1615628219007.pdf -(4617542 B, 0x0) Thumbnail displayed, click image for full size.
4617542

>>187825

>А есть что-то на русском и для тех у кого С это первый язык?

Переведённый на русский K&R2. А вообще дальше для чтения мануалов всё равно будет нужен английский, так что учи. Можешь уже сейчас их читать со словарём типа мультитрана, там часто есть графа о том, что слово значит в контесте математики или программирования.

>> No.187841  

>>187821

>Даже не знаю чего там в новых стандартах добавили

_Generic в C11
bool в С99

>Мне до сих пор компилятор ругается что я int i в for объявить не могу.

У меня такое было когда я в gcc указывал -std=c89 или оставлял дефолтные значения решается просто тем, что устанавливаешь другой стандарт, например c99
>>187826
В шапке Си треда на арисучане тоже было сказано, что этот язык не стоит изучать первым, ну наверное. У меня нет преподавательского опыта, чтобы об этом говорить. Потом постараюсь на твой пост более развёрнуто ответить.

>> No.187842  

>>187838
Спасибо, выглядит как то что нужно. А этот словарь есть на убунту и оффлайн?

>> No.187847  

>>187842

>А этот словарь есть на убунту и оффлайн?

Конкретно этот нет, но у тебя в зависимости от дистрибутива уже может быть клиент для словарей, который работает со словарями типа dict.org И естественно, если поднять у себя на компьютере такой же сервер как на dict.org, то оно будет и оффлайн работать. Но, мне кажется, что это уже сложно звучит, поэтому я на всякий случай ещё оповещу о возможности купить просто словарь в формате бумажной книги.
Словарный запас это вообще не так важно, если учишь язык, то тебе гораздо важнее понять как строятся предложения. Если переводить мануалы, то только научишься переводить мануалы. Тебе важно не найти аналог слова «из английского» на русском, а понять, что слово значит в нужном тебе контексте. Ну и не бойся ошибки делать.

>> No.187850  

>>187847

> поднять у себя на компьютере такой же сервер как на dict.org

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

>> No.187851  

>>187850

>В мое время не нужен был целый сервер для того чтобы пользоваться таблицой с двумя колонками - слово и определение.

Тоже подход, но это не такой же поисковик по толковым словарям как dict.org

Иногда я могу всё переусложнять, извините.

>> No.187852  

>>187826
Глянул бегло. Аргументы основываются на тотальном непонимании слушателями принципов работы ЭВМ и ОС. В таком случае, в начале стоит дать лекцию по архитектуре вычислительных систем, и уже потом перейти к. Ибо лучше не программировать то, не знаю что.

К лекции можно добавить ASM, нолики и единички, и пройтись с GDB по Hello World’у без libc на системных вызовах; и чем цветастей подсветка, тем, больше внимание неподготовленных слушателей из-за ассоциаций происходящего с образом кулхацкеров в media.

Короче, человек пытается начинать с абстрактных концептов, а уже потом говорит, как они map’ятся на реальность. А делать тут стоит либо наоборот, либо параллельно с, ящитаю. Тогда и проблем с понятием указателя не будет.

>> No.187854  

>>187852
дай-ка я тебя обниму

>> No.187868  
File: 1615675433802.jpg -(267165 B, 1920x1080) Thumbnail displayed, click image for full size.
267165

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

>> No.187874  

>>187852
Так можно научить только тех, кто уже имеет склонность к программированию, в то время как задача преподавателя дать общие представления о программировании каждому
>>187854
Отсосать не забудь

>> No.187875  

>>187874

>склонность к программированию

Это больше склонность к магии или склонность к технологии?

>> No.187884  

>>187875
Хуй знает, но одни стремятся к знаниям наперекор всему а других не может научить даже ментор.

>> No.187886  

>>187852

> Аргументы основываются на тотальном непонимании слушателями принципов работы ЭВМ и ОС.

Это косвенная причина.
Доводы о сложности понимания самого языка тоже есть — в сравнении с приветмиром на Паскале. Препроцессор и побочные эффекты, в частности. Амперсанд перед именами переменных — это зачем? И тут оказывается, что даже перед разъяснением таких простых программ придётся подать кучу вспомогательного материала.
А ещё такая мелочь, попробуй объяснить виндузятнику с первого раза, что такое '\n'. Перевод строки в ЦОММАНД.ЦОМ выводится сам перед промптом.
Остальное мне трудно оценивать просто потому, что я уже понимаю Сишку и обратно распонять её не смогу.
Автор не утверждает, что учить Си в целом трудно, только что как первый язык заходить будет тяжеловато. И только в том ВУЗе, в котором он тогда работал.

>> No.187889  

>>187886
Так говоришь, как будто виндузятники тупые по сравнению с кем?, а это далеко не так.

>>187868
Никак. Все курсы - это просто способ состричь бабла с хомяков.

>> No.187892  

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

>> No.187893  

>>187889

>Все курсы - это просто способ состричь бабла с хомяков.

Все ? Даже бесплатные с MIT OCW ? Курсы с coursera ?

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

>> No.187895  

>>187893
Ну а почему ты думаешь они бесплатные?

>> No.187899  
File: 1615729643299.jpg -(213652 B, 1920x1080) Thumbnail displayed, click image for full size.
213652

>>187895
Почему ? Скажи ты.

>> No.187904  
File: 1615731080330.jpg -(164124 B, 1134x872) Thumbnail displayed, click image for full size.
164124

>>187889

>Все курсы

перестал читать

>> No.187946  

>>187899
Я писал писал, а мой ответ потёр модератор.

>> No.187948  

>>187946

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

>> No.187953  
  1. FOSS *nix
  2. valgrind
  3. ???
  4. profit

Серьёзно, писать на C без valgrind'а или под проприетарной осью ни разу не весело

>> No.187954  

>>187948
Что-то там переписывать ради троллей... ну такое.

>> No.187955  

>>187821
Я не знаю что за компилятор тебе ругается на конструкцию из c99 в 2021. c17 уже на дворе, c2x скоро выходит, пора бы и обновить свою пятую фряху.

>> No.187957  

На самом деле писать на C просто, только немного муторно делать весь бойлерплейт с обработкой ошибок и буфферами руками.

Хорошей практикой будет реализация своих версий библиотек для

  • работы с индексированными (хранимыми вместе с длиной) строками, с методами как минимум для new/free, reverse, concat, substring.
  • для реаллоцируемых списков -- опять же, new/free, append, remove, sublist.
  • для linked-list'ов -- попробуй нивную реализацию, потом посмотри как linux linked lists концептуально реализованы и попробуй запилить свои макросы для того же.
  • для деревьев -- попробуй реализовать разные, начиная от просто binary tree до avl, red-black и прочих самобалансирующихся. потом можешь ещё и b-tree попробовать.
  • для хешмап -- с разными алгоритмами хеширования и кластеризации бакетов
  • для аллокации памяти -- бери sbrk и делай свой malloc
  • для парса аргументов -- попробуй сделать свой getopt с лягушками и ледяными феями вроде автохелпа

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

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

Читай так же сорцы реальных проектов, хорошими примерами будут ядро linux, nginx, сорцы всего openbsd, включая libre* -- запоминай техники, подходы. Избегай по-возможности стилей и подходов GNU-проектов, они так себе в большинстве своём.

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

Когда будет достаточно уверенности - попробуй взять какой-нибудь FOSS проект и запилить в него какую-нибудь фичу. Это на самом деле проще чем кажется и на MR/патче в мейллист тебе сделают ревью и скажут что поправить и что можно сделать лучше.

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

>> No.187958  

>>187957
Паста или сам писал?

>> No.187960  

>>187958
Сам же

>> No.187962  

>>187960
Ты классный, я бы хотел общаться с такими как ты, может быть даже дружить.

>> No.187965  

>>187962
Не уверен как реагировать. Думаю ты даёшь мне многовато кредита в силу каких-то заблуждений. Я на самом деле унылая колбаса, которая еле шевелится и ничего не соображает, но думает что всё может, если захочет.

В любом случае, треды тут сейчас интересные, мне нравится.

>> No.187966  

>>187965
Просто понравилась твоя паста, никакого кредита.

>> No.187983  

>>187965
"Во-вторых я ничего не знаю, просто очень хорошо умею притворяться что я всё знаю", хм.

>> No.188126  

Просто нужно понять что такое pointer - всё, ты выучил C.

>> No.188127  
File: 1616027049925.png -(9945 B, 340x109) Thumbnail displayed, click image for full size.
9945

>>188126

Хотелось бы чтобы это голословное утверждение было чем-нибудь подкреплено. Например было бы неплохо знать, что подразумевается под словом «понять». Знать определение указателя, пару раз применять их так как это написано в мануалах к стандартной библиотеке и использовать указатель на указатель, чтобы посередине связанного списка что-то вставить это разные вещи. Кстати о последнем два годных видео с участием профессора Брэйлсфорда на конструкторе лего показывающего некоторые нюансы использования указателей.

https://youtu.be/t5NszbIerYc
https://youtu.be/0ZEX_l0DFK0

>> No.188137  

Машинный код --> язык ассемблера --> язык C --> язык С++

Иначе до полного понимания не выучишь.

>> No.188138  

>>188137
Бред. Но написать свою VM для вымышленного байткода будет полезно с точки зрения понимания, как всё устроено

>> No.188140  

Думаю, ++ после C не обязательно, если нет целей туда идти. ООП паттерн можно и средствами C делать; более того, стоит понимать, как. После C лучше языки высокого уровня, на их примере рассмотрев отражения, метапрограммирование, атрибуты, компонентные модели и другие удобные и выразительные фичи.

>> No.188141  

>>188140
Рефлексию некорректно переводить как отражение.

>> No.188162  

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

>> No.188164  

>>188162
Нет.

>> No.188165  

>>188162

> Вас не бесят эти убогие хидеры на файлах с этой убогой капчей?

Нет.

>> No.188169  

>>188162
Искренне считаю вакабу самым оптимальным движком на данный момент.
Хорошо было бы внести пару изменений для условных noko, ютуб-embed и прочих мелочей, но оно уже прекрасно.
Капча даже лучше мятной.

>> No.188170  

>>188169

> ютуб-embed

Хотет. Надоели костыли с юзерскриптами

>> No.188172  

>>188162
Нормальные хидеры не видел? А pdf-preview вместо иконки убогой тоже? Мне тебя всех тут жаль.

>> No.188173  

>>188170
Что-то вроде: https://termbin.com/x5vu
Но это для 3.0.8 и слишком хлопотно будет внедрять в живой новерь, думаю.
К тому же голая вакаба больше соответствует минимализму - подобные фичи больше тянут как раз на юзерскрипты, да и реализуются проще.

>> No.188175  

>>188170
С другой стороны не все тут оценят слив данных гуглу. Так что опциональные юзерскрипты все-таки лучше.

>> No.188176  

>>188162
Потому что зачем? Движки для досок и так есть; почти на любой вкус.

>> No.188181  
File: 1616086033810.png -(50267 B, 278x284) Thumbnail displayed, click image for full size.
50267

>>188176
Чтобы выглядеть не как детский сад с мультиками и глаза не ломать.

>> No.188186  

>>188181

> как детский сад с мультиками и глаза не ломать

Eh? Досочки хорошо выглядят же.

>> No.188194  

>>188181
Имиджборда это не тот ресурс, который должен быть обвешан современным фронтендом и красивыми перделочками. Потому что есть старые браузеры, старые компьютеры. Потому что код должен быть максимально простым и удобным в понимании для того, чтобы проще было поддерживать. Потому что не надо нагромождать страницы чепухой, мешающей анализу написанного, вроде красивеньких кнопочек и эффектиков. Только сухой остаток, только нужные функции. Единственное, чего тут имхо не хватает, это ноко. Здесь даже саге не нужно, потому что сегать нечего, одна годнота и благодать.

>> No.188200  
File: 1616133091255.gif -(2035 B, 76x21) Thumbnail displayed, click image for full size.
2035

>>188175
Поэтому решение на юзерскриптах и сосёт. А вот если бы картинка-превью с ютьюба копировалась на сервер новеря, проблем бы не было.

>> No.188203  

>>188200
Хм, интересное. Через условный yt-dl брать превью и тайтл. Всё равно для удобства обычно только эти вещи и нужны, ведь сами видео смотрятся в других окнах.

>> No.188204  

>>188203

>в других окнах

*в других программах

>> No.188206  

>>188200
Но при просмотре данные все равно утекут, нужно копировать весь ролик целиком. Осталось только понять чем это отличается от постга сразу скачанного ролика.

>> No.188207  

>>188206
Смотреть необязательно.

>чем это отличается от постга сразу скачанного ролика.

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

>> No.188216  

>>188194

>Имиджборда это не тот ресурс, который должен быть обвешан современным фронтендом и красивыми перделочками.

Ты потерял нить диалога полностью. Чем читаешь не понятно. Речь была о наползающих хидерах во все поля.

>> No.188222  

>>188162
Движок на С не пишут, умник.

>> No.188223  

>>188222
Почему азиат на перле написать борду может, а белый человек на С - нет?

>> No.188225  

>>188223
Та я не об этом.

>> No.188227  
File: 1616166083415.gif -(1108 B, 34x20) Thumbnail displayed, click image for full size.
1108

>>188225
Так в чём проблема тогда? Почему на C нельзя написать такое же убожество, как вакаба?

>> No.188228  

>>188227
Не положено.

>> No.188229  
File: 1616167109606.jpg -(257316 B, 850x1204) Thumbnail displayed, click image for full size.
257316

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

>> No.188231  

>>188229

> причём результат будет заведомо безопаснее и компактнее

АХАХАХАХАХАХАХА

>> No.188233  

>>188231
Чё ржёшь, даун? У тебя 90% кода на сишечке будет бойлерплейт, который в Пайтоне идёт искаропке. Про безопасность даже комментировать не хочется, там, где питон просто бросит эксепшн, сишечка проедет по памяти мимо буфера до самого ядра

>> No.188234  

>>188223

>сишечка проедет по памяти мимо буфера до самого ядра

(сквозь от смеха слёзы) или просто сгенерит html-страничку и скормит серверу

>> No.188235  

>>188234
В которую попадут пароли от админки, лол.

>> No.188236  

>>188235
Не попадут. Сначала подумай, потом пиши.

>> No.188237  

>>188236
АХАХАХАХАХАХАХА

>> No.188238  

>>188236

>Не попадут

Потому что на си вакабу никогда не допишут?

>> No.188240  

>>188237
sha256, дурашка. Пукни что-нибудь посмешнее.

>> No.188241  

>>188240
С хорошей видеокартой хеши можно накрякать, если кушать без соли.

>> No.188242  

>>188238
Она готова уже. Осталось капчу причесать, чтобы такого говна, как в вакабе не было.

>> No.188243  

Самое замечательное в сишечки то, что даже если ты напишешь каким-то чудом нормальный код, компелятор всё равно поможет тебе сделать его уязвимым повыкидывав твои memset 0 на области с паролями, например.

>> No.188244  

>>188241
Крякай, кукарекай... Это твоё право.

>> No.188245  

>>188243
ну это уже совсем глупости говоришь.

>> No.188246  

Преимущество Си в относительном удобстве написания программ без динамического выделения памяти.
Когда это необходимо возможна прямая работа с указателями.
block_copy(block_in, &(message->data[n * BLOCK_LEN]));
Большую часть фич языка на мой взгляд нет смысла использовать: динамическое выделение/освобождение памяти, знаковые числа и числа с плавающей запятой, стандартная библиотека (строки не юникод + те самые сишные дыры).
Если нужно чтобы просто работало лучше взять джаву или питон. Когда нужна предсказуемость и гибкость оптимизации, и при этом модуль не слишком большой (библиотека, утилита, драйвер), то можно использовать Си.

>> No.188249  

>>188245
https://rules.sonarsource.com/c/type/Vulnerability/RSPEC-5798

>> No.188250  

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

Баке который думает что C автоматически равен дырам в безопасности: есть инструменты для статического и рантаймового анализа, valgrind упомянутый в треде - один из них. Есть так же сканнеры самого кода, десятки их. В плане лаконичности - на самом деле сильно зависит от используемых библиотек и апишек. На C можно тоже писать без особого бойлерплейта, не сильно больше чем на go например.

>> No.188253  

>>188249
Ты прав, не подумал о выходе из скоупа.

>> No.188254  

>>188250
Несмотря на все ваши валграйнды и гковы в опенсурсе всё ещё регулярно находят банальные уязвимости.

>C автоматически равен дырам в безопасности

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

>На C можно тоже писать без особого бойлерплейта,

Лаконичным и читабельным код от этого точно не станет.

>> No.188259  

>>188250

>не хочу нормальный язык, хочу си и миллион левых инструментов

ок

>> No.188260  

>>188240

Я призвываю в тред Уцуху, потому что во первых вы тут всё засрали, во вторых SHA256 уже никто не использует для хэширования паролей , для хэширования паролей есть bcrypt(3) и bcrypt_pbkdf(3) они так или иначе будут поставляться вместе с SSL библиотекой в операционной системе, например с LibreSSL, про которую тут писали.

>> No.188262  
File: 1616177896839.jpg -(109783 B, 724x1024) Thumbnail displayed, click image for full size.
109783

>>188260
Как бы не был хорош алгоритм хеширования пароля, от перехвата в момент ввода через RCE он не спасет. В то же время в C способов допустить RCE по неосторожности более чем достаточно. Впрочем технологий по минимизации ущерба от успешного RCE сейчас тоже появилось немало.

Что же касается целесообразности написания борды на C то это примерно как ездить за продуктами на белазе на мой взгляд.

>> No.188263  

>>188227
Потому что большинство программистов хотят денег за "сложный" код на си.

>> No.188280  

>>188259

Ну для тебя это «левые инструменты», а у некоторых ctags часть базовой системы, у многих bison часть пакета posix-c-development

>> No.188283  

>>188246

> Большую часть фич языка на мой взгляд нет смысла использовать: динамическое выделение/освобождение памяти

Как работать с вводом, длина которого не известна заранее?

>> No.188285  

>>188283
Обычно длина ввода не выходит за пределы фиксированного размера, пусть даже большого. Иногда можно обрабатывать ввод частями. Но это не универсальный принцип, а только мое видение места Си среди других языков.
На полную катушку его в 2021 использовать не имеет смысла. Однако есть множество задач, где требуется предсказумость и возможность ручной оптимизации.
Предсказуемость это адекватная компиляция в машинный код. Когда исполняемая программа делает именно то, что от неё ожидается. С java возникают проблемы, так как невозможно контролировать код виртуальной машины. Сборка мусора, jit-компиляция и тонны кода, которые еще и разнятся версия от версии.
Если этого не требуется, тогда зачем заморачиваться? С Java + Maven работать в разы проще. Многие библиотеки ставятся одной строчкой в конфиге.

>> No.188319  

>>188259
Почти любая *nix-система - IDE сама по себе. Это же причина по которой попытки сделать IDE для C без использования стандартных инструментов обычно выходят так себе. И как правило тот же vim с тайловым wm со всеми инструментами в соседних терминалах оказывается удобней.

>>188285
В наши дни уже go скорее новая java, но в целом с условным разделением на прикладкой код бизнес-логики под меняющиеся требования, где важна скорость разработки и на код под критичные участки, где ресурсы (включая латенси и фактическое время исполнения, помимо очевидных циклов и памяти) так или иначе ограничены спорить глупо.

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

>> No.188324  
File: 1616252847291.jpg -(256727 B, 1200x900) Thumbnail displayed, click image for full size.
256727

Да, есть области где писать на Си это явно усложнить задачу. Но при этом стоит упомянуть области где у Си практически нет конкурентов. Это Embedded (встраиваемые системы). Там правят Си, ассемблер, ну и местами Си++. Причем из этой тройки Си для этой задачи подходит лучше всего. Во-первых прямо в Си можно делать ассемблерные вставки где это необходимо. Во-вторых код на Си в отличие от Си++ легко читаем и не нужно догадываться какие перегрузки операторов использует неизвестная тебе библиотека или особо одарённый программист до тебя.

Да, писать борду на Си это немного извращение, но написать веб-морду для прибора - это то с чем Си справится на ура.

Да, иногда есть возможности поставить операционку, те же unix-ы. Тогда есть возможность использовать почти любую технологию: виртуальную машину Java, скрипты Питона. Поднять сервер к примеру. Но низкоуровневую часть все равно удобнее будет написать на Си.

>> No.188327  

>>188285
Зачем ты перечисляешь другие языки, если авторам их компиляторов/интерпретаторов приходилось решать те же низкоуровневые проблемы.
Речь идёт о Це, а не о чём-нибудь другом.

> Иногда можно обрабатывать ввод частями.

При чтении файлов — да.
А если, например, программа читает файл argv[1], сохраняет результат в файл "argv[2]".ext, добавляя новое расширение — как заранее предугадать размер (strlen(argv[2]) + 5? Только не предлагай выискивать в мануалах максимальную длину имени файла и выделять столько же на стеке.
Мне интересно, я без каверзы спрашиваю.

>> No.188328  

>>188327
Большинство программ ограничивают размер имени файла, даже если в файловой системе такого ограничения нет. Другой вопрос, что чтение/запись выходит за рамки моей концепции. Появляются непредсказуемые побочные эффекты. А значит, тесты могут показывать разные результаты в зависимости от фазы луны.
Идея в том, чтобы отделить максимум логики в либу без побочных эффектов. В результате получается .so бинарник и .h со структурой и функциями. Если правильно протестировать, то можно быть уверенным, что в этом модуле нет ошибок/уязвимостей. При этом в отличие от функциональщины все работает настолько быстро, насколько возможно.

>> No.188329  

>>188328

>можно быть уверенным, что в этом модуле нет ошибок/уязвимостей.

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

>> No.188330  

>>188327
>>188328
Приготовьтесь заебаться-с

https://man7.org/linux/man-pages/man3/realpath.3.html

>The POSIX.1-2001 standard version of this function is broken by design, since it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX.1-2001 a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(3). And asking pathconf(3) does not really help, since, on the one hand POSIX warns that the result of pathconf(3) may be huge and unsuitable for mallocing memory, and on the other hand pathconf(3) may return -1 to signify that PATH_MAXis not bounded.
>> No.188331  

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

Пример:
uint64_t add(const uint64_t a, const uint64_t b)
{

return a + b;

}

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

>> No.188332  

>>188331
Ещё нужно понимать, что тесты верифицируют не исходный код, а частный случай скомпилированной на этой машине программы. Я сейчас не об экзотике вроде
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1633882
а о банальном UB, который каким-то чудом совпадает с правильным результатом на твоей машине и твоей версии конпелятора

>> No.188335  

>>188324
На Си сложно обращаться к базе с постами и генерировать статический html? Или при POST-запросе от http-сервера добавлять запись в базу, а после этого пересоздавать тред?

>>188227
Программисты на Си не умеют писать веб-приложения и обычно их работа с этим не связана.
Программисты на других языках дешевле.
Здесь программисты на Си пишут свои оправдания. Почему они не смогут написать борду на Си.
У меня времени нет.

>> No.188336  
File: 1616277324132.jpg -(59305 B, 1024x1024) Thumbnail displayed, click image for full size.
59305

>>188335

>На Си сложно обращаться к базе с постами и генерировать статический html? Или при POST-запросе от http-сервера добавлять запись в базу, а после этого пересоздавать тред?

Давно пробовал, чтобы понять на сколько это сложно.

Первое это пример bare metal для embedded (голая железка без операционки). Никакой файловой системы и баз данных, всё что есть пишешь в Си коде. Использовал библиотеку lightweight IP https://en.wikipedia.org/wiki/LwIP#:~:text=lwIP%20(lightweight%20IP)%20is%20a,many%20manufacturers%20of%20embedded%20systems. Борду на этом врядли напишешь, но пару дасятков интерактивных HTML страничек для управления устройством вполне можно.

Второе под операционкой (урезанный Linux) использовал Си CGI скрипты (но это для тех кто не знает путей проще) http://jkorpela.fi/forms/cgic.html
Выдержка из ссылки:

>This document was written to illustrate the idea of CGI scripting to C pro­gram­mers. In practice, CGI programs are usually written in other lan­guages, such as Perl, and for good reasons: except for very simple cases, CGI programming in C is clumsy and error-prone.

Если хочешь использовать чистый Си для борды то тебе придется по сути написать свой Web server, думаю объем работ понятен.

>> No.188337  

>>188336

>Если хочешь использовать чистый Си для борды то тебе придется по сути написать свой Web server, думаю объем работ понятен.

Не обязательно. Можно использовать уже готовый httpd или NGINX, об этом есть ссылка выше по треду. Там же ссылка на библиотеку для работы с common gateway interface.

>>188335
Борда на Си не то чтобы очень нужна. А если у тебя так мало времени, то тебе и борда на пёрле не особо нужна, да и вообще хоть какая-то аиб.

>> No.188339  

>>188337

> Там же ссылка на библиотеку для работы с common gateway interface.

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

>> No.188352  

>>188227
>>188335
Да можно. Но, опять же, зачем? Борд и так полно.

>> No.188356  

>>188337

>Можно использовать уже готовый httpd или NGINX

Ага.
>>188337
>>188352

>Борда на Си не то чтобы очень нужна.

Нужна. Отсутствие зависимости от динамических языков.
Я не нашел имиджборд в репозитории debian. Нужен apt-get install imageboard с зависимостью от httpd

>Но, опять же, зачем? Борд и так полно.

Полно, они кривые. Это улучшит конкуренцию.

>> No.188357  

>>188356
С не единственный не-динамический язык. Есть и более подходящие для вебовой разработки альтернативы. Те же go и rust имеют достаточно широкий набор билиотек как раз для этих целей. В том числе есть компиляция в wasm через llvm -- можно целиком всё взаимодействие из браузера на языке бека описать. Готовые либы и фреймворки заточенные под как раз такое взаимодействие тоже уже есть и постепенно матереют.

>> No.188386  

>>188356

>Полно, они кривые. Это улучшит конкуренцию.

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

>>188356
Может просто тебе сделать ебилд для вакабы или порт во фряхе? Это гораздо проще потому что сможешь через saved config или flavors соответсвенно выбирать какой-то альтернативный вебсервер, чтобы сервить cgi тебе не обязательно нужен httpd. А во вторых часть админов привыкла самостоятельно куда-то рядом с /var/www эти веб приложения кидать. Ещё могу предложить найти или сделать самому докер имейдж или в случае с OpenBSD запилисть архив site.tgz, который можно разворачивать сразу в момент установки этой ОС.
Но всё это не к вопросам использования Си, это к вопросам использования пакетных менеджеров. Хотя если кто-то захочет сделать ультимативную утилиту, которая позволит майнтейнерам разных ОС опакечивать один архив таким образом, чтобы можно было его добавить в репозитории разных ос, то было бы интересно.
Я не про flatpak, идея в другом.
Идея в том чтобы я прописывал ссылку на архив tar.gz, а мне в ответ утилита писала список других архивов от которых архив с исходниками зависел, в том числе с опциональными зависимостями, неплохо бы было добавить поиск по уязвимостям, как в pkg_audit во фряхе, можно ещё сделать какие-то отзывы от других авторизованных майнтейнеров, которые бы писали, какие трудности есть с тем или иным пакетом, ну и конечно, чтобы можно было посмотреть какие патчи есть в каких в дистрибутивах. Главное не выполнять уже сделанную работу, не делать пакетный менеджер, который ещё будет собирать этот пакет, это уже можно отдать на откуп майнтейнерам дистрибутивов. Мда что-то я разговорился.

>> No.188397  

>>188386
Чтобы анону было куда уйти, когда очередной модератор скатится в мочу

>> No.188400  
>В linux-next добавлена возможность писать драйверы на Rust

https://www.linux.org.ru/news/kernel/16217268

Дни C сочтены

>> No.188401  

Fortran до сих пор жив, а вы.

>> No.188402  

>>188401
Разве это жизнь? Ты бы ещё Делфи вспомнил

>> No.188403  

>>188402
А что не так с Delphi?
Тот же C++, только без встроенной обфускации исходного кода.

>> No.188404  

На паскаледельфях написаны лучшие оконные файловые мэнэджэры.
https://www.ghisler.com/
https://doublecmd.sourceforge.io/
Компилировать это дело, правда, боль.

>> No.188411  
> Дни C сочтены

0xFFFF
0xFFFE
0xFFFD

>> No.188440  
File: 1616452792356.jpg -(38527 B, 626x351) Thumbnail displayed, click image for full size.
38527

>>188400

>LOR
>Дни C сочтены
>> No.188458  

>>188400

>LOR

Просили же не приносить на него ссылки, про раст в ядре давно и без тебя знаем

>> No.188460  

Нихерово у вас от безобидных шуток пригорает.

>> No.188462  

https://linuxplumbersconf.org/event/7/contributions/804/attachments/641/1168/barriers-to-in-tree-rust.pdf

>> No.188470  
File: 1616596668698.gif -(96889 B, 800x720) Thumbnail displayed, click image for full size.
96889

>>188462
Бла-бла-бла... Маркетинг буллшит.
Все ошибки, которые у меня возникали с Адой, были или от непонимания алгоритма, который кодировала, или тупо проебом части условия или путанием символов. На задачах, приближенных к реальности, где надо использовать сторонние библиотеки на C, однако, там везде use Uncheked_Reference и Unchecked_Access пополам с Unsigned_Integer, которое is mod 2**32, т.е. является массивом битов, и Unchecked_Conversion. Хуле толку-то.

>> No.188472  

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

>Маркетинг буллшит.

Чего бля?

>> No.188492  

Хороший тред. Как использовать httpd или NGINX на чистом C?

>> No.188493  

>>188492
cgi/fcgi/http

>> No.189137  

Новерь у меня OpenBSD 6.8 с компилятором Clang 10.0.1. Есть программа на Си, которая успешно на сабже собирается, но мне хотелось бы перед тем как окончательно оформлять порты добавить патчи подключающие pledge(2). Мне нужно в аргументах plegde(2) написать группы сисколлов, которые программа будет использовать. Вопрос такой: Как не компилируя программу узнать к каким сисколам она обращается ?
Вопрос точно так же актуален и для фряхи с линуксом, потому там тоже есть механизмы ограничивающие доступ к системным вызовам.
Если есть какой-то способ узнать по объектному файлу например использую что-то типа readelf -s, то тоже напишите пожалуйста.

>> No.189138  
File: 1617979907839.jpg -(765874 B, 830x1000) Thumbnail displayed, click image for full size.
765874

>>189137

> Как не компилируя программу узнать к каким сисколам она обращается ?

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

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

>> No.189141  

>>189137
Перекомпилируй ядро, внедрив на обработку сисколлов логгирование. Затем читай логи. )))))000)))0)

>> No.189142  

>>189141

Идея чем-то напоминает ktrace
https://man.openbsd.org/man1/ktrace.1

>> No.190569  

https://youtu.be/QpAhX-gsHMs

>> No.190912  

На всякий случай распишу темы упомянутые в видео >>190569

  1. Несовместимость С++ с Си и что можно в Си, но нельзя в С++
  2. Как сложные структуры данных могут быть легко объявлены с примером из библиотеки sokol gfx
  3. Измения внесённые стандартом C11
    3.1 static assert
    3.2 _Generic и перегрузки
    3.3 atomics и thread local
    3.4 новые макросы
  4. Обработка ошибок в языках программирования Zig, Rust, C++ и в современном Си
  5. Проблемы стандартной библиотеки Си и конкретно ноль-терминированных строк
  6. Советы по написанию собственных библиотек
>> No.190914  

Я нашёл простенькие задачки по cвязанным спискам на Си на codewars:
Convert linked-list to string
https://www.codewars.com/kata/582c297e56373f0426000098
Parse a linked-list from string
https://www.codewars.com/kata/582c297e56373f0426000098

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

>> No.190995  

Какие ваши любимые либы для работы со строками на си? Где надо искать бестпрактис либы?

>> No.190998  

>>190995
Чем тебя стандартный string.h не устраивает? Что ты вообще от строк хочешь получить?

>> No.191014  

>>190995
А с каким строками ты хочешь работать ?
С нультерминированными ?
С UTF-8 only ?
C хранимыми в структуре вместе с длиной ?
Память под строки аллоцирует алокатор из библиотеки или ты сам ?

Если честно был бы я опытнее, вопросов бы было бы только больше.

>> No.191033  

>>190998
>>191014
Спросил либы для строк - нет они сто вопросов задают, я всё наперёд знать должен что ли? Слышал много пердежа что в си неудобно со строками работать и что с юникодом всё не очень на си на самом деле, спросил какие варианты есть любимые у программистов - а они ни одного варианта не назвали только сто вопросов.

>> No.191034  

>>191033
Лол.

>> No.191040  

>>191033
Во первых назвали >>190998
Во вторых эти вопросы нужны были, чтобы ты подумал над ними, дал ответы и тогда тебе можно было что-то советовать.
В третьих, ну можешь glib strings использовать
https://developer.gnome.org/glib/stable/glib-Strings.html

>с юникодом всё не очень на си на самом деле

Юникод бывает разный, кодировка UTF-16 юникод и UTF-8 тоже юникод.

UTF-8 устроена более элегантно и распространена шире. Совместима с ascii.
Вот тут хорошее объяснение https://youtu.be/MijmeoH9LT4
Вот тут про то как Кен Томпсон, автор этой кодировке впервые реализовал её в операционной системе Plan 9: http://doc.cat-v.org/plan_9/4th_edition/papers/utf

Про UTF-16 много хорошего сказать нельзя, она какое-то время использовалась в винде задолго до того, как юникод был на линуксе. С этой кодировкой можно работать средствами стандарной библиотеки, заголовок <wchar.h>

>> No.191062  

>>190995

> best practice

Глупый миф. Разным случаям разные решения с разными достоинствами и недостатками.

>> No.191063  

>>191033
https://www.youtube.com/watch?v=IF_yeXNXHBY

>> No.191069  

>>183736
Не совсем по теме треда. Учу питон, но в будущем хочу выучить какой нибудь язык помощнее, смотрел всегда в сторону си, но на нем в сравнение с си++ мало что делают, да и в си++ вроде много всего добавили и улучшили в сравнение с си, в общем выбрать не могу что учить в будущем. Думаю оба попробовать выучить, но боюсь потом буду путаться, так как вроде в них синтаксис похожий, но как я слышал в них нужно разные подходы использовать в некоторых моментах, чтобы всё работало лучше. Ну и возникает вопрос с какого тогда начинать.

>> No.191070  

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

>> No.191071  

>>191070
5 минут в утке:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf

>> No.191072  

Такой вопрос возник, я с программированием если что пока знаком на низком уровне, что определяет возможно ли вставлять в один язык код другого языка? Вот выше писали, что в си можно вставлять ассемблер, как это получается? И можно ли допустим писать код на том же питоне, потом вставить кусок си, если нужно, потом ассемблер, ну и к примеру java? Какие вообще проблемы и ограничения будут?
Я же могу допустим писать код на питоне, а в моментах где нужна ну очень сильная производительность перейти на ассемблер?

>> No.191074  

Просто бери ГО уже.

>> No.191075  

>>191070
https://en.cppreference.com/w/c как привычная документация.

>> No.191076  

>>191072

>java и python

Господи спаси.

>C/asm

Короткий ответ: не можешь.
Другой ответ: можешь, но не так, как ты себе это представляешь. Можно использовать CPython или подобные ему вафли. Для других языков тоже свои биндинги есть.
С это так работает хотя бы потому, что Сишный код на одном из этапов компиляции сам представляет из себя ассемблер, чего бы и со стороны(прямо из источника) не воткнуть?
К тому же интересно, как в сишный код будешь вставлять (к примеру) java-код.

>> No.191080  

>>191069

Тот что тебе больше нравится, тебе для многих задач и пайтона хватит. Если хочешь чтобы что-то быстро работало, то тебе нужен не "быстрый" язык, а эффективный алгоритм. Эффективность алгоритмов иллюстрируют с помощью О-нотации. Возьми какую-нибудь книгу по алгоритмам если тебе интересна эта тема.
Но всё-таки в конце концов я должен добавить, что в пайтоне принято модули писать на Си, а не на C++, см PEP-7.

>>191070

>А кто вообще разрабатывает С сейчас и документацию к нему?

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

man 3 intro вместо intro можешь подставить любую тебя интересующую функцию стандартной библиотеки.

https://manpages.debian.org/buster/manpages/intro.3.en.html

>Хотел документацию глянуть по нему, нагуглил какой-то сайт со стандартами, но там нет привычной документации, а есть какая-то платная.

Обычно можно найти стандарт на сайте рабочей групы комитета стандартизации, а так вообще стандарты ISO к сожалению платные. Иногда почитывать стандарт бывает полезно, но так-то этот документ предназначен в первую очередь разработчиками компиляторов.

>>191072

>Такой вопрос возник, я с программированием если что пока знаком на низком уровне, что определяет возможно ли вставлять в один язык код другого языка?

Определяет то компилируется язык в бинарный код или нет. Прямо так вставить код одного языка в другой нельзя, но вот можно имея единый application binary interface использовать код в качестве библиотечной функции.

>Вот выше писали, что в си можно вставлять ассемблер, как это получается?

Компилятор обрабатывая исходный код языка Си проходит несколько этапов одним из таких этапов является генерация ассемблерного кода и потом уже из него сборка исполняемого файла.
Если быть внимательным, то ты заметишь, что вместе с компилятором gcc поставляется такой исполняемый файл как as, а вместе с clang поставляется llvm-as. Вот эти as и llvm-as это ассемблеры, нужные для функционирования компилятора.
Вообще тебе вряд ли это пригодиться, а ещё написанный в отдельном файле, а потом включённый как функция в основную часть, код на ассемблере выглядит лучше чем ассемблерная вставка посреди сишного исходника, впрочем в ядре Линукс можно наблюдать и такое.

> И можно ли допустим писать код на том же питоне, потом вставить кусок си, если нужно, потом ассемблер, ну и к примеру java?

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

>Я же могу допустим писать код на питоне, а в моментах где нужна ну очень сильная производительность перейти на ассемблер?

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

Если хочешь сделать что-то быстро стоит подумать над написанием более эффективного алгоритма.
Вот допустим у тебя был код работающий за O(n²), а ты его переписал так что он работает за O(n) здесь n это объём данных, погугли "big o notation" или "омега нотация". После того как ты добился максимальной эффективности алгоритма можно посмотреть на то какие в коде есть узкие места и решить cpu-bound или io-bound задачи решаются в этим местах. Соответсвенно можешь применить треды если это cpu-bound задача или асинхронный ввод-вывод если это io-bound задача.

>> No.191088  

>>191076

> Господи спаси.

А что такого в питоне?

>> No.191089  

>>191076

> Можно использовать CPython или подобные ему вафли. Для других языков тоже свои биндинги есть.

Получается можно объединить только два каких-то языка, если у одного их них есть приспособа для такого объединения?

А если не прям в коде вставки, а раздельные какие-то модули на разных языках? На том же гитхабе показывает какой язык сколько процентов составляет в приложение, допустим 70 си++, 20 пайтон, 10 джаваскрипт. Как они это делают?

>> No.191090  

>>191080

> Но всё-таки в конце концов я должен добавить, что в пайтоне принято модули писать на Си, а не на C++, см PEP-7.

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

А я все таки смотрел в сторону всяких прикладных программ, и тут вроде в основном С++ правит?

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

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

> Реализацию компилятора Си и стандартной библиотеки, уже отдельный команды программистов разрабатывающих компиляторы.

Получается в разных компиляторах может быть немного отличающийся Си?

>> No.191091  

>>191080

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

А как эта вставка обозначается? Или она вообще просто вот прям буквально посреди Си кода пишется без каких-то особых обозначений и выделений?

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

Видимо у меня было туманное и не очень правильное представление о том как всё это работает под капотом. Теперь стало более понятно. Спасибо

>> No.191092  

>>191090

>Получается в разных компиляторах может быть немного отличающийся Си?

Так и есть. Не говоря уже про язык на разных ОС.
>>191088
В питоне? Ничего. Но объединять и java и python вместе это как кушать джем со сгущёнкой - попа слипнется.

>> No.191093  

>>191090

>А я все таки смотрел в сторону всяких прикладных программ, и тут вроде в основном С++ правит?

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

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

Будет, но это зависит от того, что ты считаешь ощутимой разницей.
Вот допустим у меня есть скриптик на awk, который конвертирует записи характерные для файла /etc/hosts в зону для unbound это занимает вот столько

0m00.67s real     0m00.39s user     0m00.20s system

у меня есть программа на си делающая это за вот столько

0m00.65s real     0m00.19s user     0m00.19s system

Тут ещё конечно большая проблема в том, что я новичок в Си и пишу не очень элеганто, так что у меня не самая быстра программа получилась. Но как ты видишь, это не тот прирост в скорости, ради которого обычно платят деньги, как я понимаю. Поправьте если я не прав. С другой стороны эта программа была написана для себя, почти что "в стол" так сказать.

>Получается в разных компиляторах может быть немного отличающийся Си?

Ну грубо говоря, да. Только то что оговорено в стандарте языка будет везде одинаково, а у компиляторов бывают свои extensions так сказать. Вот допустим у clang на mac os x есть опция -fblocks, которая позволяет в коде на Си иметь что-то типа лямбд из функциональных языков.
Вот ещё один секрет о котором все знают: разные компиляторы могу немного по разному генерировать собственно
объектные файлы.

>>191089

>Получается можно объединить только два каких-то языка, если у одного их них есть приспособа для такого объединения?

Ну да, примерно так.

>Как они это делают?

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

>>191088
Тут скорее смысл был том, что идея связать джаву и пайтон выглядит не очень здравой. У них разные виртуальные машины в качестве среды выполнения. Получается тебе надо либо сделать так чтобы пайтон компилировался в байткод jvm или java компилировалась в байткод пайтона. Это скорее всего вызовет просто ряд проблем и будет оче неудобно, если вообще возможно.

>> No.191102  

>>191092

>
> >Получается в разных компиляторах может быть немного отличающийся Си?
> Так и есть. Не говоря уже про язык на разных ОС.

Вау, я думал подобное только в ассемблере есть, а все более высокоуровневые языки везде одинаковы. А есть какой нибудь компилятор, который использует большинство разработчиков и его можно назвать стандартом в этой области?
>>191093

> Ну мне не очень понятно что ты имеешь ввиду под прикладными программами

Ну, вот есть "обычный" софт, а есть всякие системные штуки, которые глубоко лежат, и там вроде как без Си вообще не обойтись

> Одно но, тебе просто придётся использовать уже написанный тулкит

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

> Тут ещё конечно большая проблема в том, что я новичок в Си и пишу не очень элеганто, так что у меня не самая быстра программа получилась. Но как ты видишь, это не тот прирост в скорости, ради которого обычно платят деньги, как я понимаю. Поправьте если я не прав. С другой стороны эта программа была написана для себя, почти что "в стол" так сказать.

А если нужно написать какой нибудь движок для симуляции физики где важна будет производительность, или программу, которая должна выдавать результат за максимально короткое время, где эти 10 мс будут важны?

>> No.191103  
File: 1622544142787.jpg -(1180940 B, 1200x938) Thumbnail displayed, click image for full size.
1180940

>>191102

> Вау, я думал подобное только в ассемблере есть, а все более высокоуровневые языки везде одинаковы. А есть какой нибудь компилятор, который использует большинство разработчиков и его можно назвать стандартом в этой области?

Обычно различия не очень значительны и выражаются в каких-либо специфичных вещах. Что же касается популярных компиляторов то сейчас это gcc и llvm.

> Ну, вот есть "обычный" софт, а есть всякие системные штуки, которые глубоко лежат, и там вроде как без Си вообще не обойтись

Сейчас кстати активно rust метит в эту нишу.

> А если нужно написать какой нибудь движок для симуляции физики где важна будет производительность, или программу, которая должна выдавать результат за максимально короткое время, где эти 10 мс будут важны?

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

>> No.191134  

>>191072
Почти в любом языке программирования есть какой-нибудь способ вызывать Си-шный код. Это как неписанное правило.

>> No.191158  

>>191103

> Сейчас кстати активно rust метит в эту нишу.

И хорошо у него получается?

>> No.191159  
File: 1622741034312.jpg -(339421 B, 1278x1003) Thumbnail displayed, click image for full size.
339421

>>191158
Он в самом начале пути, но перспективы у него хорошие.

>> No.191163  

Говорят в Си нет строк, точнее строки это просто массив байт типа char, ну или указатель на char. Я правильно понимаю, что измерить число символов в строке можно только за линейное время?
У меня есть идея как из этого выходить, если нужно подсчитывать число символов в очень длинной строке или тексте, можно во время ввода делить текст на меньшие строки и пихать в связный список, в котором у каждого узла будет лежать строка с одинаковым числом символов. Тогда останется только посчитать число узлов в списке и число символов в последнем узле. Это хорошее решение проблемы ?

>> No.191164  
File: 1622744298034.jpg -(307250 B, 818x1109) Thumbnail displayed, click image for full size.
307250

>>191163

> Я правильно понимаю, что измерить число символов в строке можно только за линейное время?

Правильно.

> Это хорошее решение проблемы ?

Нет. Для случаев длинных строк достаточно хранить их в struct с уже предпосчитанным числом символов.

>> No.191185  

Скажите, пожалуйста, каким инструментом удобно отрезать от больших хороших библиотек отдельные модули? Вот например если бы я захотел от glib отрезать в свой маленький проект только связанное со строками, как бы мне это сделать?

>> No.191186  

>>191185
Или это вообще не нужно, пара килобайт неиспользуемого кода не вредит?

>> No.191187  

>>191186
Это. Только вот glib - это вовсе не пара килобайт.

>> No.191188  

>>191185
Если есть исходники, то отрезать текстовым редактором, разве не очевидно?

>> No.191190  

>>191185
В JS это называется Tree Shaking. Для си подбного не видел.

>> No.191192  
File: 1622883480279.png -(5810806 B, 2000x2319) Thumbnail displayed, click image for full size.
5810806

>>191185
Обычно вместо отрезания кусков библиотек программы просто собирают с динамической линковкой и тогда они вообще не включают в себя код библиотек, только ссылки на них. Если тебе все-таки нужно линковаться статически то попробуй всякие -Wl,--gc-sections -fdata-sections -ffunction-sections -fwhole-program.

>> No.191194  

>>191188
Конечно нет. Как ты из сишной библиотеки типа glib что-то вырежешь? Там же зависимостей в коде очень много.

>> No.191208  

>>191185

>Вот например если бы я захотел от glib отрезать в свой маленький проект только связанное со строками, как бы мне это сделать?

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

>>191033

>Слышал много пердежа что в си неудобно со строками работать и что с юникодом всё не очень на си на самом деле

Весьма вероятно, что этот "пердёж" был про то, что строки нультерминированные.
И если ты хочешь согласно этому "пердежу" работать, то тебе стоит внимательные слушать и понимать почему автор "пердежа" считает, что со строками неудобно работать.
А про юникод ниже написали, что UTF-8 обратно совместима с ascii. Также ниже, в ссылках, авторы UTF-8 написали, какие проблемы возникают при работе с многобайтными диапазонами UTF-8 и как их решать. >>191040

>> No.191266  

>>191033

>Слышал много пердежа что в си неудобно со строками работать и что с юникодом всё не очень на си на самом деле

UTF-8 has several convenient properties:

  1. It can handle any Unicode code point.
  2. A Unicode string is turned into a sequence of bytes that contains embedded zero bytes only where they represent the null character (U+0000). This means that UTF-8 strings can be processed by C functions such as strcpy() and sent through protocols that can’t handle zero bytes for anything other than end-of-string markers.
  3. A string of ASCII text is also valid UTF-8 text.
  4. UTF-8 is fairly compact; the majority of commonly used characters can be represented with one or two bytes.
  5. If bytes are corrupted or lost, it’s possible to determine the start of the next UTF-8-encoded code point and resynchronize. It’s also unlikely that random 8-bit data will look like valid UTF-8.
  6. UTF-8 is a byte oriented encoding. The encoding specifies that each character is represented by a specific sequence of one or more bytes. This avoids the byte-ordering issues that can occur with integer and word oriented encodings, like UTF-16 and UTF-32, where the sequence of bytes varies depending on the hardware on which the string was encoded.

ВНЕЗАПНО: https://docs.python.org/3/howto/unicode.html

>> No.191270  

>>191033

>Слышал много пердежа что в си неудобно со строками работать и что с юникодом всё не очень на си на самом деле

Книга из этого >>187689 поста, 120 (151) страница.

>> No.191276  

>>191208
Разве программисты не должны стремиться к повторному использованию кода?

>> No.191277  

>>191276
Звучит слишком абстрактно, чтобы всерьёз ответить.
Это как говорить, что ооп такое крутое, потому что мир состоит из объектов. Ну охуеть открытие просто...

>> No.191395  

>>187691

> Если кто-то найдёт шапку с арисучана то можно будет сделать полноценный Си тред.

Ну вот, нашёл.
https://archive.arisuchan.jp/λ/res/882.html#882
Админ выключил его не так бесцеремонно, как оказалось.

>> No.191398  

>>191395
Спасибо

>> No.191507  

Давайте чтоли вместе какие-нибудь упражнения решать?

>> No.191522  

>>191190
Для C это называется strip. Но тот же функционал скорее всего есть и в линковщике.

>> No.191549  

>>191507
Вот книжка с упражнениями >>187838
Вот сайт с упражненями >>190914

>> No.191576  

>>191549
И пусть здесь будет анонимный тред с упражнениями.

>> No.191592  

>>191576
Так никто не против, вот даже какие-то конкретные задачи по связанным спискам были запощены.

>> No.191615  

>>188400

Сомневаюсь. Даже если Rust (или любой другой кандидат на убийство C) - удачная замена, то в любом случае останутся тонны легаси, которые скорее всего не будет переписывать.

>> No.191617  
File: 1624185049605.png -(121926 B, 946x658) Thumbnail displayed, click image for full size.
121926

Тем временем Борда на С

>> No.191618  

>>191617
А что с парсингом http-запросов?

>> No.191620  
File: 1624188220851.jpg -(113059 B, 560x933) Thumbnail displayed, click image for full size.
113059

>>191618
однопоточный асинхрон

>> No.191621  

>>191617
anonimous?

>> No.191686  

Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”

Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”

Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”

The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.

“And how many hours would you require to implement and debug that C program?” asked Nubi.

“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”

“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

Upon hearing this, the programmer was enlightened.

http://catb.org/esr/writings/unix-koans/ten-thousand.html
https://yewtu.be/watch?v=xnCgoEyz31M

>> No.191687  

3.13

Младший бухгалтер Ли Чан спросила:
— Учитель, почему нашего инженера все зовут Чжа Вынь? Ведь по паспорту он Чжа Сунь.

Инь Фу Во ответил:
— Взгляни на него, какой же он Сунь? Когда он теряет данные о клиенте, он отключает порт на коммутаторе и ждёт от клиента звонка. Ну какой же он Сунь?

>> No.191923  

Может анон подскажет. Не могу нагуглить.

https://stackoverflow.com/questions/36179191/finding-from-symbol-table-is-failing-in-php-7

>> No.193506  
File: 1630329581174.jpg -(38606 B, 200x200) Thumbnail displayed, click image for full size.
38606

Новерь, вот моя реализация string.h — она по-прежнему работает с нуль-терминированными строками, зато она моя. Zip.jpg.
Статическая либа с исходниками на ассемблере (AT&T, amd64 ABI).
Получилось вот, что:

$ size -t lib.a
text data bss dec hex filename
25 0 0 25 19 catlim.o (ex lib.a)
6 0 0 6 6 copy.o (ex lib.a)
9 0 0 9 9 fill.o (ex lib.a)
20 0 0 20 14 findc.o (ex lib.a)
67 0 0 67 43 finds.o (ex lib.a)
13 0 0 13 d kitten.o (ex lib.a)
11 0 0 11 b memeq.o (ex lib.a)
15 0 0 15 f scopy.o (ex lib.a)
20 0 0 20 14 scopylim.o (ex lib.a)
19 0 0 19 13 slen.o (ex lib.a)
32 0 0 32 20 strei.o (ex lib.a)
13 0 0 13 d streq.o (ex lib.a)
11 0 0 11 b streqlim.o (ex lib.a)
8 0 0 8 8 zero.o (ex lib.a)
269 0 0 269 10d (TOTALS)

Заставить работать вместе ассемблер и Си очень просто: аргументы передаются в регистрах RDI, RSI, RDX; возврат помещается в RAX.

>> No.193508  
File: 1630335661562.jpg -(35579 B, 500x500) Thumbnail displayed, click image for full size.
35579

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

>> No.193509  
File: 1630335711327.jpg -(456612 B, 726x1000) Thumbnail displayed, click image for full size.
456612

>>193506
Интересное у тебя хобби.

Ну и лови баг:

    #include "lib.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define SIZE 255
#define PATTERN 0x20
#define STRING " test"

int main(void) {
char* mem;
mem = (char*)malloc(SIZE);
memset(mem, PATTERN, SIZE);
mem[SIZE-1]=0;
strcpy(mem+SIZE-100, STRING);
printf("%lu\n", strstr(mem, STRING)-mem);
printf("%lu\n", finds(mem, STRING)-mem);
return 0;
}
>> No.193526  
File: 1630404092029.gif -(104 B, 30x19) Thumbnail displayed, click image for full size.
104

>>193508
Просто — никаких намёков.
>>193509
Спасибо, я так и знал, что где-то в finds() окажется ошибка из-за cmps и её инкремента.

>> No.193530  
File: 1630407997905.gif -(4021697 B, 500x280) Thumbnail displayed, click image for full size.
4021697

>>193526

>> No.193551  

>>187701

>От регистров сишечка абстрагирует

Это до первого asm

>и общая культура написания кода.

Что такое культура кода? Что-то уровня написания осознаных комментариев и описаний коммитов?

>> No.193564  

Чем бойлерпринт от библиотеки отличается?

>> No.193566  
File: 1630524601941.png -(4181445 B, 4200x3600) Thumbnail displayed, click image for full size.
4181445

>>193564
Экземпляр кода в бойлерпринте нельзя шарить между приложениями.

>> No.193570  
File: 1630533914475.jpg -(70126 B, 1280x720) Thumbnail displayed, click image for full size.
70126

>>193566

Я не понимаю. Зачем тогда использовать метод модифицированной копипасты, если препроцессор библиотеку впихнёт все равно как нативный код?

Почему просто этот шаблон не написать как библиотеку модифицируя когда она того требует?

>> No.193572  

>>193570
Дорогой, ты бы таблеточек принял от шизофазии.

>> No.193788  
File: 1630976366280.jpg -(2388273 B, 2368x3400) Thumbnail displayed, click image for full size.
2388273

Смотрите что нашла, сюда можно загружать длинные тексты

https://2ch.sh/user/pr/

>> No.193792  

>>193788
Только оно не работает.

>> No.193799  

>>193798
Зачем оно тогда тут нужно?

>> No.193815  

>>193799
Чтобы ты сходил на termbin.com тот же и захостил свою ноду?

>> No.193816  

>>193815
Но зачем оно мне?

>> No.193817  

>>193816
Заливать, конфиги, логи и код. Ты станешь лучшим системным администратором или анимешной девочкой.

>> No.193818  

>>193817
Но есть ведь zipjpeg. Зачем придумывать что-то еще?

>> No.193889  

куку погромисты, ну че насколько я хуевый хеллоуворлдщик?
main.c
https://pastebin.com/XtWrryzX
functs.h
https://pastebin.com/r4hxaRYs

>> No.193893  
File: 1631207380450.png -(197896 B, 397x547) Thumbnail displayed, click image for full size.
197896

>>193889
Не пользуясь strchr-ами и прочими memcpy-ями и не думая об методах оптимизации строковых функций из glibc, хочется написать что-то вот такое в strtrim.
https://pastebin.com/ckSQtdZT

>> No.193894  

>>193818
Затем, что лучше запихать 7-Zip (i.e. LZMA) в PNG?

>> No.193899  

>>193893
спасибо что растоптал остатки моей самооценки
буду оправдывать себя тем, что никогда погромированию не учился специально, а чисто как хобби почитывал книжечки и документацию и вообще у меня другая профессия, да

>> No.193900  
File: 1631215737650.png -(2434300 B, 1920x1080) Thumbnail displayed, click image for full size.
2434300

>>193899
Да ладно тебе, я код уровня исходников Gumbo, GCC, simdjson и прочей фигни всё равно не пишу и писать не умею.
К тому же, я ту штуку не тестировал, и она ошибается если у предпоследнего слова найден конец и у последнего слова в конце нет пробелов, в 15-ую строчку надо if(!end || !at_space_substr) пихнуть.

>> No.194089  
File: 1631560766600.webm -(246515 B, 500x281) Thumbnail displayed, click image for full size.
246515

>>193530

>> No.194090  
File: 1631560909901.jpg -(35469 B, 200x200) Thumbnail displayed, click image for full size.
35469

>>193506
Вторая версия.

text   data    bss    dec      hex   filename
29 0 0 29 1d catlim.o (ex lib.a)
35 0 0 35 23 copy.o (ex lib.a)
9 0 0 9 9 fill.o (ex lib.a)
20 0 0 20 14 findc.o (ex lib.a)
64 0 0 64 40 finds.o (ex lib.a)
13 0 0 13 d kitten.o (ex lib.a)
11 0 0 11 b memeq.o (ex lib.a)
14 0 0 14 e scopy.o (ex lib.a)
29 0 0 29 1d scopylim.o (ex lib.a)
18 0 0 18 12 slen.o (ex lib.a)
43 0 0 43 2b srevers.o (ex lib.a)
32 0 0 32 20 strei.o (ex lib.a)
16 0 0 16 10 streq.o (ex lib.a)
11 0 0 11 b streqlim.o (ex lib.a)
59 0 0 59 3b strin.o (ex lib.a)
24 0 0 24 18 slow.o (ex lib.a)
24 0 0 24 18 sup.o (ex lib.a)
8 0 0 8 8 zero.o (ex lib.a)
459 0 0 459 1cb (TOTALS)

>>187957

> reverse

Где может пригодиться переворачивание строк?
И ещё вопрос. Хороший ли тон — инклюдить хидеры в других хидерах?

>> No.194091  

>>194089
Откуда стесняша?

>> No.194092  

>>194091
В метаданных файла же: Saekano (Saenai Heroine no Sodatekata).
https://anidb.net/anime/10538

>> No.194094  

>>194091
Упомянутое аниме не смотрел, но очевидно, что это не стесняша, а цундере или ещё кто агрессивный и энергичный.

>> No.194135  
File: 1631646414890.webm -(5117044 B, 1920x1080) Thumbnail displayed, click image for full size.
5117044

>>194092

В метаданных у >>194089 сказано «Seanai» вмѣсто правильного «Saenai», и это может дезориентировать зрителя, до этого не знакомого с Saekano.

>> No.196340  
File: 1636975841928.png -(3961 B, 272x232) Thumbnail displayed, click image for full size.
3961

Давно мечтал об утилите, которая будет разделять строки на поля по пробелам и выводить произвольное. Вызывать «awk '{ print $2 }'» — оверкилльно (да и вводить долго/неудобно), «cut -f2 -d' '» не работает с количеством пробелов больше одного.

>> No.196344  

>>196340
А нахуя она тебе надо?
Но вообще прикольно, добро пожаловать в поэкт GNU! Github, личный, надеюсь, имеете?

>> No.196347  

>>196344

>в поэкт GNU! Github, личный, надеюсь, имеете?
>GNU
>Гитхаб

Тебе за такое надо уши надрать. Крепко надрать.

>> No.196371  
File: 1637025153833.png -(4879 B, 272x232) Thumbnail displayed, click image for full size.
4879

>>196340
Индеец Зоркий Глаз тоже давно такую утилиту хотел и, вдохновившись картинкой, начал её делать. Спустя 4 часа он заметил на картинке надпись "word.zip.png", но его уже было не остановить.

P. S. Твоя версия захлебнётся под Виндой, без буферизации. Моя, в общем-то тоже, надо setvbuf() везде расставлять, но я ебал уже и эту утилиту, и этот ваш C, в котором 100500 способов выстрелить себе в ногу и ни одного правильного.

>> No.196372  

Отдельный луч поноса посылаю придумавшим ato...() и strto...l().

>> No.196379  

>>196340
tr -s работает с количеством пробелов больше одного (только с ним и работает)

>> No.196380  
File: 1637052677468.png -(611041 B, 922x800) Thumbnail displayed, click image for full size.
611041

>>196371
используй раст.

>> No.196381  

>>196380
Уровень аргументации: мелкобуква.

>> No.196382  

>>196381
все правильно говорит
C и вправду ебанутый язык.

>> No.196384  
File: 1637061394726.gif -(42833 B, 324x430) Thumbnail displayed, click image for full size.
42833

>>196381

>ряяя си гавно ненавижу ууу мразь
>используй раст вместо си
>ряяя трансы гавно ненавижу ууу мразь

как называется эта болезнь?

>> No.196387  

>>196384
нетортянка
вооот когда быыл кобол и фортран, вооооот тогдаа то мы жили как аристокрааты

>> No.196389  
File: 1637062025409.jpg -(121855 B, 825x855) Thumbnail displayed, click image for full size.
121855

>>196387
я на фортране допиливал старую софтину однажды, такая параша, бррр.

>> No.196390  

>>196371

> Индеец Зоркий Глаз тоже давно такую утилиту хотел и, вдохновившись картинкой, начал её делать.
> Спустя 4 часа он заметил на картинке надпись "word.zip.png", но его уже было не остановить.

Поздравляю. Алсо, Быстрый Ум будет вторым прозвищем индейца.
Я не искусствовед в области кода, но в этом файле заметно явное влияние творчества GNU, getopt_long тоже в наличии. Отступы какие-то необычные, по два пробела (не четыре и не табы). Даже в комментариях блотварь и бюрократическое многословие. Лишние пробелы на пустых строках, кстати.

> P. S. Твоя версия захлебнётся под Виндой, без буферизации.

I wanted it to be brutally simple. Да и зачем буферизовать в программе, если это сделают ОСь или терминал.
Как вариант: можно читать строки в увеличивающийся по необходимости буфер и выводить выбранные поля построково — куцая виндовская концолька легче справится, наверное.
>>196372
А что не так? strtol() даже переполнение проверяет.

>> No.196399  

>>196390

> Да и зачем буферизовать в программе, если это сделают ОСь или терминал.

Windows XP не буферизует. Проверял.

>> No.199395  
File: 1645478624298.png -(2608 B, 200x200) Thumbnail displayed, click image for full size.
2608

>>196340

>> No.199423  
File: 1645574699682.jpg -(166642 B, 620x877) Thumbnail displayed, click image for full size.
166642

Программисты Amazon Web Services постепенно отказываются от других языков в пользу Rust и переписывают свои сервисы.

Как скоро Си превратится в Делфи?
Мне нравится в целом на нем писать, но вот отлов уб утомляет в наспагеченном коде, и мне кажется когда я наконец освою алгоритмы и пройду сикп, мне останется лишь поддержка Легаси среди дедов, а Раст займет все ниши, включая вебассемлер

>> No.199425  

>>199423
Ты подожди, они ещё один язык придумают (с монадами, например), и будут с Раста на него всё переписывать.

>> No.199426  
File: 1645591468288.jpg -(269422 B, 1920x1080) Thumbnail displayed, click image for full size.
269422

>>199425
в расте HKT называют HRT(higher-rank trait bounds), так что монады будут. вот сперва гаты стабилизируют и зоживём.

>> No.199428  

>>199426

> в расте HKT называют HRT(higher-rank trait bounds),

Компилятор перестал на них валиться?

>> No.199429  
File: 1645614185026.jpg -(786200 B, 2000x3407) Thumbnail displayed, click image for full size.
786200

как же заебали эти пидарасы

>>199428
валится в 42% случаев, потихоньку улучшают.

>> No.199430  
File: 1645614218067.jpg -(194507 B, 2000x4000) Thumbnail displayed, click image for full size.
194507

>>199429
и вот эти

>> No.199431  
File: 1645614532805.png -(1207727 B, 3000x2500) Thumbnail displayed, click image for full size.
1207727

>>199429
>>199430
ох вейт, это не рандом.

ну тогда суть такая что баги задрали.

>> No.199442  

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

>> No.199445  

>>199426
Значит, кто-нибудь придумает язык с зависимыми типами или с алгебрами эффектов, и все будут переписывать всё на нём.

> гаты стабилизируют

Они уже во всех языках стабилизированы, зачем их опять стабилизировать?

>> No.199449  

>>199442
[HLASM](https://ru.wikipedia.org/wiki/HLASM)?

>> No.200640  
File: 1651439595400.jpg -(139886 B, 1200x875) Thumbnail displayed, click image for full size.
139886

Спрошу тут!
Какие главы SICP реально полезно прорешать
Прямо вот основа, базис.

И с каких начинается академиз и беззадачность для прикладного велосипедостроителя?

>> No.200642  
File: 1651457724613.jpg -(3700074 B, 2894x4093) Thumbnail displayed, click image for full size.
3700074

>>199442
nim?
>>199445

>Они уже во всех языках стабилизированы

щито?
>>200640
не читал но осуждаю!

>> No.200918  
File: 1651875281770.jpg -(23567 B, 441x421) Thumbnail displayed, click image for full size.
23567

>>200640

Решаю тут Сикп.

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

Смотрю HTDP, но без перевода туго.

Но мне писали что это для совсем детей и вкатывальщиков, и он больше во вред будет. Хотя было и другое мнение, что сикп вреднее, так как уводит от реальных задач, в академизм, и htdp будет лучше, т.к ориентирован на реальный продакшен и задачи.

Вот перевод энтузиаста https://github.com/IisNuINu/htdp-rus
Уже нашел ошибки, включая код. И перевод будто допиленный машинный.

Что думаешь, анон?

Кстати, я был уверен что на новерь был сикп тред. Хотя может это была хайбане.

>> No.200919  

>>200918
Зависит от того, чего ты добиться хочешь. Я лично решал только то, что казалось концептуально сложным.

>> No.200920  

>>200642

> щито?

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

>> No.200921  
File: 1651879511343.jpg -(153983 B, 1080x1080) Thumbnail displayed, click image for full size.
153983

>>200919

Я не уверен.
Скорее повышения общего понимания как строится архитектура программ, абстракций и синтактического сахара в других языках и практика правильного построения и проектирование этих самых программ

>> No.200924  

>>200921
А, так это тебе надо:

  • С. Макконнелл. Совершенный код
  • Ben Moesley, Peter Marks. Out of the Tar Pit
  • Э. Хант, Д. Томас. Программист-прагматик
  • Г. Буч. Объектно-ориентированный анализ и проектирование
  • Б. Мейер. Объектно-ориентированное конструирование программных систем
  • Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Паттерны объектно-ориентированного проектирования
  • https://agilemanifesto.org/iso/ru/manifesto.html
  • К. Бек. Экстремальное программирование (несколько книг)

и прочую муть.

>> No.200926  
File: 1651898091058.png -(2509160 B, 1114x1368) Thumbnail displayed, click image for full size.
2509160

>>200918
сикп это мем. все книги по программированию - мем. в лучшем случае это сикп, повторяющий очевидное, в худшем какие-нибудь говнопаттенры придумывают для дебилов, которые затем ими засирают код.

поясню за сикп, а то вы скажете опять мелкоченский со своим "нинужно".

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

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

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

>>200920
пересчислил языки-мемы. хачкель то хоть потенциально может быстро работать.
>>200921
всё это хуета и по большей части существует чтоб программеры могли сигналировать компетентность. как хвост у павлина.

>> No.200927  
File: 1651898348282.jpg -(869439 B, 912x1368) Thumbnail displayed, click image for full size.
869439

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

>> No.200946  

>>200927
они к нему приделали наивн борроу-чекер. система типов там криво и бездумно спизжена из ака хачкеля.

>> No.200947  
File: 1651924121151.jpg -(1557197 B, 2516x3354) Thumbnail displayed, click image for full size.
1557197

>>200946
в хачкеле идеал системы типов. я бы писал только на хачкеле, если бы он не так говёно работал.

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

>> No.200951  

>>200947
члень, ты вот это сейчас по серьезке написал?

>> No.200952  

Чень все правильно делает, нехуй сидеть на легаси говне. Раз оно все говно, то надо использовать перспективное говно.

>> No.200955  
File: 1651930752705.jpg -(96478 B, 720x900) Thumbnail displayed, click image for full size.
96478

>>200951
если у тебя есть что-то лучше - предлагай. из толпы покрикивать и собака может.

>> No.200956  

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

>> No.200957  
File: 1651936550442.jpg -(62232 B, 604x399) Thumbnail displayed, click image for full size.
62232

>>200924

>ооп
>ооп
>ооп

Тут целые баталии разворачивались что ООП ересь от Сотоны и нинужно, фу бяка, не трогай это, а ты ему многотомники насоветовал.

>> No.200958  

>>187427

>> No.200960  
File: 1651939403497.gif -(1312 B, 49x18) Thumbnail displayed, click image for full size.
1312

>>200957
Это троленк, люди не могут быть настолько неадекватами.

>> No.200963  
File: 1651940629542.jpg -(1627052 B, 1125x1500) Thumbnail displayed, click image for full size.
1627052

>>200960
ооп это чисто хвост тропического петуха для сигналирования компетентности и превращения кода в кал.

>> No.200964  
File: 1651941500855.jpg -(495206 B, 1400x1400) Thumbnail displayed, click image for full size.
495206

>>200924

Я тебя найду и буду кормить мороженным пока у тебя не разовьётся диабет и тебе к хренам не отсобачат ручки что бы ты такое больше не писал, ня

>> No.200965  

И конечно же все сразу стриггерились на "объектно-ориентированное" (хотя "Паттерны..." и правда можно уже выбросить на свалку истории). А ведь даже в книгах по ООП первые несколько глав посвящены принципам программной инженерии, ISO 25010 (или рассуждениям, предшествовашим ему) и обоснованию ОО подхода. Да и про само ООП можно почитать, чтобы понять, что ты пишешь не на ОО языке, а на хуете с грибами.

>> No.200966  
File: 1651948535596.jpg -(284723 B, 1273x900) Thumbnail displayed, click image for full size.
284723

>>200965

>Да и про само ООП можно почитать

вот, почитай https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

книги по программированию могут учить только говнокоду, т.к. все бест практисес, теория и эвристики укладываются в пару страниц. я писал доку коудстандард для кампании, у меня получилось 5 листов ворда(с примерами кода). нет, там не было хуиты про отступы.

>> No.200967  

>>200966
Вангую, что в первой части там было, утрированно, "если вы видите два повторяющихся фрагмента кода, то объедините их в функцию" и прочие цитаты из Макконнелла, а во второй - перевод .editorconfig на английский.

>> No.200981  

>>200966

> все бест практисес, теория и эвристики укладываются в пару страниц

Посмотреть бы на эту пару страниц.

> я писал доку коудстандард для кампании, у меня получилось 5 листов ворда(с примерами кода). нет, там не было хуиты про отступы.

Или на эти пять.

>> No.200983  
File: 1652013177720.jpg -(83610 B, 404x604) Thumbnail displayed, click image for full size.
83610

>>200967
>>200981
я уже описывал в целом.

вкраце:
-фокус на простейшую имплементацию - функции. функция оптимальный уровень абстракции. если функции не вытягивают то объекты-кэширующие прокси по кэю с стэйтлесс апи, вдохновившись рест. схожие по области применения функции помещаются в отдельный файлик. пишите функцию так будто её будут все использовать. притворитесь что ничего сложнее вам никогда не потребуется. если потребуется - садись изобретай решение по ситуации и have fun, ведь у тебя появился настоящий шанс попрограммировать.
-читабельность превыше всего - уменьшайте скоуп, генерируйте данные функционально, константы повсюду.
-архитектура строится дедуктивно, от общего требуемого результата к конкретным нужным функциям. рекваерменты по возможности сперва пишутся в виде тестов. пихайте моки повсюду.
-оптимизация это приведение лэйтенси программы на таргет хардваре к нужной вели-ч`ени.
-оптимизировать вам не нужно будет, с проблемами по общей производительности пишите на anton.melkochensky@rogaicopyta.nz
*в случае если всё таки нужно - профилируйте и добавляйте кэширующие объекты. если что-то внутри объекта лагает - добавте в него логику батчинга. так делают с стэйтом внутри гпу, а гпу самое быстрое что существует. если продолжает лагать - симд или куда.

5 пунктов на 5 страниц. джуну достаточно первые 2 страницы.

>> No.200984  

>>200983
Эй, ты же говорил что ООП не нужно, а сам про объекты пишешь.

>> No.200985  
File: 1652016439521.png -(680544 B, 719x650) Thumbnail displayed, click image for full size.
680544

>>200984
ооп не нужно.

объект - это то что может быть использованно в множестве разных программ вне зависимости от решаемой задачи(например канал или вектор из стд раста), лежит в либе и покрыто тестами. ты это никогда писать на работе не будешь.

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

ещё раз, у меня нет объектов. есть какой-то пакет данных который трансформируется функциями. если где-то нужно что-то сохранить(на диск или для скорости), то в программе делается соответствующая прокси.

алсо если где-то нужно сложное поведение пакетов данных, которые в одну функцию все подряд не влезают, то такие пакеты разбиваются на набор компонентов и посылаются в системы, как а в популярном среди геймдева ecs.

>> No.200986  

>>200985
"Вы не понимаете, это другое!"

>> No.200987  
File: 1652017422945.jpg -(77004 B, 560x560) Thumbnail displayed, click image for full size.
77004

>>200986
если ты не можешь понять разницу я просто скажу боссу тебя не нанимать.

>> No.200989  

>>200985
Ну вот ты и процитировал книги выше обрывками, причем без какого-либо их обоснования.

>> No.200990  
File: 1652019742630.jpg -(99395 B, 802x850) Thumbnail displayed, click image for full size.
99395

>>200989

>НУЖНА ПРАЧИТАТЬ 5000 СТРАНИЦ А НЕ 5
>А ТО НИЧЕСНА
>> No.200992  

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

>> No.200993  

У меня на Хаскеле никаких проблем с архитектурой не возникает. Не понимаю, о чём вы тут спорите.

>> No.200996  
File: 1652032128521.jpg -(201788 B, 1000x1373) Thumbnail displayed, click image for full size.
201788

>>200992
я тебе описал свою методологию, она проверена и работает.
все твои аргументы это "ололо, ты хуй".
мы вам перезвоним.
>>200993
что пишешь?

>> No.201026  

>>183736

>Как быстро вкатиться в сишку до уровня модификации чужих кодов?

Как быстро выучить алфавит и русский язык до уровня, чтобы править чужие докторские по физике, биологии, астрономии и истории. Ты уже понял свой проеб?

Знание языка это 1% в программировании, все остальное это предметные области, алгоритмы, которые к языку не имеют отношения.

>> No.201036  

>>200996
Методология без коудстандарта тоже работает.

Правда, выдает "Host is banned".

>> No.201041  
File: 1652107160481.jpg -(134241 B, 1128x1164) Thumbnail displayed, click image for full size.
134241

>>201026

>докторские по физике, биологии, астрономии и истории

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

>> No.201043  
File: 1652107454824.png -(3562459 B, 5396x2720) Thumbnail displayed, click image for full size.
3562459

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

когда додики в додзе какую-то там хуйню изучают, потом приходит мусаши и бьёт им в ебало веслом.

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

>> No.201050  

>>201041
Ну так он же написал в >>200983.

>> No.201133  

>>201041

> ну какие там алгоритмы? сортировка пузырьком?

А вот weighted random sampling (получение случайного элемента из взвешенного множества {A: 10%, B: 20%, C:70%}) за логарифмическое время, например.

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

>> No.201135  
File: 1652412071868.jpg -(194244 B, 1600x780) Thumbnail displayed, click image for full size.
194244

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

даже если оно где-то пригодится, то скорее всего уже есть либа.

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

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

>> No.201138  

>>201135
Вот буквально неделю назад стояла такая задача. И нет, либ не оказалось, все хуярят наивным O(n). А на Википедии как раз библиотечные алгоритмы и описаны.

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

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

>> No.201140  
File: 1652416453461.jpg -(796193 B, 2300x2300) Thumbnail displayed, click image for full size.
796193

>>201138

>все хуярят наивным O(n)

и что, в ваше лейтенси оно не укладывалось? если укладывается - то и похуй. на сколько порядков ты сократил время выпонения вашей задачи?

>гугловские адово оптимизированные хеш-таблицы

свиссчиз хэшмапа есть в расте, а больше она никому нахуй и не нужна.

пока ты укладываешся в лейтенси думать про оптимизации вредно.

>> No.201141  

>>201140

> и что, в ваше лейтенси оно не укладывалось?

Не делали, если б укладывалось.

> в расте

Нахуй не нужон.

>> No.201144  
File: 1652427770912.jpg -(267870 B, 1009x1000) Thumbnail displayed, click image for full size.
267870

>>201141
повторю вопрос

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

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

>> No.201158  

>>201144
Да там и без замеров всё было ясно. Наивный вариант был в принципе неприемлем, всё тупо висло на момент расчёта, а второй юзер перестал замечать.

>> No.201460  

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

>> No.201517  
File: 1654393253458.png -(103094 B, 1400x1100) Thumbnail displayed, click image for full size.
103094

как вы относитесь к редису?

>> No.201519  

>>183736

>Как быстро вкатиться в сишку до уровня модификации чужих кодов?

K&R для синтаксиса самого языка хватит в 90% случаев.
Но С под мелкие микроконтроллеры без ОС или с лёгкими ОС, С под ядра Linux/Windows/QNX, C под юзерленд отличаются по идиоматике и паттернам весьма сильно, плюс к самому С всегда требуется (знание архитектуры процессора или конфигурации периферии, ассемблер, процесс сборки приложения, сами системы сборки, системы управления версиями пакетов, сетевые протоколы, структуры данных...) в разных пропорциях. За несколько лет можно сложить общее представление и набраться умений на уровне поправить мелкий баг, но между мейнтейнером Linux kernel и gcc и писателем прошивок под dsPIC на С разница больше, чем между бекендерами на php, go, python.

>> No.201520  

>>201517
Как к хранилке кешей.

>> No.201524  
File: 1654444207522.jpg -(1025989 B, 2288x3833) Thumbnail displayed, click image for full size.
1025989

>>201518
>>201520
я про овощ.

>> No.201525  

>>201524
Стало стыдно настолько, что удалил свой предыдущий ответ.

>> No.201528  

>>187953
Но если хочется на WinApi под Windows пописять?

Алсо, сколько не пытался, valgrind не заводится в wine. Ну и хрен с ним.

>> No.201562  
File: 1654618240362.jpg -(200033 B, 850x662) Thumbnail displayed, click image for full size.
200033

>>201528
Сюда смотрел? https://wiki.winehq.org/Wine_and_Valgrind

Скидывай логи, вместе попердолимся

>> No.201563  

>>201517
Как к лефтпаду и logz.io

>> No.201748  

>>201524

Подсаливать немного нужно.

>> No.201803  
File: 1655381609554.jpg -(342513 B, 1356x2048) Thumbnail displayed, click image for full size.
342513

Как быстро вкатиться в раст до уровня мне не надо лезть в гугл по каждому глупому поводу?

>> No.201812  

>>201748
Портишь хороший продукт.

>> No.201819  
File: 1655433154125.png -(242582 B, 733x800) Thumbnail displayed, click image for full size.
242582

>>201803
если ты про ворох методов стдлиба, то они есть прям с доками в автокомплите раст-аналайзера.

>> No.201831  

>>201803
Никак. Язык не имеет стандарта или даже гарантий стабильности текущей реализации.

>> No.201833  

>>200918

>htpd

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

>> No.201932  
File: 1655965574357.png -(2658113 B, 1466x2160) Thumbnail displayed, click image for full size.
2658113

зачем нужны обновления? вот шиндосщ - постоянно что-то там обновляет.

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

>> No.201933  

>>201932
Хех. Ты такой няша.

>> No.201935  
File: 1656004365372.png -(1943196 B, 852x1238) Thumbnail displayed, click image for full size.
1943196

>>201932
Программа выполняет свою задачу, но что-то может пойти не так.

>> No.202486  

Расскажите чем так отличается

char *str = "example";

от

char str[] = "example";

Знаю, что первое поместит строку в .rodata секцию исполняемого файла
Насколько по ламерски делать так :

char *str = strdup("example");
>> No.202487  

>>202486
Первая строка будет в неизменяемой памяти, вторая в изменяемой. strdup("r/o string") делать не опасно, а плохо это или хорошо, уже зависит от кода

>> No.203308  
#include <stdio.h>

int main(void) {
int array[] = { 10, 20, 30, 40 };
int *ptr;

printf("sizeof(array) = %lu\n", sizeof(array));
printf("%p <- array\n", array);
printf("%p <- array + sizeof(array)\n", array + sizeof(array));

for (ptr = array; ptr < (array + sizeof(array)); ptr++) {
printf("ptr = %p (%d)\n", ptr, *ptr);
}

return 0;
}

Почему здесь array+sizeof(array) указывает дальше последнего элемента? Мог бы получиться очень простой foreach.

>> No.203309  
File: 1662993960062.jpg -(1066556 B, 708x1025) Thumbnail displayed, click image for full size.
1066556

>>203308
Он размер в байтах возвращает а не количество элементов. Если вместо array + sizeof(array) использовать array + sizeof(array)/sizeof(int) то будет работать как и задумано.

>> No.203310  
File: 1662995959845.jpg -(112497 B, 1000x750) Thumbnail displayed, click image for full size.
112497

>>203308
зачем писать такой концентрированный говнокод? это же просто не читаемо человеком. зачем инкрементивать поинтер, индексинг - для лохов? кто запрещает создавать алиасы для значений с осмысленным названием?

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

>> No.203311  

>>203310
Индексинг для лохов. Особенно в Си, в котором есть указатели, особенно в эмбеддед.

>> No.203313  

>>203309

> Он размер в байтах возвращает а не количество элементов.

Это очевидно из названия же. Количество элементов вернёт универсальное макро

arraylen(a) (sizeof(a) / sizeof(a[0]))
> Если вместо array + sizeof(array) использовать array + sizeof(array)/sizeof(int) то будет работать как и задумано.

Но ведь (начало_массива) + (размер) должно быть (конец_массива). Инкремент увеличивает указатель в зависимости от типа; здесь при сложении (array + sizeof(array)) тоже срабатывает какое-то неочевидное правило?

>> No.203314  

>>203313

>arraylen(a) (sizeof(a) / sizeof(a[0]))
char *v;
v = malloc(sizeof(char) * 5);
printf("%d\n", sizeof(v) / sizeof(v[0]));

Почему не итерировать до NULL как все нормальные люди?

>> No.203315  
File: 1663007925330.jpg -(399179 B, 750x1062) Thumbnail displayed, click image for full size.
399179

>>203313

> Инкремент увеличивает указатель в зависимости от типа; здесь при сложении (array + sizeof(array)) тоже срабатывает какое-то неочевидное правило?

При сложении с int и ему подобными работает то же правило что и при инкременте. Ту же логику можно было реализовать как (void*)ptr < ((void*)array+sizeof(array)).

>> No.203316  

>>203314

> arraylen(a) (sizeof(a) / sizeof(a[0]))
> malloc

Ну, и что?
Здесь другой тип. arraylen срабатывает для массивов с заданным во время компиляции размером. sizeof(a[0]) нагляднее, чем sizeof(*a) — сразу видно, что здесь требуется массив.
Размер памяти, выделенной маллоком, определён во время выполнения — даже если в качестве аргумента маллоку передать литерал.
sizeof(v) вернёт размер указателя, sizeof(v[0]) - размер типа,

printf("%d\n", sizeof(v) / sizeof(v[0]));

и получится из этого —

printf("%d\n", 8 / 1);
> Почему не итерировать до NULL как все нормальные люди?

Потому что NULL = (void*)0; по массиву чисел с такой проверкой не поитерируешь.
>>203315

(void*)ptr < ((void*)array+sizeof(array))

Теперь мой форы́ч работает.

#include <stdio.h>

#define foreach(iter, ptr) \
for (ptr = iter; (void*)ptr < ((void*)iter + sizeof(iter)); ptr++)

int main(void) {
int array[] = { 10, 20, 30 };
int *ptr;

foreach(array, ptr)
printf("%d\n", *ptr);

return 0;
}
>> No.203318  

>>203315
Проще открыть The C programming langue на разделе pointer arithmetic и разобраться за 15 минут что к чему, чем бегать по имиджбордам и спрашивать фигню.
>>203316

>Теперь мой форы́ч работает.

Стремно выглядит. Особенно

>(void*)ptr < ((void*)iter + sizeof(iter))

не объяснишь? Намного интуитивнее и проще смотрится

#include <stdio.h>

// Must be plain array, not pointer (e.x. char a[], not char *a)!
#define foreach_in_array(array, element)\
for (\
element = array;\
element < array + sizeof(array)/sizeof(array[0]);\
element++\
)

int main() {
int a[] = { 0, 1, 2, 3, 4 };
int *i;
foreach_in_array(a, i) {
printf("%d\n", *i);
}

char str[] = "NOWERE";
char *c;
foreach_in_array(str, c) {
if (*c != '\0')
printf("%c\n", *c);
}
}
>> No.203319  

Вывод:

0
1
2
3
4
N
O
W
E
R
E
>> No.203325  

>>203318

> Стремно выглядит. Особенно
> (void*)ptr < ((void*)iter + sizeof(iter))
> не объяснишь?

Объясню. По умолчанию прибавляется не количество байт, а количество элементов переданного типа, но размер void равен одному и после каста прибавляется именно размер в байтах.

> Намного интуитивнее и проще смотрится
> […]

Ещё интуитивнее и проще будет

#define foreach(array) \
for (\
size_t i = 0; \
i < (size_t)(sizeof(array) / sizeof(array[0])) && array[i] != '\0'; \
i++ \
)

, полностью универсально, вдобавок, но по стандарту С99 и выше. Значение i, присвоенной за пределами цикла, не заменяется.

> Проще открыть The C programming langue на разделе pointer arithmetic и разобраться за 15 минут что к чему, чем бегать по имиджбордам и спрашивать фигню.

Ты меня пристыдил. Об этой особенности арифметики с указателями написано прямо в начале главы 5.4.

>> No.203328  

>>203325

>Ещё интуитивнее и проще будет

Нет.

>> No.203974  

rust пролез в ядро и линупс-пингвинус одобрил

>> No.203975  

>>203974
Пусть. С не может жить вечно. Задача безопасности софта уже давно стоит и в С безопасность достигается максимальным упрощением кода. Как только код стает нетривиальным, его по умолчанию считают небезопасным. Это бред, пора переходить на новый уровень, а раст отличная возможность обкатать идею. Раст через 5-10 лет издохнет и на его место прийдет новый король. А может и нет. Зависит от того, допустят ли к работе умных инженеров, или очередных говнокодеров.

>> No.203976  
File: 1664010733873.png -(1077011 B, 1280x720) Thumbnail displayed, click image for full size.
1077011

>>203974
...and that's a good thing!

>> No.203977  
File: 1664010835565.jpg -(250598 B, 1184x1467) Thumbnail displayed, click image for full size.
250598

>>203975
вареник по дефолту охуеннейший язык, лучший. идеальный, лучше не будет, только фич мало.

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

>> No.203978  

Говорят что раст это пропаганда.

>> No.203979  

>>203977

>лучше не будет

Рано ты постарел.

>> No.203984  

>>203978
Конечно пропаганда. Ты на раст фоундейшн посмотри.

>> No.203990  

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html

>> No.203991  
File: 1664055967757.png -(49670 B, 1536x1920) Thumbnail displayed, click image for full size.
49670

>>203990

>а вот goвно...

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

>> No.203992  

>>203991
И webp.

>> No.203997  
File: 1664062854894.jpg -(127624 B, 800x1300) Thumbnail displayed, click image for full size.
127624

>>203992
таки да.
******
логичный, но неожиданый союз

>> No.203998  

>>203992
Если создавать только говно, люди не поймут, кроме того, шебп и вп9 были выгодны для бизнеса. Ничем и ни капли не оправдывает гугл. Они и жаббер когда-то развивали, а потом из-за них же он и умер.

>> No.204001  

>>203991
Мелкобуква ебучая, там про го меньше абзаца. Ты всю статью читай.

>> No.204002  

>>203991

>всё что создаёт гугл - поебень.

Гугл участник раст фоундейшн
https://foundation.rust-lang.org/

>> No.204003  

>>203990

> Rust is not a good C replacement

Насколько тезисы этой статьи актуальны в конце 2022го?
Решил наконец спустится на дно и потыкать етот ваш раст

питонист-RRRRяяяяист

>> No.204004  

>>204003
Все ещё актуальны.
Если вам интересен раст, пожалуйста создайте про него отдельный тред.

>> No.204007  

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

>> No.204011  

>>204001

>Ты всю статью читай

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

>> No.204012  

>>204011
*который не С

>> No.204016  
File: 1664134206111.jpg -(173098 B, 1280x720) Thumbnail displayed, click image for full size.
173098

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

>C is the most portable programming language

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

>> No.204018  

>>204016
Ты прочитал только один пункт, а остальное пропустил мимо ушей. Потому что мелкобуква не читатель, а писатель. Писатель бредней, и бредни свои пишет с маленькой буквы потому что недостаточно концентрации внимания чтобы дотянуться пальцем до шифта.

>> No.204033  
File: 1664162356945.png -(65718 B, 340x296) Thumbnail displayed, click image for full size.
65718

>>204018
да, и..?

>> No.204035  

>>204016
Согласен с портабилити. На ембед можно и отдельный язык завести, или С оставить, что бы мозги не трахать, а для всего остального использовать что-то нормальное.

>> No.204049  

>>204018
у меня туннельньій синдром на обе руки.
*его брат по разуму.*

>> No.204067  
File: 1664287119975.jpg -(3387107 B, 2000x3000) Thumbnail displayed, click image for full size.
3387107

>>204049
соболезную, говорят очень противная штука. как живешь-то с этим?

>> No.204144  

>>203977
Я его дропнул из-за синтаксиса.

>> No.204151  
File: 1664463117462.jpg -(275070 B, 2411x1447) Thumbnail displayed, click image for full size.
275070

>>204144
и чё не понравилось, что бы ты поменял? классный синтаксис, меня всё устраивает.

>> No.204180  

>>204151
(Не помню твои предпочтения, но ты в любом случае их только что оверрайднул.)
C++ тебе вообще на ура зайдет, базарю.

>> No.204186  
File: 1664621075426.jpg -(1439139 B, 3172x2160) Thumbnail displayed, click image for full size.
1439139

>>204180
можешь ответить на вопрос? мне интересно твоё мнение, что надо в варенике изменить.

>> No.204188  

>>204186
Синтаксис, очевидно же.

>> No.204189  

Кстати, если в варенике реально синтаксис как в плюсах (я не смотрел, ага), то нахуй надо. Плюсы дрочь полная в плане синтаксиса.

>> No.204191  
File: 1664629867863.png -(4970441 B, 1247x2036) Thumbnail displayed, click image for full size.
4970441

>>204188
>>204189
не смотрел но осуждаешь?

давай так: какой синтаксис ты хочешь?

>> No.204192  

>>204191
Это два разных постера, я >>204189.
Хочу как в С. Хороший, простоей и понятный синтаксис. Разве что декларации функций можно поменять, типо как в хачкеле, потому что чисто по человечески это понятей.

>> No.204193  
File: 1664633260433.jpg -(577550 B, 2560x1440) Thumbnail displayed, click image for full size.
577550

>>204192
ну он в варенике и есть как в ц.

>> No.204224  

>>204191
Английский с ISO-80000-2 (каким написан, например, http://www.cs.utoronto.ca/~szhao/group_theory_thms_defs.pdf). Правда, анальникам до него - как России до безвиза с Украиной, но могли бы сделать хотя бы как в Агде или втором Идрисе.

>> No.204225  
File: 1664706039116.jpg -(724958 B, 2422x1638) Thumbnail displayed, click image for full size.
724958

>>204224
синтаксис это штука субъективная, и будет делаться как привычно большинству юзеров. т.е. смесь джээс и сяшки, как в расте или питухоне.

для математиков есть хачкель.

>> No.204226  
File: 1664706906975.jpg -(101452 B, 850x1063) Thumbnail displayed, click image for full size.
101452

>>204224
алсо, прежде чем ты ещё раз повторишь что хачкель хуйня для нубов, а вот идрис тру: ты можешь на идрисе вебсервис написать? а на хачкеле можешь.

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

>> No.204228  

>>204225
Большинству юзеров привычен английский.

>> No.204229  
File: 1664707097036.jpg -(101200 B, 546x717) Thumbnail displayed, click image for full size.
101200

>>204228

>> No.204230  

>>204228
Чушь полная. Большинству юзеров привычен китайский.

>> No.204231  
File: 1664707531316.gif -(845 B, 23x18) Thumbnail displayed, click image for full size.
845

>>204230
у китайцев своя атмосфера. капча соглашается.

>> No.204232  

>>204231
Тогда хинди.

>> No.204233  
File: 1664708228013.jpg -(75671 B, 886x527) Thumbnail displayed, click image for full size.
75671

>>204232
в этом случае как раз таки английский, сир.

>> No.204234  

>>204226
Так ты про синтаксис спрашивал.

>> No.204235  

>>204234
Для него существуют только два типа мнений - его собственное и неправильное. Все аргументы им будут игнорироваться.

>> No.204239  

>>204226

>хачкель

Мотивация учить математику, лол. Тяжеловато вкатиться в это, однако.
>>204235
Ваш унылый троллинг надоел, пора придумать что-то более утонченное. Тем более, что мелкочень это целый кладезь для троллинга.

>> No.204246  

>>204239
В хачкеле математики столько же, сколько каббалы в Евангелионе. Там больше необычная модель вычислений мозг выносит.

>> No.204250  
File: 1664719838716.jpg -(92511 B, 619x800) Thumbnail displayed, click image for full size.
92511

>>204239
я вообще до сих пор не понимаю в чём смысл троллинга на аиб. вы мне вкидываете хуйню - я отвечаю хуйню. ну или не отвечаю.

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

>> No.204251  

>>204250
Дай детям поиграться.

>> No.204253  
File: 1664720177822.jpg -(122149 B, 900x1221) Thumbnail displayed, click image for full size.
122149

>>204250
Ты совершенно не понимаешь сути троллинга!

>> No.204255  
File: 1664720572550.jpg -(74700 B, 842x642) Thumbnail displayed, click image for full size.
74700

>>204253
нет вы!

>> No.204256  

https://rustmustdie.com/
вопрос к Мелк-о-Чень: каковьі твои мьісли о статье? троллинг ли статья?
и про вот єто: https://habr.com/ru/post/598219/

на ameliorated windows нет переключателя раскладки без сменьі локали, перепрошую.

>> No.204257  

>>204239

>Тем более, что мелкочень это целый кладезь для троллинга.

ну, еще он сексуален. разумом.

>> No.204267  

>>204250
Ты же мелкобуква, откуда тебе что-то понимать.
https://lolwut.info/comp/trolling-definition.html

>>204256
https://wiki.opennet.ru/RUU
Советую, сам когда-то пользовался, пока не понял, что на белорусском мне особо не хочется писать.

>> No.204270  

>>204267

>Ты же мелкобуква, откуда тебе что-то понимать.

Так ты же сам под свое определение не попадаешь.

>> No.204274  

>>204049
Ну значит я и не троллю.

>> No.204276  
File: 1664737136025.jpg -(2330996 B, 4331x5906) Thumbnail displayed, click image for full size.
2330996

>>204250
Разве он был не в том чтобы причинить неудобство и ощутить злорадство?

>> No.204286  
File: 1664754687266.jpg -(135304 B, 719x1200) Thumbnail displayed, click image for full size.
135304

>>204256
первая - хуита. растовские либы и проги зачастую наиболее быстрые, можешь сам загуглить бенчмарки.
пример - хуйня, автор даже не в курсе что есть get_unchecked, которую он может реекспортировать глобально как чё угодно и использовать. я люблю раст именно за дженерики, которые позволяют сделать ПОДСЕБЯ как в линуксе. по дефолту же в расте хороший для энтерпрайза подход к безопасности. сравнивать языки по трём строчкам кода - цирк.

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

суть качественного языка вообще не в том сколько байтиков выдаёт трёхстрочная программа. в современном мире бинарь меньше 100мб это норма. совершенно похуй какого он размера. ну окдшникам может быть это важно. и скорость работы тоже не важна. важна гибкость, которая в расте есть. по дефолту ты можешь в нём писать практически как в джаваскрипте, но вот когда где-то у тебя что-то не укладывается в лейтенси, то в отличии от goвна или сисярпа, в расте ты можешь начать писать как в си и получить максимальный контроль над кодом. оптимизации до профилирования это признак нуба и источник говнокода.
>>204276
негативные эмоции которые не переходят в реальность всегда будут сильнее на стороне "троллера". именно поэтому притворяться дебилом на аиб - не троллинг, ну или троллинг самого себя.

>> No.204287  
File: 1664756192289.jpg -(273375 B, 1920x1080) Thumbnail displayed, click image for full size.
273375

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

>> No.204288  
File: 1664766021281.jpg -(71606 B, 765x538) Thumbnail displayed, click image for full size.
71606

>>204256
алсо вот это

>Мелк-о-Чень

деление на ноль. суть ō-чень в том что это большая чень.

>> No.204290  

>>204286

> сисярпа
> goвна
> си

А если сравнивать с языками программирования?

>> No.204293  
File: 1664775517966.jpg -(169762 B, 1000x1200) Thumbnail displayed, click image for full size.
169762

>>204290
в тред вкатывается питухонист?

глядите какая птикча нашлась.

>> No.204295  

>>204293

>питухонист

нет, жаваскриптер, ололо.

>причка

твои сусеки перескрести таких птиц найдешь, глаза позападают, имхо

>> No.204298  
File: 1664786614860.jpg -(487183 B, 608x800) Thumbnail displayed, click image for full size.
487183

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

>> No.204312  

>>204293
Нет, с языками программирования.

>>204295
Да нет же, с языками. Программирования. С Хаскелем, там, с F#...

>> No.204324  
File: 1664804544260.jpg -(754760 B, 1200x720) Thumbnail displayed, click image for full size.
754760

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

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

>> No.204330  

>>204324
Ну, он такой, примитивненький, да, для бегущей строки на веб-страничке сойдет (точнее, сошел бы, но как-то не сложилось). Но вопрос >>204290 не об этом.

>> No.204332  
File: 1664805799080.jpg -(1003594 B, 1000x1571) Thumbnail displayed, click image for full size.
1003594

>>204330
а о чём?

>> No.204340  
File: 1664807138061.jpg -(129111 B, 850x1200) Thumbnail displayed, click image for full size.
129111

>>204332
Вопрос был, можно ли в случае слишком большого латенси писать на языке программирования, как на C. Нет, нельзя, потому что C - это не язык программирования. Но для этого есть FFI.

>> No.204355  

>>204340
Согласен, C - это язык для прошивок.

>> No.204452  
File: 1665025916971.jpg -(221787 B, 1600x1131) Thumbnail displayed, click image for full size.
221787

>>204355
а раст - это язык для анимэшных девочек.

https://www.youtube.com/watch?v=xxpQzyUncGY

>> No.204453  

>>204452
Кстати, такий прикол, что эта (вроде эта) витубица реверс инжинирнула дрова на какую-то видюху и написала свое поделие на расте и вроде даже пыхтит.

>> No.204458  

>>204453
Хорошая попытка. Если б это был не M1 который мне вот вообще никаким боком - даже попробовал бы посмотреть, ибо тот случай когда контент решает, несмотря на формат.

>> No.207184  
File: 1667048136566.jpg -(11425 B, 188x269) Thumbnail displayed, click image for full size.
11425
$ fgrep -w 71 /usr/include/errno.h 
$ fgrep -w include /usr/include/errno.h
#include <features.h>
#include <bits/errno.h>
#include <bits/types/error_t.h>
$ locate bits/errno.h
/usr/include/x86_64-linux-gnu/bits/errno.h
$ fgrep -w 71 /usr/include/x86_64-linux-gnu/bits/errno.h
$ fgrep -w include /usr/include/x86_64-linux-gnu/bits/errno.h
# error "Never include <bits/errno.h> directly; use <errno.h> instead."
# include <linux/errno.h>
$ fgrep -w 71 /usr/include/linux/errno.h
$ fgrep -w include /usr/include/linux/errno.h
#include <asm/errno.h>
$ locate asm/errno.h
/usr/include/x86_64-linux-gnu/asm/errno.h
$ fgrep -w 71 /usr/include/x86_64-linux-gnu/asm/errno.h
$ fgrep -w include /usr/include/x86_64-linux-gnu/asm/errno.h
#include <asm-generic/errno.h>
$ fgrep -w 71 /usr/include/asm-generic/errno.h
#define EPROTO 71 /* Protocol error */

В некоторых хидерах вообще нет ничего, кроме очередного инклюда.

>> No.208935  

>>204324
Что такое монада и в чем крутость ФП относительно ООП?

>> No.208958  

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

>> No.208960  
File: 1667445837746.jpg -(37064 B, 864x486) Thumbnail displayed, click image for full size.
37064

>>208958
Опять пришёл поручик и всё опошлил.

>> No.208964  
File: 1667496424254.jpg -(271249 B, 500x871) Thumbnail displayed, click image for full size.
271249

Писать скрипты на Си в онлайновом компиляторе. Так как не осилил Excel. А поставить что-нибудь на комп проблема. Это сильное извращение?

>> No.208965  

>>208964
Смотря какие скрипты. Но упоминается Excel, поэтому могу предположить, что скрипты с довольно низким IQ, тогда извращение весьма умеренное.

>> No.208969  
File: 1667500345367.gif -(22176 B, 455x541) Thumbnail displayed, click image for full size.
22176

>>208965
Ну, да. Какая-нибудь фигня. Типа отсортировать массив данных и сделать над ним какие-нибудь математические операции.

>> No.208970  

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

>> No.209211  
File: 1667503911585.png -(129270 B, 944x468) Thumbnail displayed, click image for full size.
129270

>>208970
Может это и удобнее, чем на Си, но питоновский код выглядит отвратно. Все эти iterable объекты, которые нужно явно приводить к list, эта ужасная функция map, которая не хочет через точку как в Скале или JS, а требует длинную шнягу с обилием скобочек - и я не говорю о скорости инвалидной коляски, если ты попытаешься сделать что-то сложное не готовой написанной на плюсах библиотекой, а инструментами языка.

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

>> No.209231  

>>209211
Вообще-то есть, называется coreutils.

>> No.209232  
File: 1667563930273.png -(282690 B, 1920x1047) Thumbnail displayed, click image for full size.
282690

>>209211
Эх... Людям давно сделали Ruby, но все делают вид, будто его не существует и как попугаи: змеюка, змеюка, курсы, выучить змеюку. Как же это печально. Там приятный человеку синтаксис, в остальном абсолютно та же скриптота. Какой-то заговор замалчивания.

>> No.209235  

>>209232
У руби вроде не было интерактивного режима как в змеюке.

>> No.209236  
File: 1667566932275.jpg -(40453 B, 199x183) Thumbnail displayed, click image for full size.
40453

>>209235
Их было аж несколько.

>> No.209237  

>>209236
Но при запуске по умолчанию он его не умел, что меня в те времена и остановило.

>> No.209246  
File: 1667594337288.jpg -(90488 B, 1004x879) Thumbnail displayed, click image for full size.
90488

>>209232

Код прикольно выглядит. С теплотой вспоминаю CoffeeScript. Но CoffeeScript постепенно стал считаться зашкваром. Интересно, как порой меняются понятия того, что "модно", а что нет.

А React-хуки, например, наоборот модные, хотя превращают код в месиво. Но все тоже как попугаи повторяют: хуки-хуюки, фи, class components это so 2017.

>> No.209254  

Чем вам Перл не угодил, ироды?

>> No.209255  
File: 1667599698017.jpg -(112595 B, 587x800) Thumbnail displayed, click image for full size.
112595

>>209232
в вареник гаты завезли, а вы всё на своих мусоросборниках сидите.

>> No.210807  
File: 1667609660178.jpg -(355943 B, 1386x1369) Thumbnail displayed, click image for full size.
355943

бехолд:

assert_eq!(monadic::join(Some(Some(true))), Some(true));
>> No.210858  

>>209255
И нафига оно надо?

>> No.210860  

>>209255

Чень, мы это уже обсуждали.

>>210858

Вообще или в варенике? Если второе, то ни в пизду, ни в Красную армию.

>> No.210861  

>>210860
А если первое?

>> No.210879  

>>209254
А ведь его тоже раздлелили на две ветки как и питон.

>> No.210880  

>>210879
Отрежь змеюке голову...

>> No.210896  
File: 1667723504941.jpg -(145671 B, 1089x1520) Thumbnail displayed, click image for full size.
145671

>>210858
->
>>210807

>> No.210898  

>>210896
Чтобы писать нечитаемый код?

>> No.210903  

>>210860
Например, чтоб тебе даза банных при запросе "select такой-сякой список булов" не вернула [true, false, жопа]. Или чтоб после парсинга жсонов не приходилось их еще раз парсить. Ну и чтоб запиливать типобезопасные языки, конечно же.

>> No.210904  

>>210903
Приведение типов? Нет, не слышал.

>> No.210905  
File: 1667728970238.jpg -(163169 B, 1400x1000) Thumbnail displayed, click image for full size.
163169

>>210898
??

>> No.210906  

>>210905
!!

>> No.210908  

>>210904
Это оно и есть, только работает на этапе компиляции.

>> No.210909  

>>210908
Шел 2022 год, в расте додумались до приведения типов. Отличный язык.

>> No.212811  

>>208964
>>208969
Используй awk же!
Это скриптовой Си подобный язык, который именно для тех задач и разрабатывался для которых ты пытаешься использовать сишку.
Если не можешь на компьютер поставить, то можешь попробовать использовать public access unix system типа sdf.org

Кстати awk рассшифровывается как: Aho, Weinberg, Kernighan в честь создателей этого языка.
Это один из немногих языков, где не действует IEEE754 и 0.1+0.2==0.3

>> No.212812  

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

>> No.212815  
File: 1674155430056.jpg -(97632 B, 957x1280) Thumbnail displayed, click image for full size.
97632

>>212812
https://man7.org/tlpi/index.html
>>188331

>Здесь ломаться нечему

Buffer overflow ?

>> No.212817  

>>212815
s/Buffer/Integer/

>> No.212823  

Как присоединить сишку к графике в линуксах? Гтк-кутэ и тд. Гуглю - огромный поток непонятных слов. Учил оп-книгу.

>> No.212825  
File: 1674160216100.gif -(168 B, 65x19) Thumbnail displayed, click image for full size.
168

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

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

уцух, как ты сделал говорящую каптчу? слишком часто совпадает для совпадения. высшие силы, не иначе

>> No.212827  

>>212823
Метавопрос. Переформулируй пожалуйста. ГТК и кьют это тулкиты, а "графику" можно и без них рисовать, хоть с OpenGL – это низкоуровнево и именно про графику, а не графический интерфейс, хоть с cairo – уровень повыше, библиотека для двухмерной векторной графики.

>>212825
Попей оланзапина.

>> No.212828  

>>212827
Я хочу чтоб в учебном стиле меня научили применять цэ к какой то графике. Как с этой графикой играться я придумаю, разобравшись в том, чему меня научат.
Так я бы чувствовал себя хорошо и ощущал прогресс.

>> No.212830  
File: 1674181966955.jpg -(149567 B, 891x1306) Thumbnail displayed, click image for full size.
149567

>>212823
для кюти устанавливаешь qtcreator и смотришь доку/самплы.

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

>> No.212831  
File: 1674182230888.jpg -(65851 B, 488x639) Thumbnail displayed, click image for full size.
65851

>>212828
https://github.com/ocornut/imgui

ну вот держи. а про кутежткпоебень забудь.

>> No.212841  
File: 1674224505029.jpg -(108700 B, 604x590) Thumbnail displayed, click image for full size.
108700

>>212831

>> No.212845  

>>212831
Он просит учебник, а не ссылку на библиотеку. Хотя может быть она и лучше других тулкитов.
>>212830
Попей респеридона.

>> No.212846  

>>212845
сам попей. смотри какой умный нарисовался. не умеешь видеть глубже первого слоя нашей виртуализации? досвидания. а мы тут серьезные люди, симуляция не шутка.

>> No.212860  

>>212846
Да, да, да видел, потом попил оланзапина.
Ты тоже попей, здоровее будешь. Надо лечиться

>> No.212866  

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

>> No.212878  

>>212866
Попробуй сделать шейдер на GLSL
https://ru.wikipedia.org/wiki/OpenGL_Shading_Language
А вообще не надо очаровываться, чтобы потом не разочароваться.

>> No.212879  

>>212878
В шкиле паскаль умел в графику.

>> No.212880  
File: 1674336739263.png -(86598 B, 600x315) Thumbnail displayed, click image for full size.
86598

Нагуглил
http://ods.com.ua/koi/unix/svgalib.html
Просто подключаем библиотеку и просто терминале играем с пикселями

>> No.212881  

Или не просто

>> No.212887  

>>212879
Это же был Паскаль ABC.NET
Оригинальный Виртовский Паскаль как Си в графику сам по себе не умел.
Да и стандарт на Паскаль наверняка ничего про графику не содержит.

>> No.212888  

>>212880
Жесть конечно что ты откопал

>> No.212889  
File: 1674355082720.jpg -(81543 B, 635x900) Thumbnail displayed, click image for full size.
81543

>>212866
https://learnopengl.com

>> No.212890  

>>212889
хочу пощупать хлоро

>> No.212903  

>>212890
Кот бы не пощупал?

>> No.212904  
File: 1674400762621.jpg -(21179 B, 300x300) Thumbnail displayed, click image for full size.
21179

>>212889

>OpenGL

Напомни, какой сейчас год?

>> No.212905  

>>212904
А что, модно-молодёжный Вулкан сильно отличается? Там даже названия методов одинаковые для совместимости.

>> No.212906  
File: 1674404835459.jpg -(85916 B, 1200x831) Thumbnail displayed, click image for full size.
85916

>>212904
напомни, зачем вулкан нубу? ты вообще знаешь чем у них спеки отличаются?

>> No.212907  
File: 1674408549776.png -(4869 B, 504x439) Thumbnail displayed, click image for full size.
4869

Вот

>> No.212913  

Я хочу программу чтоб можно было из шариков молекулы собирать.

>> No.212924  

>>212812

> Надо учить линухи чтоб применять можно было.

Brian W. Kernighan, Rob Pike — The UNIX programming environment
https://libgen.is/book/index.php?md5=AFE458B6FCFE968E58A040B30F5222B4
Перевод не советую, даже в нетехнических описаниях перлы порой такие, что без хорошего штакетника не въедешь (с ним тоже не въедешь, но будет всё равно).

>> No.212925  

>>212924
Там есть как сделать окно >>212907 и в нем графику?

>> No.212982  

>>212925
Как сделать окно, будет в описании иксопротокола и XLib/XCB. Если сложно, тутор по GTK. Если опять сложно - Tcl/Tk.

>> No.212987  

>>212982
А там есть?

>> No.212990  

>>212913
Детально опиши что ты хочешь и мы посмотрим что можно сделать.

>> No.212992  

>>212990
Это был пример того ради чего можно было бы что-то учить.
А я хочу ПЛАВНЫЙ переход от учебника языка ЦЭ к графическому приложению.

>> No.212994  

>>212992
подожди лет 50-60, если повезет, порог вхождения к тому моменту будет относительно плавным.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]