Имхо, достаточно было бы в Си добавить средства, облегчающие организацию VMT, и на этом стоило бы закончить.
VMT - раз. private - два (надо же защищать от внешнего неавторизованного доступа). namespaces - три (есть тут у меня один компонент, названия типа rrx_sub_trr_pkt_new задалбывают).
Вот уже именно что языковые средства и 1/5...1/4 от C++ уже есть.
И что странного в зашивке в язык, если там всё равно уже зашито 100500 всего начиная с типов, а это конкретно - используется очень значительной частью софта?
Ну я только по Киеву могу показать: улицу, где несколько километров исторически вырезаны (а сейчас частично восстанавливают); улицу, которая формально так пересекается с собой несколько раз (а реально там промзона, в которой было всем плевать, что за улица, знали объекты) и тоже порвана на части; две улицы с двумя рукавами (одна тоже в промзоне, вторая в частном секторе); одинаковые названия в разных частях города, так что требуется уточнение районом.
Но всё это по сути требует одного - разделения названий. Если есть перекрёсток - или надо одной из улиц дать другое название, или если она слишком короткая - применить общий принцип для длинной улицы, а короткую назначить местным проездом. Я бы выбрал первое.
[1. С семейством m68k надо сравнивать 80386 и далее, а не 8086. Защита памяти появилась в 80286, но не страничная. В линии m68k она появилась не в 68000, а в 68010, а это уже 1982 - то есть он ровесник 80286; но у 68010 это требовало внешнего MMU, решение было не из дешёвых (тогда). 68020 аналогично требовал внешнего MMU. Только с 68030 они смогли впихнуть MMU внутрь, а это уже 1987, через два года после 80386.
2. Неортогональность по регистрам в 32-битном режиме x86 значительно снижена - именно там, где она била больше всего (режимы адресации). То, что она остаётся и сейчас в вариантах типа косое умножение с результатом в xDX:xAX, переменный сдвиг в CL - ни на что реально не влияет.
3. У m68k нет полной ортогональности по регистрам. Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра. К A-регистру нельзя добавить произвольную константу. ADDx (аналог ADC) не работает на A-регистрах. То же про битовые операции. Однобитовые операции типа BFCHG не разрешены почему-то для режимов типа (An)+. Когда вы говорите
ортогональная к регистрам, очень логичная система команд
вы почему-то игнорируете все эти тонкости и нелогичности.
4. Зато есть безумные двойные косвенные режимы типа ([bd,An],Xn,od). Именно они убили всю архитектуру: перевести их на out-of-order исполнение оказалось просто невозможно, причём не технически, а административно: кто-то постановил, как именно в каком порядке они проходятся, для возможности восстановления с любой промежуточной точки. X86 как более примитивный таки избежал этого.
Мне, конечно, нравятся некоторые аспекты m68k, но именно из-за описанного в конце не считаю её настолько лучшей. Мнение типа "m68k была заведомо лучше x86" - это чистый туман размытых воспоминаний, подкрепляемый фанатичными ненавистниками x86. Я пытаюсь быть объективным:)
Тут следует упомянуть, что самые первые IBM PC могли поставляться вообще с 16KB памяти, и на 1981-й это ещё стоило примерно 100, на персональный компьютер - нереально). А на потом думали вообще сменить архитектуру. Проблема в том, что, условно, MS-DOS задержался на десять лет по сравнению с тем, что ожидали (в заметной мере, в своих наполеоновских планах) авторы железа, программ, журналисты и прочие, и, несмотря на то, что адресация далее 1MB была уже в 80286, массовое переписывание кода на новый стиль стало быть позволено уже только в середине 1990-х. Вот об этом бы почитать подробнее, каким образом и почему индустрия впала в такой заклин.
микропроцессоры Motorola были лучше, чем интелловские
В плане адресации - да. В остальном - нет. Когда пришла возможность делать out-of-order исполнение, для десктопных процессоров это начало 1990-х, линия m68k умерла потому, что была over-CISC в массе деталей, как именно исполняется команда, какое количество и сложность режимов адресации, и введя эти детали в спецификации своего ISA. А у x86 такого ограничения не было. По тому, например, что в командах (кроме строковых и всяких служебных) не более одного операнда в памяти, она оказалась ближе к требуемому в новые времена (RISC) и потому выжила. Конечно, правительство этому помогло (см. историю про ASCI Red), но это лишь ускорило на несколько лет неизбежную смерть m68k. А у x86 к тому времени был отлаженный 32-разрядный режим.
(Кстати, почему только 16MB? Адрес 32-разрядный, значит, наступал период обновления. Немного раньше S/370 прошла этот путь, 370/XA расширило адрес с 24 до 31 бита. И там было много граблей в первую очередь с софтом, пришлось добавлять режим 24-битной адресации для старого пользовательского кода, а ядерный пришлось массово переписывать, где он зависел.)
Если вы считаете какой-то код ООП, а кто-то другой не считает его таковым, результат выполнения кода от этого никак не поменяется, равно как не поменяются метрики выполнения кода такие как время, потребление памяти и т.д.
Поменяется то, что будут или хотя бы захотят делать при развитии и сопровождении кода. Странно, что вы это не учитываете, а код рассматриваете в статике, как высеченный в мраморе.
Но я могу вам задать вопрос с ещё более крутым подвохом: если взять процедурный код, в котором нет ни одного класса, и все его функции сделать статическими методами классов. Будет ли это ООП?
Я считаю, что нет, и нет разницы с моим вопросом. Классы тут будут играть роль пространств имён. Но это может быть предварительным шагом перед созданием уже реально ООП кода.
А потом улицу решили продлить, от "начала улицы" дальше построили еще несколько домов. Какие им номера давать? Отрицательные?
А вы что предлагаете? Давать им случайные незанятые номера, чтобы окончательно потом все запутывались?
Нормальный подход - новому куску дать другое имя. Это однократная проблема, в отличие от прочих вариантов, когда люди будут мучаться десятилетиями.
А еще бывает топографический объект "Площадь". У нее от центра расстояния до домов могут быть одинаковы, поэтому нужно учитывать угол. Здесь явно номера напрашиваются комплексные.
Да, для площадей нужно уточнить это правило. Но и в этом случае надо делать по расстоянию (например, по внешней границе территории собственно площади).
Если код сам по себе полностью процедурный без единого класса, но использует библиотеку, в которой создаются объекты и зовутся их методы - это считать ООП?
Смешно тут то, что авторы таких утверждений не понимают (или не хотят признавать), что Linux, и ядро любого Unix, и ядро Windows - они все на ООП как раз классического пассивного, не-Кеевского типа. Полиморфизм на виртуальных функциях - в полный рост. Уровень сисколлов: есть универсальный read() на всех, write(), close(), fcntl(), вплоть до epoll и io_uring, ко всем применяются одинаковые методы для большинства работ, внутри происходит переключение. В реализации read(), например, ret = file->f_op->read_iter(&kiocb, &iter); - f_op это Virtual Method Table.
Инкапсуляция делается только на границе user land / kernel land, да. Но это ограничение языка. Был бы даже очень урезанный C++ - всякие private и protected были бы везде. А пока следят на уровне верификации кода (начиная с визуальной).
Наследования в явном виде очень мало, да. Например, в иерархии обработки ioctl: есть общие для всех вообще дескрипторов, есть для терминалов, есть для последовательных портов, которые тоже терминалы, реализация чисто через код. Остальное неудобно делать. Но и без него достаточно.
Так что вы с этим
Конечно, в ядре Linux не до полиморфизма
неправы, Linux ещё больше играет за вашу же команду: ООП нужен - там, где удобен.
(Повторюсь) сокращение - не проблема. Ну стали нумероваться с 81 вместо 1, зато принцип расстояний соблюдается, вместе с монотонным возрастанием номеров в ходе движения. А не так, что, например, идут 3,5,7,9, а потом вдруг 3а.
Тут в описании пропущено существенное, согласен. Сначала надо найти точку посредине проезжей части улицы, к которой данный объект (наиболее важное место его доступ, типа крыльца или ворот, если нет - то самая выделяющаяся) ближе всего, затем считается расстояние от этой точки до начала улицы (плюс какая-то константа, заданная в паспорте этой улицы), и наконец расстояние проецируется на пространство номеров (например, делится на 10 метров и дальше округляется до ближайшего чётного или нечётного номера, согласно стороне). Погрешность в несколько метров и пару процентов несущественна, пока нет нумерованных в обратном порядке. В случае, если несколько объектов получили бы один номер, добавляем буквы, как сейчас принято.
А это неважно. Главное, чтобы номера были не меньше, если какой-то запас и нумерация начинается, например, с 19 и 20 - не страшно, у нас целых чисел на всех хватит.
Удлинение улицы с её формального начала - редчайший случай. Скорее в таком случае кусок называют другим именем. Укорачивание ничего не меняет. Разрыв - тоже. В предполагаемом варианте я допускаю добавление константы к номерам, общей на всех, поэтому если улица начнётся с номеров 251/252 - ничего плохого, если дальше будет увеличение по расстоянию.
В любом случае это лучше того бардака, что сейчас почти везде.
Ничего из описанного вами не является причиной для падений. Кстати, аддонов у меня там нету.
Аналогичные периоды падений были и раньше, как-то прекращались. Видимо, метод тестирования на живых пользователях разработчикам хрома нравится не меньше, чем мелкомягким.
VMT - раз.
private - два (надо же защищать от внешнего неавторизованного доступа).
namespaces - три (есть тут у меня один компонент, названия типа rrx_sub_trr_pkt_new задалбывают).
Вот уже именно что языковые средства и 1/5...1/4 от C++ уже есть.
И что странного в зашивке в язык, если там всё равно уже зашито 100500 всего начиная с типов, а это конкретно - используется очень значительной частью софта?
Ну я только по Киеву могу показать: улицу, где несколько километров исторически вырезаны (а сейчас частично восстанавливают); улицу, которая формально так пересекается с собой несколько раз (а реально там промзона, в которой было всем плевать, что за улица, знали объекты) и тоже порвана на части; две улицы с двумя рукавами (одна тоже в промзоне, вторая в частном секторе); одинаковые названия в разных частях города, так что требуется уточнение районом.
Но всё это по сути требует одного - разделения названий. Если есть перекрёсток - или надо одной из улиц дать другое название, или если она слишком короткая - применить общий принцип для длинной улицы, а короткую назначить местным проездом. Я бы выбрал первое.
[1. С семейством m68k надо сравнивать 80386 и далее, а не 8086. Защита памяти появилась в 80286, но не страничная. В линии m68k она появилась не в 68000, а в 68010, а это уже 1982 - то есть он ровесник 80286; но у 68010 это требовало внешнего MMU, решение было не из дешёвых (тогда). 68020 аналогично требовал внешнего MMU. Только с 68030 они смогли впихнуть MMU внутрь, а это уже 1987, через два года после 80386.
2. Неортогональность по регистрам в 32-битном режиме x86 значительно снижена - именно там, где она била больше всего (режимы адресации). То, что она остаётся и сейчас в вариантах типа косое умножение с результатом в xDX:xAX, переменный сдвиг в CL - ни на что реально не влияет.
3. У m68k нет полной ортогональности по регистрам. Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра. К A-регистру нельзя добавить произвольную константу. ADDx (аналог ADC) не работает на A-регистрах. То же про битовые операции. Однобитовые операции типа BFCHG не разрешены почему-то для режимов типа (An)+. Когда вы говорите
вы почему-то игнорируете все эти тонкости и нелогичности.
4. Зато есть безумные двойные косвенные режимы типа ([bd,An],Xn,od). Именно они убили всю архитектуру: перевести их на out-of-order исполнение оказалось просто невозможно, причём не технически, а административно: кто-то постановил, как именно в каком порядке они проходятся, для возможности восстановления с любой промежуточной точки. X86 как более примитивный таки избежал этого.
Мне, конечно, нравятся некоторые аспекты m68k, но именно из-за описанного в конце не считаю её настолько лучшей. Мнение типа "m68k была заведомо лучше x86" - это чистый туман размытых воспоминаний, подкрепляемый фанатичными ненавистниками x86. Я пытаюсь быть объективным:)
Тут следует упомянуть, что самые первые IBM PC могли поставляться вообще с 16KB памяти, и на 1981-й это ещё стоило примерно 100
, на персональный компьютер - нереально). А на потом думали вообще сменить архитектуру. Проблема в том, что, условно, MS-DOS задержался на десять лет по сравнению с тем, что ожидали (в заметной мере, в своих наполеоновских планах) авторы железа, программ, журналисты и прочие, и, несмотря на то, что адресация далее 1MB была уже в 80286, массовое переписывание кода на новый стиль стало быть позволено уже только в середине 1990-х. Вот об этом бы почитать подробнее, каким образом и почему индустрия впала в такой заклин.
В плане адресации - да. В остальном - нет. Когда пришла возможность делать out-of-order исполнение, для десктопных процессоров это начало 1990-х, линия m68k умерла потому, что была over-CISC в массе деталей, как именно исполняется команда, какое количество и сложность режимов адресации, и введя эти детали в спецификации своего ISA. А у x86 такого ограничения не было. По тому, например, что в командах (кроме строковых и всяких служебных) не более одного операнда в памяти, она оказалась ближе к требуемому в новые времена (RISC) и потому выжила. Конечно, правительство этому помогло (см. историю про ASCI Red), но это лишь ускорило на несколько лет неизбежную смерть m68k. А у x86 к тому времени был отлаженный 32-разрядный режим.
(Кстати, почему только 16MB? Адрес 32-разрядный, значит, наступал период обновления. Немного раньше S/370 прошла этот путь, 370/XA расширило адрес с 24 до 31 бита. И там было много граблей в первую очередь с софтом, пришлось добавлять режим 24-битной адресации для старого пользовательского кода, а ядерный пришлось массово переписывать, где он зависел.)
Можно - в режиме live coding. Но это потребует более высокого уровня интервьеров.
В смысле, отрицатели ООП - плоскоземельщики? Полностью согласен 😆
Давайте без таких излишне полемических приёмов.
Поменяется то, что будут или хотя бы захотят делать при развитии и сопровождении кода. Странно, что вы это не учитываете, а код рассматриваете в статике, как высеченный в мраморе.
Я считаю, что нет, и нет разницы с моим вопросом. Классы тут будут играть роль пространств имён. Но это может быть предварительным шагом перед созданием уже реально ООП кода.
А вы что предлагаете? Давать им случайные незанятые номера, чтобы окончательно потом все запутывались?
Нормальный подход - новому куску дать другое имя. Это однократная проблема, в отличие от прочих вариантов, когда люди будут мучаться десятилетиями.
Да, для площадей нужно уточнить это правило. Но и в этом случае надо делать по расстоянию (например, по внешней границе территории собственно площади).
Если код сам по себе полностью процедурный без единого класса, но использует библиотеку, в которой создаются объекты и зовутся их методы - это считать ООП?
Смешно тут то, что авторы таких утверждений не понимают (или не хотят признавать), что Linux, и ядро любого Unix, и ядро Windows - они все на ООП как раз классического пассивного, не-Кеевского типа. Полиморфизм на виртуальных функциях - в полный рост. Уровень сисколлов: есть универсальный read() на всех, write(), close(), fcntl(), вплоть до epoll и io_uring, ко всем применяются одинаковые методы для большинства работ, внутри происходит переключение. В реализации read(), например,
ret = file->f_op->read_iter(&kiocb, &iter);- f_op это Virtual Method Table.Инкапсуляция делается только на границе user land / kernel land, да. Но это ограничение языка. Был бы даже очень урезанный C++ - всякие private и protected были бы везде. А пока следят на уровне верификации кода (начиная с визуальной).
Наследования в явном виде очень мало, да. Например, в иерархии обработки ioctl: есть общие для всех вообще дескрипторов, есть для терминалов, есть для последовательных портов, которые тоже терминалы, реализация чисто через код. Остальное неудобно делать. Но и без него достаточно.
Так что вы с этим
неправы, Linux ещё больше играет за вашу же команду: ООП нужен - там, где удобен.
(Повторюсь) сокращение - не проблема. Ну стали нумероваться с 81 вместо 1, зато принцип расстояний соблюдается, вместе с монотонным возрастанием номеров в ходе движения. А не так, что, например, идут 3,5,7,9, а потом вдруг 3а.
Тут в описании пропущено существенное, согласен. Сначала надо найти точку посредине проезжей части улицы, к которой данный объект (наиболее важное место его доступ, типа крыльца или ворот, если нет - то самая выделяющаяся) ближе всего, затем считается расстояние от этой точки до начала улицы (плюс какая-то константа, заданная в паспорте этой улицы), и наконец расстояние проецируется на пространство номеров (например, делится на 10 метров и дальше округляется до ближайшего чётного или нечётного номера, согласно стороне). Погрешность в несколько метров и пару процентов несущественна, пока нет нумерованных в обратном порядке. В случае, если несколько объектов получили бы один номер, добавляем буквы, как сейчас принято.
А это неважно. Главное, чтобы номера были не меньше, если какой-то запас и нумерация начинается, например, с 19 и 20 - не страшно, у нас целых чисел на всех хватит.
Удлинение улицы с её формального начала - редчайший случай. Скорее в таком случае кусок называют другим именем. Укорачивание ничего не меняет. Разрыв - тоже.
В предполагаемом варианте я допускаю добавление константы к номерам, общей на всех, поэтому если улица начнётся с номеров 251/252 - ничего плохого, если дальше будет увеличение по расстоянию.
В любом случае это лучше того бардака, что сейчас почти везде.
Хорошо бы этот вариант, как самый простой и надёжный, реализовать везде:)
Втекает == доходы
вытекает == расходы
Мне сложно представить себе, что для кого-то будет наоборот.
??? Не понимаю, как можно было так интерпретировать мои слова ???
Ничего из описанного вами не является причиной для падений. Кстати, аддонов у меня там нету.
Аналогичные периоды падений были и раньше, как-то прекращались. Видимо, метод тестирования на живых пользователях разработчикам хрома нравится не меньше, чем мелкомягким.
Насколько видно из публичных данных, как раз втекало бы в разы меньше. Вытекало бы меньше, да, но насколько - ХЗ.