Проект на чистом Си

Для утюгов есть muon.

Матрица опять дала сбой))

Проблема вот в чём: в эталонном проприетарном ПО (тот же Фотошоп с 3ds максом) изначально запиливают единственный разумный интерфейс, пригодный даже для разовых работ. Но… никто ж не будет тупо клонировать, все ведь, сцуко, креативные личности.

Вот и получаем СПО с мозголомным управлением. Иногда трансмутируют в конфетку, как Блендер. Иногда высвобождают внутренную или проприетарную (но переставшую быть прибыльной) разработку, как Ghidra.

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

Так и живем.

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

Твою ж мать, я ведь искал, отвечал ли я на этот комментарий, почему-то не нашёл.

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

Обе части утверждения спорны.

1. Если бы интерфейс был единственно разумным - его бы не меняли в каждой версии.
2. Эти программы на Западе стоят столько что для разовых работ их никто приобретать не будет. Иногда конечно встречаются и «пираты» но сомневаюсь что разработчики будут учитывать их потребности.

Вот и получаем СПО с мозголомным управлением.

На лично мой взгляд в Гимпе мозголомности не больше чем в Фотошопе,как и наоборот. Да, фотошоп больше ориентирован на полиграфию, но это актуально только тем кто работает с типографией,а таких среди общего числа пользователей графических редакторов не особенно много.

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

Как имеющий отношение к любительской электронике могу назвать основную причину этого. В руки самодельщиков если действительно хорошая аппаратура и попадает то обычно списанная и директивно объявленная «морально устаревшей». От этого она хорошей быть не перестает и обычно превосходит по характеристикам ту что лежит в магазине «новая и современная» (сделанная в Китае непонятно кем и как). А та что настоящая современная - стоит таких диких денег что в ее сторону никто даже и не пытается смотреть. Так что действительно Made in Japan (C) 1993 обычно лучше чем Made in China (C) 2023. Цена при этом примерно одинакова.

Гимп

Не надо зацикливаться на нём, он, после исправления родового порока многооконности - почти конфетка.

директивно объявленная «морально устаревшей».

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

радиолюбители

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

А ведь так можно и до Программатора Вертьянова™ додеградировать, и до прочего ЛГБТ…

он, после исправления родового порока многооконности - почти конфетка.

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

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

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

Здравствуйте! Я учусь языку С и не могу понять,
как из строки **f** вычесть подстроку **m**.
Не могли бы вы мне тезисно подсказать.

😆️

вендорлочиться на D-STAR и прочую муть

ну с дстаром и есовским fusion хоть примерно понятно, почему их поклонники их собсно любят - сравнительно много изначально предназначенных для радиогубителей девайсов. Не вендорлокнутые DMR/P25 устройства добывались только из энтерпрайза «взрослой» связи, где конечному пользователю ничего кроме шумодава крутить не положено, и на любую перенастройку - доставай шнурок с компом и шей замуженные конфиги.

вот вам архитектура PDP https://en.wikipedia.org/wiki/PDP-11_architecture, будьте добры, облейте меня мудростью и утопите в величии вашего интеллекта ответив на вопрос, что конкретно из этой архитектуры нашло отражение в систаксисе языка Си, и каким бы получился Си если бы его писали с прицелом на архитектуру, скажем, Z-80. Спасибо

например, режим адресации РОН и стековый режим адресации

все эти конструкции типа перемещения *src++=*dst++ <-> MOV (R1)+,(R2)+ например, в этом примере это пролог/эпилог с PUSH/POP R0,R1 и BICB #40,-(R0) <-> *R0–&=~0x40 //clear that bit

очевидно (тому, кто знает ISA set опкодов архитектур MC 680x0, PDP-11, Z80, X86-64) – что в Motorola 68k и PDP-11 такие режимы адресации есть (с авто инкрементом/декрементом) – а в Z80, X86 – нетути.

вот тебе ещё для затравки: язык C как переносимый ассемблер высокого уровня похож не только на опкоды вот таких ассемблеров CISC-alike – но и в какой-то мере, на нетипизированный BCPL,CPL,B,C.

например, тип данных в BCPL – один – это «слово». размер этого слова машинозависим, но например, именно поэтому типизация в BCPL отсуствует как класс – то ли это адрес, то ли значение, то ли битовая строка которую надобно расшифровывать pack/unpack.

можешь сам скачать посмотреть современный BCPL и его интерфейс с SDL на Raspberry PI, например. там эти обёртки всю дорогу.

концепция указателей в C не продумана, и тянется это с того самого BCPL: указатель на яблоки = указатель на апельсины, хотя это типизированные ссылки разных типов. в общем, тут как в ассемблере, B, BCPL, C(++) – куча костылей всю дорогу by design

ещё можешь там (в сорцах BCPL) посмотреть на такую операционку, как TRIPOS. которая целиком и полностью была на этом BCPL написана.

TRIPOS, по слухам, лежит в основе AmigaDOS Exec (микро)ядра. В общем-то, само ядро амиги классической – это вот этот кусок из BCPL + шелл который System-Startup обрабатывает и подозрительно напоминает куски из сорцов BCPL и TRIPOS (видать, тоже на BCPL написан). плюс такая вещь например, как AmigaREXX на котором есть «порты» управления приложениями, и например любой GUI начиная с MUI (Zune) по умолчанию скриптуем, то есть, любое более-менее современное GUI приложение уже скриптуемо по умолчанию.

но можешь например и классический vimED заскриптовать AREXX-ом, например см. вот тута:

Above, we can see Ed editing an ARexx script. Below is an AmigaShell window using Ed’s own ARexx port to send instructions to Ed. I have just sent the command T; RP E /g./global./, renaming the compound variable g to the more descriptive global. Click the image for full resolution.

просто удивительно, что в Unix-ах до такого не додумались – максимум что пытались это навороченный expect делать для tck/tk – и главное, tk тоже приложений.

ещё в ней всё хорошо с tagged union указателями, с различением типизированных ссылок и обычных указателей.

var’access гораздо круче и верифицируемо во время компиляции – чем var’address (который там тоже есть, но неправославен) :)

Лишь сказал что простота Си (исходного К&R варианта) была обусловлена аппаратными ограничениями по объему памяти. И сказано это было в контексте вопроса встраивания в язык работы со строковыми типами,имеющими сложное внутреннее представление и повышенные требования к памяти.

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

но что там происходит с типизацией данных, теорией типов, типами высшего порядка, всякими там first class object типами этих самых высших порядков?

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

например, тот же BitC или Cyclone уже более выразителен.

но тогда уже возникает другой вопрос – а если есть некоторое герметичное корректно замкнутое ядро типов/пакетов/модулей языка, типа как в ML или Ada – то зачем тогда нафиг нужна синтаксическая совместимость с низкоуровневым высокоуровневым переносимым ассемблером вообще? ну то есть она вроде как нужна на уровне модели памяти С и _cdecl calling conventions, то есть, на уровне C ABI – примерно на уровне gcc -c file1.c file2.ada -fdumpspecs-ada для автоматической генерации pragma(C,import) – а более особо и не нужна вообще.

и даже если изобретать «переносимый ассемблер высокого уровня». то есть более выразительные варианты. например, такой язык как HLA by Randy Hyde «Art Of Assembly». у него есть CTFE макросы довольно выразительные (почти как в D) – на которых написаны: аналог STL, ООП системы, исключения, и прочее.

в общем-то, если есть нормальное typeinfo и RTTI как в D, или атрибуты типов данных пакетов как в Ada (с нормальным и понятным API расширения) и продуманный интерфейс типа ASIS или CTFE в D – то и этого может оказаться достаточно.

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

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

внезапно, может быть и PL/I с его UNSPEC командой (типа emit непосредственных опкодов) было бы достаточно для ликвидации всяких UB на ровном месте :)

Чем всё закончилось, сколько коммитов удалось сделать за эти 20 дней?

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

классический Лео Броуди «Thinking FORTH» про «форт – как образ мышления», «концепция языка» – как-то и фортом обходился году эдак в 1982, вроде бы.

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

отсюда один шаг до какого-нибудь Jack Crenshaw «Let’s make a compiler» IEEE edition – изначальный компилятор Креншоу был паскаля на паскале, а переписанный (и в книгах Баранова по форту тоже) – паскаля на форте.

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

далее смотрим например Taygeta и публикации J. V. Noble про ассемблер на форте – и библиотеку численной математики через «компилирующие слова», в общем получаем и прозрачно внедряемый ассемблер в форт, и программируемый DSL синтаксис.

к которому сверху ничего в общем-то не мешает прикрутить паскалеподобный синтаксис как у Креншоу и Баранова.

Ну или адский (типа того интерпретатора Ады досовского или Sparforte)

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

на лиспе в общем-то тоже не сильно сложнее вышло бы. например, есть x86 ассемблер на Guile, довольно компактный (как бы не проще того форт-ассемблера). в который элементарно обернуть всё такое на выходе кодогенератора – и прочитать AI MEMO года примерно 1982 про Common Lisp с паскалевским pretty printer-ом, только под схему из коммон лиспа переделать.

Куда это всё пихать например в микроконтроллерах? Да и так в языке системного программирования неявная работа с памятью это плохо.

я по-другому понимаю: «язык системного программирования» – это, по идее, должен быть язык программирования систем (сверху донизу на этом самом языке или его над/под/мета множестве типа DSL из макросов в духе лиспа)

в этом смысле, если нужен какой-то ручной housekeeping такой сущности, как second class object доступной через указатели, контролируемую память и т.п. – то это костыли и велосипеды.

продумывание концепции first class object в лиспах привело к functional objects : goo, dylan, и прочий метаобъектный протокол.

хорошо на эту тему писал товарищ John Schutt про kernel и vau-expressions. как пример того самого, что мешает лиспу схеме стать полноценным лисп-1.

«все сущности, концепции, понятия языка равны – но всё же некоторые равнее»

например, несмотря на наличие гигиеничных макросов с syntax->datum и наоборот CST<->AST объектов, всё ещё не только лишь все классы объектов можно использовать и как входные и как выходные параметры значений данных типов-литералов.

например, в таком языке как CURL есть такое понятие как «документ-литерал» с динамическими переменными. в какой-нибудь Scheme (например, см. Pollen как LaTeX на Skribe на максималках, TheBeautifulRacket книжку про всё это) – этот «документ-литерал» вполне можно было бы сделать как гигиеничный макрос, FEXPR, динамический первоклассный объект-значение.

в общем-то, в реализации kernel от John Schutt этот недостаток практически исправлен – модуль это first-class object времени компиляции, first-class environment времени выполнения.

песочницы там элементарно реализованы – небезопасные функции импортозамещены пустышками.

в общем, исправляется фатальный недостаток lisp-1 схемы – не доделанная реализация first class objects.

в целом, для того чтобы её доделать на СTFE макросах придётся реализовать какое-нибудь управление памятью: сборщик мусора, пул объектов, контролируемую память limited типов и т.п.

так что этот housekeeping не так уж и прост: хотели просто банан, а нужно вытаскивать за него целую обезьяну и все джунгли.

Короче, кошмарно-непонятная и мутная эта штука – строка

обычный моноид с операцией гомоморфизма «конкатенация», ничего страшного :)

Угу.

обычный моноид с операцией гомоморфизма «конкатенацией» template в три этажа и программа готова.

видел, кстати, исходники игрушки типа Lunar Lander на SDL.

переписаны с ФОКАЛа на COBOL. обёртки к SDL реализованы на GNU COBOL.

так я вам скажу – этот КОБОЛище читается просто как песня!

почти объектно-ориентированный 4GL, лол

если на пятой странице выхлопа компиляции раскрытия шаблонов BOOST не уйдёт в бесконечную рекурсию , или стека под них не хватит :)

16к там было ПЗУ, а ОЗУ 48К, потом 128К (и около 4Мб в всяких клонах типа ATM-Turbo или ZS Scorpion – туда даже полноценный CP/M с RAM-диском устанавливали, винчестер, модем и ZX-Fido).

но оно же 8-битное. в ATM Turbo и далее, кажется, экспериментировали с Z80A 8..20Mhz, и кто-то Z80000 с сотнями мегагерц пытался подрубить, но там уже CP/M и далее, с совместимостью непонятно что.

и поскольку 8-битное – все эти выше 64к делались переключением страниц.

с плоской моделью памяти был более-менее продвинутый go32 и djgpp. но оно 32-битное, да. в целом, там и PE exe грузили, и DLL-ки, и какой-то недоделанный кусок полуоси, вроде бы :)

на аде есть MARTENS или как-то так испанского университета.

а вообще, вот посмотрел я на микроядро L4::Pistaschio, L4::Fiasco на C++. и кажется мне – они упорно изобретают абстрактную фабрику объектов ядра с ролевым мандатным доступом на основе Capabilities, завёрнутую в смартпоинтеры и прочие шаблоны шаблонов через шаблоны ради бога шаблонов на С++. на аде, наверное, можно было бы обойтись контролируемой памятью и всеми вот этими limited controlled – или переизобрести смартпоинтеры на ’Access а не ’address заново :))

а на unixhistory всё начиная с PDP-11 SVR1 как-то так минималистично начиналось…

.. авторы юникс изначального попытались исправиться, изобретя Plan 9 и далее Inferno – но было уже поздно, поезд ушёл (и их всё равно никто не слушал, как и Никлауса Вирта с оберонами)

открытое Zune из AROS, закрытое/шароварное MUI из Amiga на основе BOOPSI и ООП на обычном Си

для Xlib можно писать вообще на ассемблере голыми запросами поверх TCP/IP: раз два

а на русте под гтк можно

обычный моноид с операцией гомоморфизма «конкатенация», ничего страшного :)

gandjustas, ты? :)

Более того, в паскале, который человек приводит в пример, а современном, например, имеется четыре варианта строк, а так называемый string меняет свое поведение в зависимости от директив компилятора. А в бородатые годы они бы путались в string и pchar, или чем-то ещё.

Вообще, кмк, вся критика в адрес Си исходит в первую очередь от незнания предметной области.

Тут уже тред пошел в такие дебри и холивары, что я потерял нить противоборствующих сторон.

понять что такое k-мерный театр очень просто: «сначала представим себе k-мерный театр, а потом для наглядности, положим тривиальный случай: k=3» :)))

многомерный гиперкуб очень простая штука:

1)доказываем по индукции что такое n-мерный куб если понятно что такое (n-1)-ый

2)представляем себе абстрактный куб вообще (соответствующие узлы соединены через n-ортов)

3)вращаем себе wireframe в голове при n=3, n=4, n=5 ….

:)))

И что теперь? Будешь всё-таки начинать проект, или забъешь? Или не на Си?

нахуй той симейк если у нас есть обертка в виде платформио?

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