таки не полінувався, зайшов на ВПН

habr доступний без VPN:)

Перефарбувати вершину гори :)

Нові патерни проектування, впевнений, до сих пір розробляють.

Поки у нас фоннеймановські компʼютери — вони будуть не заміняти, а доповняти.

Прикол в тому, що то була не гра, а SaaS.

Непринципово. Коли підуть нові вимоги, стане ясно, куди рухатись. Але керування складністю завжди буде.

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

Або ви погано пояснили, що ж там не так було, або проблема принципової зміни вимог.

Це вже припущення. ;)

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

обробка приблизно така
— якщо прилітає зовнішній сигнал-команда який нас цікавить — виставляємо флаг (на який буде реакція потім десь в loop)

І знову, це принципово різні випадки (і те, що в Unix вони обʼєднані в один механізм сигналів — тут заважає і розумінню, і, може, обробці).

Асинхронні сигнали на зразок SIGTERM, SIGINT, SIGIO, SIGUSR1/2, вся RT-група і не тільки — їх обробляти має сенс, для більш-менш складних програм, як раз тим чином, що ти описав: просто налаштувати канал прийому повідомлень і читати його. Це може бути зроблено декількома варіантами:
1) Традиційні обробники, ставлять флаг (типу sig_atomic_t) і виходять, і більш нічого не трапляється. Десь вже нагорі флаг регулярно перевіряється.
2) Сигнал замаскований, в циклі перевіряється, що прийшло, через sigpending().
3) signalfd (Linux), EVFILT_SIGNAL (BSD) ловлять факт сигналу в формі, придатної для mass poll форми.

Можна, звісно, і робити терміновий вихід з того коду, що зараз працює, але чим складніше програма і її дії, тим менш імовірно, що це буде з нагоди.

А ось синхронні події, такі, як доступ по невалідній адресі, вимагають обробки в тій нитці або корутині, де вони стались, і для них саме розмотка по стеку є найбільш природним підходом. А відкладати її в принципі не можна.

І ось тому для синхронних — якщо взагалі програма має вижити, то це або longjmp(), або SEH — принципово вони роблять одне і те ж. А ваш приклад з циклом в принципі не має відношення до цього.

Повторюсь, поєднання цього в одному механизмі було не зовсім адекватною ідеєю, і це збиває з пантелику.

мабуть булоб краще сказати

А так завжди. Хтось просто каже «не використовуйте goto там, де можна написати розгалуження через if або цикл через while, for; не стрибайте в середину циклу або блоку під if, якщо це не один cleanup на всіх», і це нормальна робоча порада. А хтось буде волати раненим вовком «кожний goto це злочин, вбивати на місці». І от других я не підтримую.

Чи є в цій мові обовʼязкові атрибути ООП мови, на кшталт декларації класів?

Нема. Що далі? Якщо ви вважаєте, що від цього в ядрі нема ООП, ви помилились.

Дуже просте запитання. Два.

Які не мають жодного відношення до дійсности.

то можемо легко упоротися та дійти до висновку, що HTML — це ООП мова програмування.

Програмування — ні. бо нема коду. Опису — коли будуть довільні теги і атрибути. Тобто HTML — ще ні, XML — да.

Ви впали в демагогію, значить, аргументи кінчаються.

Є купа підходів в не-ООП мовах програмування, які можуть вважатися за такими, що схожі на класичні ООП-шні.

Важливо не яка мова, а як написана програма. Мова тут може дуже допомагати, частково допомагати, хоча б не заважати, частково заважати, сильно заважати.
C частково заважає, але все одно писати на ньому в ООП можна і часто де треба.

Для порівняння: на JavaScript писали задовго до класів в ООП стилі навіть з реальною інкапсуляцією (чого C не дає).

Але тоді можна так само сказати, що ООП це трохи ускладнена процедурщина.

В мінімальних формах так і є. В серйозних розділення на сутності, привʼязка коду і даних до них, барʼєри доступу до не-свого (інкапсуляція), інші ідейні компоненти ООП переводять на новий якісний рівень, після якого «процедурщина» стає абсолютно неадекватним означенням.

Я разве обещал, чтобы lynx (речь про него? или про links?) показывал сайты с жабаскриптом?
Ваши слова про «пока последний юзер не умрёт?» — вот и отвечайте за них.

За такую стоимость вы и на винде это можете делать

Не могу. Просто отказываются разговаривать.

но вам же хочетцо нахаляву

А это из какого пальца высосано?

Встановлення Linux — це москальська рулетка. Може все стати з коробки, а може навіть до башу не завантажитись (реальна історія, доречі).

З віндою те ж саме і більше. Але за тебе зазвичай все це вже зроблено, всі граблі знешкоджені, тим, хто продав лаптоп.
З самозбірним десктопом вже не так, я теж «не дійшов до стартового екрану» з віндою бачив багато разів. Але у випадку вінди, щоб зрозуміти, що не так, треба набагато вищу кваліфікацію, ніж з Linux.

Я лаптопи купляю такі, про які сказано, що на них Linux. Часто на них реально лінуху немає (це часто у Acer), але сучасна йому убунта встає без проблем.

Але якщо використовуєте професійний софт, то він увесь під вінду only. Від Фотошопа до Альтіума.

Для помітної частини такого софту — да, на жаль. Але є і зворотні приклади.
А якщо треба не просто комп з мережею і спец. софтом, а так, щоб він ще і якесь специфічне приладдя підтримував — то зараз співвідношення в зворотню сторону, вінда пролітає далеко і надовго, бо ніхто не хоче морочитись з ліцензуванням.

Саме тому, що треба правильно описати кожен з обʼєктів, кожні взаємовідносини, систематизувати все та зробити хоча б трохи універсальним. Це вимога ООП.

«Хоча б трохи універсальним» автоматично зробиться з будь-якої спроби вирішення задачі. Але, якщо не впадати в режим FizzBuzzEnterpriseEdition, воно буде максимально простим.

Здається, ви навмисно плутаєте просто ООП і спробу максимувати рецепти типу SOLID навіть на мінімальній задачі.

Кожен з субʼєктів є незалежною системою, яка самостійно приймає «рішення». Та є просто обмін сигналами між цими системами з урахуванням структур.

І це є теж ООП, проте типу «активні обʼєкти», воно ж імені Алана Кея, а-ля Simula і Smalltalk (тобто раніше ООП на пассивних обʼєктах, стиля C++). Але воно не обовʼязково буде простішим.

втомився його вже приводити

Ну і для чого ви втомились, коли це реально нічого не показує, крім того, що ви не знаєте, що таке ООП? 🤷‍♂️

то логічно повісити обробку signal з jump куди треба по ідеї (imho)

Логічно її вішають саме туди, де був би try.

if (setjmp(buf) == 0) {
  // try block
} else {
  // catch block
}

А яка і чому потрібна альтернатива?

Не за адресою: я не лаю за посилання на хабр чи навіть на аналог у хамаса.

що окремі обʼєкти це часто дуже малі блоки.

Ну, розмір обʼєктів визначається декількома факторами: необхідністю мати границю через принципове розділення (Страуструп — літак не може бути наслідником двох його двигунів), логічне за рахунок information expert + high cohesion (а інфоциган Мартин зводить в SRP), і оцінка незалежности аспектів реалізації (часто штучна). А, ще повністю штучні посередники через dependency injection.
Якщо використовуються по більшости природні фактори, то не буде надто малих обʼєктів.

Тоді визначення ООП це одна єдина фіча: вказівник на функцію.

На яку з? Я цього не зрозумів. Якщо мова про факт виклику віртуальної функції через вказівник, може бути інший варіант. Я бачив ООП з віртуальними функціями на bash, коли виклик йшов по імені. Але навіть це не однозначна ознака.

Якщо читати Греді Буча, то наслідування реалізації він вважав обов’язковою ключовою рисою.

Є визначення за Граді Бучем.
Є за Аланом Кеєм.
Є ще за кимось.
Варіант Буча зрозумілий, але він занадто орієнтований на конкретний стиль. Я підтримую цей стиль (і вважаю спроби його заборонити, як в Go, марними), але і те, як роблять те ж ООП в інтерфейсі ядра, теж має право на існування.

До речі, я взагалі вкрай мало чую про Граді Буча після ≈2005 року. Якось його наробки вийшли з масової уваги.

Це не стандарт, не кажучи про те, що Microsoft C не підтримує останні стандарти, просто незрозуміла іграшка.

На жаль, да, інші цього не підтримують.
Але не «іграшка». У MS C є одна колоссальна перевага: він не ганяється за тим, щоб заради 2% в нікому не потрібному синтетичному тесті використати ще десяток UB там, де програмісти найменш цього чекають. Вони навіть SSA ввели тільки у 2015-му.

Це інша функція, більше комунікація.

Не плутайте асинхронні сигнали як SIGTERM з внутрішними синхронними, як SIGSEGV. (Їх взагалі не слід було обʼєднувати в один механізм.)

Якщо краще потім оптимізується компайлером

Ні (або я таких не бачив).

чи читається в цілому

Більшости — ні.

Більш цікавий випадок то longjmp.

А в чому різниця з try-catch?

все неправильно, та новина мала б бути першою саме на цьому сайті й з посиланням на оригінальні англомовні джерела...

Ну ось і почни. Де твої новини? В критиканство ми всі вміємо.

(ніколи у цьому контексті не скажеш книга лежить на столі)

Якщо мова з самого початку йшла про цю книгу, то її поставлять на перше місце.

Ти природньо ставиш визначене на початок, невизначене у кінець.

І це не артиклі як частини мови або члени речення. Це саме порядок слів. Ця манера іде ще з загальної індоєвропейської, де теж артиклів не було (і взагалі як для нас була дуже дивна, там складних конструкцій, по типу object clause, в реченні взагалі не могло бути, слова в реченні були всі незалежні і розташовувались в порядку зменшення значення в висловлюванні... але це окрема тема).
І тут не визначене/невизначене. Тут є типовий порядок і нетиповий. Те, що ви сказали про «невизначене», це те, що пікреслюється як нова або принципова інформація. Підкреслення може бути зроблено зміною порядку, а може і інтонацією («Я те́бе кохаю» і «те́бе я кохаю», «я́ тебе кохаю» і «тебе я́ кохаю»). Не можна тут спрощувати.

Англійська майже не має зараз вільного порядку слів і таких інтонацій, і вони компенсують або довгими описами («Thatʼs me who loves you!»), або артиклями. (І не тільки вона, артиклі це типова риса десятків мов.)

Глобальна мітка cleanup де очищується все тимчасове, що нароблено в функції. Альтернатива у вигляді дуже уважного контролю, в якому з return треба на що сказати free, де повернути старе значення і все таке, зламається максимум на пʼятому параметрі, почнуть забувати.
(C++ вирішує це через RAII, Go — через defer, в обох випадках рахує дії вже компілятор.)
Розширений приклад: тут.

Вихід з другого і глибше вкладеного циклу, до сих пір в мові нема тегованих циклів і відповідно break/continue по тегу. Звісно, можна нарожати bool-флагів з перевіркою в умові циклу, і ifʼов в тілі, але навіщо?

якось не задумувався над тим, які трейдофс з тим можливі?

Зараз, мабуть, ніяких, всі можливі недоліки вже пророблені.

В реалізації win32 була ціна на утримання стекового фрейма на кожну функцію, яка хоч якось обробляє винятки. В win64 замінили на табличний пошук, для якого лінкер генерує дані. Це складно, згоден, але все вже вироблено.

В Unix та ж задача була вирішена в ті ж часи в рамках C++, зі схожими підходами (sjlj-exceptions замінені на table-based), тобто код є, зневаджений, треба лише його прилаштувати.

Перевести синхронні винятки, викликані кодом, як то SIGFPE (ділення на 0), SIGSEGV (некоректна адреса памʼяти) і все таке — тривіально. Можна це робити викликом для конкретної нитки. Асинхронні, що приходять з інших ниток/процесів — тут треба подумати, включати чи в той же механізм, але спішити нікуди.

А ось переваги у вигляді поєднання всіх стилів обробки винятків тут можуть бути дуже смачними.

GTK підхід віднесемо до складних задач?

Да.

бо хтось вбачає там деякі OOP властивості на далеких відстанях, хтось ні.

Воно там є. Але реалізація на C вимагає glib-них трюків, після яких комусь таки може здаватись, що ООП нема.