Полностью или не полностью вообще не играет роли. Покуда в баллоне есть вещество в жидкой фазе, над этой жидкой фазой будет газовая фаза этого вещества, которая и создает давление внутри баллона, потому как газ подобен пружине.
Давление этого газа вообще не зависит от количества жидкой фракции в баллоне! Оно зависит только от давления насыщенных паров конкретного вещества при конкретной температуре — а это табличные величины.
Если из баллона выпустить какую-то часть вещества (хоть газовую фазу сверху, хоть жидкую снизу), давление в нем не уменьшится: по принципу Ле Шателье с поверхности жидкой фазы испарится ровно столько вещества, сколько нужно, чтобы вернуть прежнее давление в баллоне. Только когда в баллоне не останется жидкой фазы, а останется только газовая, то есть нечему будет кипеть, выпуск газа наружу будет приводить к снижению давления.
Так вот:
Давление насыщенных паров при разных температурах разное, но какую температуру ни возьми, у пропана она в разы больше, чем у изобутана!
При температуре +25°C давление внутри любого баллона с изобутаном будет 3.4 атм, а внутри любого с пропаном — 9.5 атмосфер.
Рассчитан ли туристический баллон для изобутаном на давление в 10 атмосфер? Может и рассчитан, ведь уже при температуре +65°C давление в том же баллоне с изобутаном уже составляет примерно те же 9.5 атм. Но рассчитан ли он на проран? Нет, потому что с пропаном при той же температуре давление внутри баллона будет уже 24 атмосферы.
В общем, заряжая пропан в тонкостенный туристический баллон, вы играете в опасную игру, подвергая баллон действию кратно более высокого давления на постоянной основе.
Прочнисты никуда не исчезли, а копировальщицы, которые перерисовывали с одного чертежа на другой действительно исчезли, но только это исчезновение равнозначно исчезновению набивщиц перфокарт, а не исчезновению программистов.
То о чем пишут в статье — это предрекание исчезновения как раз тех самых консьрукторов. Мол, останутся только промпт-инженеры, которые будут объяснять ИИ, что должно делать изделие, и уже ИИ будет выдумывать конструктив от и до.
Если продолжать: VB (и в равной степени VBA) это, пожалуй, уникальная среда, где интерпретирование кода (парсинг, разбор) происходило в момент набора кода в редакторе, и с тех пор, как программист нажал Enter (или другим способом перешёл на другую строку), строка кода под капотом вообще больше не существует как текст.
Лишь для целей отрисовки на экране избранные строки реконструировались обратно в цветной текст из исходно не текстового представления.
По этой причине (потому что код под капотом не существует как код в привычном нам строковом представлении) в VB-коде невозможно произвольно отбивать/не отбивать пробелами скобочки, запятые или ключевые слова, либо же произвольным образом играть с регистром символов ключевых слов или идентификаторов — приведение регистра в каноничную форму и вырезание лишних пробелов (и вставка недостающих) не дополнительная фича (которую можно было бы отключить), а следствие архитектуры, подразумевающей неиспользование текстового представления кода под капотом среды разработки.
Какое T-S-D у Моргенштерна? Я конечно не могу в уме воспроизвести ни одной композиции последнего, но в целом, в среднем по больнице, у меня ощущение, что есть тенденция на пропадание из музыки гармонической составляющей.
Нет больше игры на струнах души с помощью манипулирования сменой аккордов. Перестало быть модным как художественный инструмент.
Вопреки гуляющим в сети бредням, что VB интерпретируемый язык, по умолчанию при генерации исполняемых файлов среда генерировала IL-код в том формате, в каком происходило взаимодействие между фронтендом и бэкендом компилятора Microsoft Visual C/C++ — и этот IL скармливался бэкенду.
Соответствие, оптимизация при генерации машинного кода была настолько же хороша, насколько хорошо это получалось у MSVC соответствующей версии. Никак не хуже.
Если не быть чудаком и использовать типизированные переменные скалярных типов, а не тип Variant — код получался настолько же хорошим, как аналогичный сильный код, с той оговоркой, что в код вставлялись проверки, чтобы не выстрелить себе в ногу. Да и то, эти проверки были весьма легковесными — например, проверка на переполнение после операции сложения делалась одной единственной инструкцией JO/JNO, проверяющей OF. Но и подобный проверки во многом можно было отключить в настройках оптимизации.
Не по умолчанию — это компиляция в P-code. Так назывался байт-код собственной виртуальной машины VB/VBA. Этот вариант всегда использования в режиме отладки, потому что позволяло чрезвычайно бонато и гибко править код по живому в процессе запуска в режиме отладки. В этом случае операции проводились короткими обработчиками соответствующих P-codeных инструкций, которые были написаны на ассемблере и вылизаны, насколько это было возможно.
Операции над типом Variant в любом случае выполнялись при помощи API-функций ил OLEAUT32.DLL.
Вам стоило бы знать, что миндалины бывают разные. Есть нёбные, есть глоточная, есть язычная. Автор пишет про удаление аденоидов — это т.н. носоглоточная миндалина. А в комментариях он пишет уже о нёбных миндалинах.
Каждый сегмент имеет свой собственный размер и базовый адрес в физической памяти.
Нет, базовый адрес сегмента — это линейный адрес, а не физический. Они не тождественны в общем случае, и только если бит PG в CR0 выключен, линейный адрес будет численно равен физическому.
Но главное, что поскольку это именно линейный адрес, сегмент может быть и как угодно фрагментирован в физпамяти, а сточки зрения кода это будет непрерывный блок.
Каждый из этих регистров хранит базовый адрес соответствующего сегмента.
Нет, не хранит. В реальном режиме он хранит индекс параграфа физпамяти, к которому будет приплюсовано смещение.
В защищенном режиме он хранит селектор, который состоит из битовых полей, отдельные биты которого задают индекс дескриптора сегмента в глобальной/локальной таблице дескрипторов.
Но, что это интересно, в исходном ошибочном утверждении таки есть доля правды: с введением защищенного режима у сегментных регистров появилась невидимая пользователю теневая часть, в которую процессор заносит базу, лимит, атрибуты доступа соответствующего сегмента, чтобы затем при каждом обращении к сегменту не читать эту информацию из GDT/LDT. То есть это такой кеш для текущего элемента GDT/LDT.
Эта модель была широко использована в ранних компьютерных системах и операционных системах, таких как Intel 8086/8088, и была частично сохранена в более поздних архитектурах x86.
Чего это частично? По мере развития 8086/80186/80286/80386/80486/80586 от сегментов никто не отказывался и их функциональность никак не урезал. Наоборот, появились регистры FS и GS.
Это только в amd64 решили рубить с плеча, потому что парадигма поменялась: раньше инновации в области процессорных архитектур мотивировали системных арограммистов на интересные решения в системном софте, а теперь тупо спрос рождает предложения.
Сегментная модель: может страдать от внешней фрагментации, когда различные сегменты разбросаны по физической памяти, что может затруднить выделение больших блоков для выполнения задач.
Как раз таки не страдает, в отличие от архитектур с flat-моделью памяти. Вот единое адресное пространство процесса очень легко фрагментировать микровыделениями, так, что свободно будет 80%, но нельзя будет выделить непрерывный блок, размером хотя бы 20% от суммарного объема свободной части АП.
А вот с сегментами такой проблемы нет, она есть только на уровне фрагментации линейного адресного пространства. Ах, если бы инженеры Intel сделали PDBR не в составе CR3, а в составе дескриптора сегмента... в этом случае проблема фрагментации была бы решена на корню.
Но и без этого, фрагментацию линейного адресного пространства можно было бы решить дефрагментацией: блоки данных можно было в нужные моменты времени сдвигать/раздвигать в линейном АП, чтобы устранить или расширить гэпы. При этом даже копирование данных не пришлось бы делать: достаточно править PDE/PTE, меняя трансляцию линейных адресов в PFN-ы.
В любом случае, для прикладного кода, который оперирует только селекторами, переезд содержимого сегмента в линейном АП вообще никак не останется замеченным: селектор тот же, смещения те же.
А вот с фрагментацией плоского АП сделать нельзя абсолютно ничего: нельзя разрозненные блоки памяти сдвинуть вместе, потому что программа держит миллион адресов, указывающих внутрь этих блоков, и все они станут недействительными.
Не попробую, потому что не существует плагина под мою IDE
Я не представяю, как АИ-помощник может помочь. Он должен разбираться в предметной оласти, а откуда ему это знать. Для этого мой код полностью будет сливаться провайдеру АИ-сеовиса?
И наконец, в последнем блоке case, используется символ универсального сопоставления. Он выглядит как знак подчёркивания (_) и играет роль ветви else условного оператора.
Ну гениально же! Лучшего выбора и сделать было нельзя. Но мне кажется создатели этого языка, подарка судьбы для продавцов курсов, недостаточно преисполнились в своем дзене
Вместо if нужно было использовать символ ?, а вместо else — символ /.
Возможно мы увидим это в каком-нибудь ином новорожденном языке, например, языке Udaff. Курсы по которому будут рекламировать из каждой дырки.
Полностью или не полностью вообще не играет роли. Покуда в баллоне есть вещество в жидкой фазе, над этой жидкой фазой будет газовая фаза этого вещества, которая и создает давление внутри баллона, потому как газ подобен пружине.
Давление этого газа вообще не зависит от количества жидкой фракции в баллоне! Оно зависит только от давления насыщенных паров конкретного вещества при конкретной температуре — а это табличные величины.
Если из баллона выпустить какую-то часть вещества (хоть газовую фазу сверху, хоть жидкую снизу), давление в нем не уменьшится: по принципу Ле Шателье с поверхности жидкой фазы испарится ровно столько вещества, сколько нужно, чтобы вернуть прежнее давление в баллоне. Только когда в баллоне не останется жидкой фазы, а останется только газовая, то есть нечему будет кипеть, выпуск газа наружу будет приводить к снижению давления.
Так вот:
Давление насыщенных паров при разных температурах разное, но какую температуру ни возьми, у пропана она в разы больше, чем у изобутана!
При температуре +25°C давление внутри любого баллона с изобутаном будет 3.4 атм, а внутри любого с пропаном — 9.5 атмосфер.
Рассчитан ли туристический баллон для изобутаном на давление в 10 атмосфер? Может и рассчитан, ведь уже при температуре +65°C давление в том же баллоне с изобутаном уже составляет примерно те же 9.5 атм. Но рассчитан ли он на проран? Нет, потому что с пропаном при той же температуре давление внутри баллона будет уже 24 атмосферы.
В общем, заряжая пропан в тонкостенный туристический баллон, вы играете в опасную игру, подвергая баллон действию кратно более высокого давления на постоянной основе.
Прочнисты никуда не исчезли, а копировальщицы, которые перерисовывали с одного чертежа на другой действительно исчезли, но только это исчезновение равнозначно исчезновению набивщиц перфокарт, а не исчезновению программистов.
То о чем пишут в статье — это предрекание исчезновения как раз тех самых консьрукторов. Мол, останутся только промпт-инженеры, которые будут объяснять ИИ, что должно делать изделие, и уже ИИ будет выдумывать конструктив от и до.
Скорее всего я эту её лекцию видел. В любом случае, это не отменяет моих последних слов.
И нет, я не гонюсь за богатством красок классиков, можно мне хотя бы богатство красок самоучек, которые 20 лет назад делали композиции?
Погодите-ка. Вы перезаправляете баллоны, исходно предназначенные для изобутана, пропаном. Правильно понял?
А какая эпплу выгода бороться с воровством? Наоборот же: украли у фанбоя телефон — он купит новый.
Если продолжать: VB (и в равной степени VBA) это, пожалуй, уникальная среда, где интерпретирование кода (парсинг, разбор) происходило в момент набора кода в редакторе, и с тех пор, как программист нажал Enter (или другим способом перешёл на другую строку), строка кода под капотом вообще больше не существует как текст.
Лишь для целей отрисовки на экране избранные строки реконструировались обратно в цветной текст из исходно не текстового представления.
По этой причине (потому что код под капотом не существует как код в привычном нам строковом представлении) в VB-коде невозможно произвольно отбивать/не отбивать пробелами скобочки, запятые или ключевые слова, либо же произвольным образом играть с регистром символов ключевых слов или идентификаторов — приведение регистра в каноничную форму и вырезание лишних пробелов (и вставка недостающих) не дополнительная фича (которую можно было бы отключить), а следствие архитектуры, подразумевающей неиспользование текстового представления кода под капотом среды разработки.
Какое T-S-D у Моргенштерна? Я конечно не могу в уме воспроизвести ни одной композиции последнего, но в целом, в среднем по больнице, у меня ощущение, что есть тенденция на пропадание из музыки гармонической составляющей.
Нет больше игры на струнах души с помощью манипулирования сменой аккордов. Перестало быть модным как художественный инструмент.
Почему «даже»?
Вопреки гуляющим в сети бредням, что VB интерпретируемый язык, по умолчанию при генерации исполняемых файлов среда генерировала IL-код в том формате, в каком происходило взаимодействие между фронтендом и бэкендом компилятора Microsoft Visual C/C++ — и этот IL скармливался бэкенду.
Соответствие, оптимизация при генерации машинного кода была настолько же хороша, насколько хорошо это получалось у MSVC соответствующей версии. Никак не хуже.
Если не быть чудаком и использовать типизированные переменные скалярных типов, а не тип Variant — код получался настолько же хорошим, как аналогичный сильный код, с той оговоркой, что в код вставлялись проверки, чтобы не выстрелить себе в ногу. Да и то, эти проверки были весьма легковесными — например, проверка на переполнение после операции сложения делалась одной единственной инструкцией JO/JNO, проверяющей OF. Но и подобный проверки во многом можно было отключить в настройках оптимизации.
Не по умолчанию — это компиляция в P-code. Так назывался байт-код собственной виртуальной машины VB/VBA. Этот вариант всегда использования в режиме отладки, потому что позволяло чрезвычайно бонато и гибко править код по живому в процессе запуска в режиме отладки. В этом случае операции проводились короткими обработчиками соответствующих P-codeных инструкций, которые были написаны на ассемблере и вылизаны, насколько это было возможно.
Операции над типом Variant в любом случае выполнялись при помощи API-функций ил OLEAUT32.DLL.
Судя по его описанию, это электроэнергетика.
Все-таки аппарат называется не холтер, а кардиорегистратор. А Холтер — фамилия человека, придумавшего методику.
Вам поставила?
Вы неправильно знаете. Это разные анатомические образования и операции по их удалению имели разные названия.
Вам стоило бы знать, что миндалины бывают разные. Есть нёбные, есть глоточная, есть язычная. Автор пишет про удаление аденоидов — это т.н. носоглоточная миндалина. А в комментариях он пишет уже о нёбных миндалинах.
Присоединяюсь к вашей скорби и негодованию, шлю лучи добра.
Да что угодно, контроллер станка какого-нибудь.
К кому вы обращаетесь? К переводчику статьи?
Нет, базовый адрес сегмента — это линейный адрес, а не физический. Они не тождественны в общем случае, и только если бит PG в CR0 выключен, линейный адрес будет численно равен физическому.
Но главное, что поскольку это именно линейный адрес, сегмент может быть и как угодно фрагментирован в физпамяти, а сточки зрения кода это будет непрерывный блок.
Нет, не хранит. В реальном режиме он хранит индекс параграфа физпамяти, к которому будет приплюсовано смещение.
В защищенном режиме он хранит селектор, который состоит из битовых полей, отдельные биты которого задают индекс дескриптора сегмента в глобальной/локальной таблице дескрипторов.
Но, что это интересно, в исходном ошибочном утверждении таки есть доля правды: с введением защищенного режима у сегментных регистров появилась невидимая пользователю теневая часть, в которую процессор заносит базу, лимит, атрибуты доступа соответствующего сегмента, чтобы затем при каждом обращении к сегменту не читать эту информацию из GDT/LDT. То есть это такой кеш для текущего элемента GDT/LDT.
Чего это частично? По мере развития 8086/80186/80286/80386/80486/80586 от сегментов никто не отказывался и их функциональность никак не урезал. Наоборот, появились регистры FS и GS.
Это только в amd64 решили рубить с плеча, потому что парадигма поменялась: раньше инновации в области процессорных архитектур мотивировали системных арограммистов на интересные решения в системном софте, а теперь тупо спрос рождает предложения.
Как раз таки не страдает, в отличие от архитектур с flat-моделью памяти. Вот единое адресное пространство процесса очень легко фрагментировать микровыделениями, так, что свободно будет 80%, но нельзя будет выделить непрерывный блок, размером хотя бы 20% от суммарного объема свободной части АП.
А вот с сегментами такой проблемы нет, она есть только на уровне фрагментации линейного адресного пространства. Ах, если бы инженеры Intel сделали PDBR не в составе CR3, а в составе дескриптора сегмента... в этом случае проблема фрагментации была бы решена на корню.
Но и без этого, фрагментацию линейного адресного пространства можно было бы решить дефрагментацией: блоки данных можно было в нужные моменты времени сдвигать/раздвигать в линейном АП, чтобы устранить или расширить гэпы. При этом даже копирование данных не пришлось бы делать: достаточно править PDE/PTE, меняя трансляцию линейных адресов в PFN-ы.
В любом случае, для прикладного кода, который оперирует только селекторами, переезд содержимого сегмента в линейном АП вообще никак не останется замеченным: селектор тот же, смещения те же.
А вот с фрагментацией плоского АП сделать нельзя абсолютно ничего: нельзя разрозненные блоки памяти сдвинуть вместе, потому что программа держит миллион адресов, указывающих внутрь этих блоков, и все они станут недействительными.
Не попробую, потому что не существует плагина под мою IDE
Я не представяю, как АИ-помощник может помочь. Он должен разбираться в предметной оласти, а откуда ему это знать. Для этого мой код полностью будет сливаться провайдеру АИ-сеовиса?
Я думал это шутка, что кто-то вместо написания кода доверяет задачу нейросетям.
Ну гениально же! Лучшего выбора и сделать было нельзя. Но мне кажется создатели этого языка, подарка судьбы для продавцов курсов, недостаточно преисполнились в своем дзене
Вместо if нужно было использовать символ ?, а вместо else — символ /.
Возможно мы увидим это в каком-нибудь ином новорожденном языке, например, языке Udaff. Курсы по которому будут рекламировать из каждой дырки.