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

что конкретно из этой архитектуры нашло отражение в систаксисе языка Си

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

каким бы получился Си если бы его писали с прицелом на архитектуру, >скажем, Z-80

Я думаю что плюс-минус таким же так как у Z-80 были примерно те же ограничения по памяти.

утопите в величии вашего интеллекта

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

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

Ради восстановления справедливости замечу что Ада тоже позволяет - если написать явное приведение типов. Точно также как в Си надо написать явное приведение типов для того чтобы избежать обрезки результата. То есть симметрично-противоположное поведение по умолчанию. И умолчание Ады мне нравится намного больше чем умолчание Си.

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

https://c-faq.com/misc/sd26.html

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

Забористо!

Обрезанная цитата действительно выглядит «забористо». Можно еще обрезать до «ассемблером на стероидах Си делает возможность структурного программирования» - будет еще глупее.

Напомню, что полная фраза была такая:

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

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

mov reg_int, int1
add reg_int, int2
mov long1, reg_int

То есть когда мы пишем на Си long1 = int1 + int2; И используем архитектуру x86 мы понимаем что получится примерно вот то что выше (возможно с поправкой на возможные виды адресации операндов).

PharLap DOS Extender - да, кровушки попил изрядно.

Причем их был два разных варианта. Один работал только на 386+ и действительно был капризным,конфликтовал с чем угодно и имел совершенно неинтересную «плоскую» модель памяти (как сейчас в линуксе). А вот второй встречался намного реже (может потому что стоил 495 баксов), работал и на наиболее распространенных тогда 80286, и имел вот те интересные штуки с сегментами и «внутрипрограммной» защитой которые я выше упоминал.

результат молча обрезается при присваивании overflow и conversion.

Занялся проверкой как ведут себя -Woverflow и -Wconversion. Оказалось, conversion в моем кусочке кода срабатывает не на сложение двух интов,а на присваивание i=0xFFFFFFFE. Типа это будет не большое положительное число,а маленькое отрицательное. Логично,но несколько не то что я искал. А overflow ни на что вообще не срабатывает.

Строчка вида long1 = int1 + int2 по-прежнему проглатывается молча. Так что я рано обрадовался.

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

и долго он проработает без сборщика мусора?

Куда-то же пихали в ZX-80

Самое смешное что си туда впихнуть даже в 48 килобайтную версию нормально не получилось, компилятор занимал почти всю память, на сотне другой (или скорее даже меньше, уже не помню) строк уже вылетал с переполнением памяти и выдавал очень медленный код. Понятно что кое-что можно было улучшить добавив дисковод и компилятор от CP/M, но код все равно очень плохо оптимизированный получался. Так что на синклере нормально было только под бейсик + асм.

дак его никто и не собирался прибивать. https://github.com/ziglang/zig/issues/16270

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

выделят в независимый пакет, и все.

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

Логика не моя,а создателей стандарта и компилятора языка ADA. Там этой глюкофичи нет.

Да интересно, но тем кто имел дело с другими языками как-то контринтуитивно. В rust например просто тупо запретили неявное приведение типов и всегда приходится явно приводить, по моему это самый надежный вариант.

В верилоге размер тоже определяется по левой части (там немного сложнее, на самом деле, но это не важно).

long1 = int1 + int2

Я кстати не вижу тут ошибки. long (если речь всё-таки о LP64) вместит в себя два int, как бы ты не старался.

А она есть. Можешь проверить.

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

тем кто имел дело с другими языками как-то >контринтуитивно.

Да я не против,пусть так будет если это кому-то удобно. В отличие от кое-кого кому лень лишний #include написать,мне не лень написать приведение типов. Но предупреждение-то можно же выдавать! Хотябы на самом максимальном уровне «параноидальности». Или предупредить gcc всё-таки может,но не знаем как это включить? -Wconversion и -Woverflow не помогло.

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

Так бейсик же в ПЗУ был зашит и ОЗУ не занимал. А сишный компилятор приходилось в ОЗУ грузить. Понятно что места ему не хватало. Под такие компы надо кросс-компиляцией собирать на чем-то большом. Внутрь микроконтроллеров(с примерно такими же ресурсами) компилятор Си тоже ведь не пихают. Но пишут под них именно на Си.

Я кстати не вижу тут ошибки. long (если речь всё-таки о LP64) вместит в >себя два int, как бы ты не старался.

Вот именно что не_видите! А она будет,как минимум на х86-32,причем и в Си (проверял в трех компиляторах) и в Паскале (от Borland точно).

А происходит действительно неочевидная вещь - инты складываются, не влезшее в размер int обрезается, и этот обрезаный результат присваивается long. Причем всё это происходит БЕЗ ПРЕДУПРЕЖДЕНИЙ даже в gcc с -Wall.

Естественно, хочется сделать «красиво, модно, молодёжно» и удобно.

Убийца ли C язык C3?

но вот написали сетевой стек на го в фуксии. Итог такой что фуксия >осталась недоосью и обещания переписать на си

Умел бы я писать операционные системы - написал бы на ADA. Но я абсолютно не представляю как один человек (Линус) смог написать аж целое работоспособное ядро. Не потому что я не представляю как оно работает,а просто в силу объема кода. Даже если я просто буду сочинять просто русский текст то я за день(ну или ночь) максимум полсотни килобайтов наколочу. Программный код сочинять сложнее,да еще и проверять работоспособность сочиненного потом надо.

А можно вопрос к присутствующим тут профессиональным программистам: сколько килобайтов сишного кода может написать и более-менее заставить работать настоящий программист ну допустим за восьмичасовой рабочий день? (ну или ночь - кому как удобнее:)

Убийца ли C язык C3?

Увы - новый язык может быть сколько угодно хорошим, но проблема в том что накопленный за много десятков лет объем написанного на Си кода такой что переписать его на что-то другое уже не реально. Сколько там десятков мегабайтов уже исходники одного только ядра Линукса занимают? А ведь кроме ядра еще и огромное количество библиотек, используемых прикладным софтом. У меня на домашнем компе с достаточно минималистичной системе (без всяких «сред» типа KDE) каталог /usr/lib занимает пять гигов - и это в скомпилированном виде. Скольо это в исходниках - подумать страшно. И большинство из это написано на Си. По-моему переписать это способен только искусственный интеллект,когда научится не делать ошибок.

переписать его на что-то другое уже не реально

А зачем? ТС хочет начать новый проект.

LP64

Для тебя и Werenter я это специально уточнил.

LP64 Для тебя и Werenter я это специально уточнил.

Эту аббревиатуру я видел применительно к IBM AIX. Живьем его щупать не приходилось, так что не знаю проявляется ли там вышеупомянутая глюкофича. Если там её нет - значит она еще и системозависима. Что делает её только еще более неприятной.

LP64 это модель данных, это не что-то AIX специфичное.

Но я абсолютно не представляю как один человек (Линус) смог написать аж целое работоспособное ядро

Это несложно, я сам это делал много раз в первой версии ядра (0.0.1) было 10 тыс строк. Несколько месяцев работы.

Я когда-то давно делал типа ОС для микроконтроллеров. Тоже тыщ 15 строк получилось в первой версии.

пакетные менеджеры (а они вообще есть?)

-dev (-devel) пакеты из дистрибутивов, собственно

А выигрывателей достаточно?

Куда еще их, и так полно этих ничего не умеющих плееров. Что еще нужно, когда уже есть QMMP, Deadbeef и Sayonara?

Что еще нужно

Музыкальный проигрыватель на чистом си.

с теплым ламповым звуком

mpv же.

Легаси. Нужно что-то новое.

Нужно что-то новое.

Я уже как-то говорил,что всё «общеупотребительное» что может написать один человек - за последние три десятка лет уже написали. Если чего-то под линуксом и нет то это что-нибудь узкоспециальное. Чтобы это написать - нужно быть не столько программистом,сколько специалистом в прикладной области. А так как такие спецы обычно не владеют ультрамодными технологиями программирования - то для них нужны достаточно простые инструменты. В первую очередь инструменты,позволяющие написать к своей программе пользовательский интерфейс. И монстрообразные библиотеки типа QT не подходят из-за черезмерного уровня сложности. Я там выше по тексту не просто так XForms упоминал. Интересно - есть ли что-то еще подобное?

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

Чтобы именно из Си без плюсов можно было использовать.

https://www.tecgraf.puc-rio.br/iup/?

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

С этой точки зрения XForms лучше так как работает поверх вполне стабильного xlib.

Смутила только зависимость от GTK или Motif

Тогда https://github.com/Immediate-Mode-UI/Nuklear, наверное.

Nuklear, наверное.

Спасибо, поизучаю. Не видел раньше этой штуки.

MOPKOBKA его часто использует, может ещё чего посоветует.

Пишут, но только ембед.

Я уже как-то говорил,что всё «общеупотребительное» что может написать один человек - за последние три десятка лет уже написали.

Очень сомнительный тезис.

Очень сомнительный тезис.

А чего еще не написали не слишком узкоспециального? И при этом такого,что в принципе может осилить один человек.

Ну вот tig намного медленнее, чем gitui на Расте.
Предполагаю, что из-за неиспользования libgit2.

Я уже неоднократно предлагал написать простенький, как глоток водки морозным январским утром, трёхмерный редактор. С низким порогом вхождения для условной домохозяйки, которой что-то смоделировать нужно раз в полгода. Чтобы домики набигали можно было натаскать шариков, кубиков, стен, текстур и прочего из панели инструментов и расположить в пространстве (вот сделать последнее наглядно, кстати, не очень тривиальная задача). Блендер не то, его надо осваивать, и если его освоить, что-то сделать и забросить на полгода — осваивать придётся заново.

Ну и оценивать тезис «всё уже написано» надо с точки зрения, что разнообразие — это хорошо. К сожалению, многие линуксоиды считают, что если есть GIMP, значит, все растровые редакторы уже написаны. Между тем растровый редактор тоже можно сделать простеньким, заточенным под потребности человека, которому иногда нужно что-то порезать склеить и пририсовать поясняющий кружок с надписью. В гимпе это можно сделать, но совершенно неочевидным для того, кто в нём работает не каждый день, образом. К примеру, когда мне там потребовалось попиксельное рисование, мне сначала пришлось гуглить, как показать сетку, а потом гуглить, как задать размер карандаша в пикселях. Причём если первое я не нашёл, в общем-то, по недостатку упорства, то второе я без гугла бы искал вообще до второго пришествия. А было бы неплохо, чтобы для такой элементарщины гугл вообще был не нужен. Вот ещё одна задача — простой растровый редактор.

Всё написанное не означает, что GIMP и Blender плохи. Нет, просто оба они для тех, кто в них работает ежедневно.

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

Какой хитрый, аднака.. 😀

Да мне не жалко советами человека забросать. :)

man apropos (ну или man man)

https://misra.org.uk/misra-c/

К сожалению, многие линуксоиды считают, что если есть GIMP, значит, все >растровые редакторы уже написаны.

Да, сталкивался с таким. И даже не пытаются поискать что написано еще. А оно есть.

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

Именно так его обычно и использую. Художественных шедевров в нем не создавал ибо талантом не обладаю. Неудобства возникают только когда в очередной версии меняют интерфейс. Но я понимаю что делается это в угоду требованиям художников,работающих в нем ежедневно. А я могу и потерпеть создаваемые этим неудобства. Но если кому-то Gimp особо сильно не нравится то есть немало и других редакторов https://pingvinus.ru/programs/graphics/imageeditors Вы точно всё это попробовали и совсем ничего вам не подошло?

трёхмерный редактор.

В этой области я не силен так что особо спорить не буду. Когда мне потребовалось сделать модель гребного винта для самодельного лодочного мотора с целью последующей передачи ее в печать на 3д принтере - я за несколько дней написал её в OpenSCAD. Конечно,почитав перед этим документацию. И трехмерные редакторы тоже одним blender не ограничиваются: https://pingvinus.ru/programs/graphics/3d-modelling

Другое дело что о gimp и blender слышали все,а о других редакторах мало кто знает если специально не гуглил. Но это не значит что их нет. В больших дистрибутивах линукса вообще много чего есть такого о чем мало кто знает.

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

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

Ну вот tig намного медленнее, чем gitui на Расте.

Намного - это насколько в секундах? И так ли эти секунды критичны?

Вы точно всё это попробовали и совсем ничего вам не подошло?

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

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

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

Молодец.

Когда использую download master, 7z, ... всегда приходит мысль - какие же они молодцы.