А может они просто "пучки света", летающие безо всяких кораблей, зачем им космопорты и космо-лифты? Да не, не может такого быть, в кино же никогда такого не было!
Какой-то крайне неудачный пример с оснасткой? Есть люди, у которых команды запуска разных оснасток не отлетают от зубов? По крайней мере devmgmt, diskmgmt, lusrmgr?
Что с вами не так, что вы сходу и без подсказок не поняли всю фишку, прелесть, суть и глубину производных? И не только с вами.
И это не подкол: реально хочется понять — вас каким-то не тем путём подводят к понятию производной. Тогда не понимать должен весь класс. Или это как с золотым/синим платьем?
А что делать, если мне не сложно читать первую запись? Куда обратиться? А вот вторая запись, напротив, вызывает вопросы.
Во-втором примере я не вижу, куда спряталась информация о типе возврата функции, указатель на которую передаётся. Или функции operation пофигу: она ждёт указатель на функцию, принимающую два инта, а что она там возвращает ей глубоко наплевать? И как в этой нотации записать не указатель на функцию, а указатель на указатель на функцию, или указатель на указатель на указатель на функцию?
И чтобы все среды разработки из коробки поддерживали такие гибридные проекты.
В смысле, среды? Какие вам среды нужны?
Писать проект на двух или более языках всегда было возможно, и эта возможность всегда упиралась в линкер, а не IDE или один из ЯП. Если линкер способен слинковать объектные файлы, порождённые разными компиляторов разных ЯП — милости просим.
И чтобы это происходило легко и безболезненно, мировому сообществу нужно было тратить больше усилий на стандартизацию ABI, на стандартизацию способа декорирования/замангливания имён, а не на привнесение в язык тупейшего синтаксического сахара, чем они заняты в последнее время.
Что за субстанция в голове у людей, которые вот так искренне считают...
fn funcname() -> rettype
Вместо
rettype funcname()
И эти люди смеют заикаться о громоздкости... Что касается архаичного, якобы, внешнего вида, то это чистой воды NIH-синдром и юношеское революционерство, желание стать Страуструпом 21-го века и дистанцироваться от предыдущих поколений.
Поставить винду — это простейшая задача. А вот бут-сектор диска и раздела починить, наладить дулбут, посидеть с дизассемблером над кодом загрузчика — вот это задача уже не простая.
Сравнивать концепцию, которая буквально вчера появилась в процессорах, с концепцией, которой уже сорок лет?
«Ваша» memory protection keys по сравнению с сегментами защищённого режима:
Page-level, а не byte-level защита. А вот сегенты защищённого режима могли (могут) иметь как страничную, так и байтовую гранулярность.
Работает только в 64-битном режиме (не проверял)
Ограничение на максимальное число ключей защиты, жестко заданное на уровне архитектуры процессора. Всего 16 ключей защиты на любой процесс. Шестнадцать, Карл! Это значит, можно создать 16 независимо защищаемых буферов или разделить все защищаемые страницы на 16 подмножеств.
Принципиально никак не защищает от ошибок переполнения буфера — если индекс/смещение адресуемого элемента больше величины буфера, мы получаем такое же исключение, как просто при доступе в «запрещённую для чтения» страницу, но если индекс/смещение на удачу достаточно большое, то можно чисто случайно попасть пальцем в следующий доступный и разрешённый для нас буфер и операция чтения/записи пройдёт вообще без сучка и без задоринки. То есть это технически решение такого же уровня надёжности, как в обычном x86 без этой новой технологии просто после буфера создать полосу из guard-страниц и надеяться, что когда кто-то по ошибке вылезет за пределы буфера, он наткнётся на guard-страницу и будет отловлен. Но если он перепрыгнет guard-gap, то никто тревогу не забьёт.
Вообще никак не распространяется на instruction fetchинг у процессора. То есть по прежнему в рамках одного процесса кто угодно может вызывать кого угодно. Любой код может сделать call или jmp в аюсолютно любое место адресного пространства, если базовые аттрибуты защиты страниц это позволяют.
По прежнему не позволяет реорганизовать написание программ и архитектуру приложения так, что приложение дробится на множества маленьких микро-песочниц, где прорыв безопасности и установление полного хаоса в одной из них никак не распространяется на соседние. Оно и не удивительно: это решение в духе «пришей кобыле хвост» — оно и не должно было бы революционным и не должно было бы требовать иных ЯП и иных архитектурных подходов.
Требует явного написания дополнительного кода программистом для того, чтобы получить какие-то бенефиты от новоявленной технологии.
Новости сто лет в обед, и вдруг пошли комменты как из рога изобилия.
Конечно можно не переводить: достаточно исправить баги. В ином случае процесс перевода можно наплодить намного больше новых багов — можно подумать кроме use-after-free в мире не бывает никаких других багов...
При небольшой доработке могут - это называется VBScript, который имеет еще дополнительные объекты по сравнению с VBA вроде словаря, регулярок и т.д
VBScript это не расширение VBA, это совершенно другой продукт, который разделяет с VBA ту же торговую марку и очень похожий по синтаксису но несколько иной язык.
Что касается словаря, регулярок и прочего — это не часть VBScript-а, это реализованные в отдельной ActiveX DLL библиотеки классы, которыми вы с лёкостью можете пользовать точно так же и из VBA, и из VB6, и из C++, и из Си, и из PHP собранным с модулем-расширением, дающим поддержку COM в PHP.
Добавлено позже:
Точнее класс для регулярок таки часть VBScript, а вот словарь нет. Что не мешает пользоваться классом для регулярок из под VBA (или откуда угодно ещё) так же, как вы пользуетесь классом для словаря из VBScript (и так же, как им можно пользоваться откуда угодно ещё).
Но в целом, так же можно обращаться по имени модуля, и получим почти те же самые "классы"
Что за пургу вы несёте, не побоюсь этого слова? Тут ниже я распинался расписывать аргументацию об отличие VBA от VBS, но судя по таким заявлением, у вас знаний о технологии на уровне «слышал звон».
Абсолютное ахинею вы написали.
Модули это просто способ сгруппировать процедуры и переменные по организаицонному принципу, и сделать некий скоуп, чтобы внутри него можно было сделать Public сущности, видимые внешнему миру и Private сущности, которые доступны только внутри модуля.
Всё. Время жизни модульных переменных соответствует времени жизни проекта.
Классы же — это натурально классы как в любых других языках программирования. Их можно инстанциировать, то есть порождать экземпляры класса. У каждого класса будет своя копия всех его переменных полей/членов. Можно создать 10, а можно создать 1000 экземпляров одного класса. У разных классов будут разные значения полей, разные внутренние состояния. А модули это просто модули. Нельзя создать экземпляр модуля или несколько экземпляров модуля.
У классов, а точнее экземпляров классов есть время жизни, основанное на подсчёте ссылок. Объекты (экземпляры классов) уничтожаются, когда счётчик ссылок достигает значения 0. О модулей нет никаких счётчиков ссылок и никакого уничтожения.
Экземпляры классов «адресуются» по ссылками. Может быть один объект, но 10 разных ссылок на него из разных мест. Ссылки на объекты можно передавать в другие DLL (написанные на других языках). Благодаря OLE ссылки на объекты можно передавать в другие процессы или даже на другие компьюреры — обращения к членам таких объектов по таким ссылкам будут работать через RPC-механизмы.
Ссылку на COM-класс написанный на VB или VBA можно передать в любой другой язык, поддерживающий технологию COM (явно или неявно, как C или C++) и из любого другого языка дёргать методы или обращаться к полям. И наоборот, с объектом, реализованным на совершенно другом языке, можно работать в VB/VBA, если объект импементирован по правилам COM. Модули так не могут. Нет никаких ссылок на модулей или на экземпляры модулей, потому что не бывает экземпляров модулей.
Классы в VB/VBA могут поддерживать интерфейсы, то есть, в частности, могут поддерживать множество интерфейсов. И не обязательно это должны быть интерфейсы, определённые в том же VB/VBA-проекте, это могут быть совершенно сторонние COM-интерфейсы. Модули не могут поддерживать интерфейсы, потому что модули это не объектные сущности.
Классы в VB/VBA могут быть источниками событий, на которые другие объекты могут подписываться, причём подписка на события всегда может быть множественной: на одно событие одного объекта-источников может быть целая гора listener-ов. О модулей нет никаких событий, модули не могут генерировать события.
И после этого вы говорите, что классы это те модули? Алё, очнитесь.
Класс:
' Класс CSample
Public Foo As String
Какой-то код где-то:
Dim jaa as CSample
Dim bau as CSample
Dim sir as CSample
Set jaa = New CSample
Set bau = New CSample
Set sir = New CSample
jaa.Foo = "Крокодил"
bau.Foo = "Телевизор"
sir.Foo = "Мурманский полуостров"
' Сейчас существует три объекта, три экземпляра класса
' и каждого своё собственное значение свойства «Foo»
Set bau = sir
'
' А теперь осталось в живых только два объекта:
' «Крокодил» (на него есть 1 ссылка) и
' «Мурманский полуостров»' (на него теперь есть 2 ссылки)
' тогда как «Телевизор» только что уничтожился, так как не него
' не осталось ни одной живой ссылки.
'
И что тут общего с модулями? Как после этого сниппета можно утверждать, что классы и модули это одно и то же?
Сложно передать степень фейспалмовости, которое я получил от прочтения ваших убеждений. И такое чувство возникает, прямо между строк читается, будто вы сами обманываться рады.
Будем надеяться, что это искренние заблуждения.
Во-первых, вы вероятно считаете, что между VBA и VBScript совсем небольшая разница, а классический VB (например VB6), который компилируемый, который в EXE-файлы компилируется, который x86-машинный код даёт на выходе стоит где-то в стороне.
Это в корне неверно!
На самом деле, всё наоборот. VB и VBA это практически одно и то же. Образно выражаясь, их генетических код сход на 99%, а в реальности оба продукта собраны из одних и тех же исходников, но с разными ключами условной компиляции.
А вот VBScript это совершенно другой проект, у него абсолютно своя кодовая база, он разрабатывался (по видимоу) другой командой, и единственное, что его роднит с VB и VBA это то, что маркетологам в Microsoft захотелось, чтобы новый скриптовый язык что-то роднило с уже раскрученным брендом.
VBScript это реально скриптовый язык. Он интерпретируется в момент запуска. Он абсолютно безтиповый. У него ОБЩЕЕ ядро с JScript (майкрософтовская имплементация JavaScript).
VB и VBA это совершенно иная история. Во-первых, это уникальный продукт, в котором код хоть и отображается в виде привычного кода, но под капотом среды перестаёт существовать в виде текста уже в момент написания — сразу после того, как программист перевёл каретку на другую, условно говоря, строку. В этот момент код подвергается синтаксическому разбору, по нему строится синтаксическое дерево, оно анализируется, по нему строятся другие бинарные структуры, отражающие семантику написанного. Текстуальное представление кода при этом вообще отбрасывается — когда IDE хочет отрисовать цветной код на экране или отдать его в буфер обмена, она воссоздаёт исходный код ровно для этой цели. Уже это делает VB/VBA языками, которые не имеют ничего общего с интерпретируемыми языками.
В отличие от интерпретируемых языков, которые разбираются и анализируются по мере исполнения программы, здесь разбор кода происходит даже не в момент запуска, а в момент набора кода!
Далее из высокоуровневых древовидных и графовидных структур, которые IDE использует для хранения кода внутри себя, нужные процедуры по принципу JIT компилируются в P-код — так называет байт-код виртуальной машины VB/VBA.
Результаты выполнения, если процедура не менялась, между перезапусками «проекта» не перекомпилируются.
VB же вдобавок умеет компилировать не в P-код, а в Native-код, то есть в машинный код x86-процессоров.
Если вы отбросите своё пренебрежительное отношение и реально захотите разобраться, то вам стоит прочитать несколько статей и несколько моих комментов, в которых я немного раскрыл тайны внутреннего мира VB.
Статьи:
Почему меня называют «отцом Visual Basic'а» Перевод статьи Алана Купера о том, как он придумал технологию под названием Ruby (не путать с языком программирования Ruby), и как потом она стала частью VB (но не VBA)
Thunder... рождение Visual Basic Перевод статьи одного из разработчиков VB о том, как они создавали Thunder, который позже стал VB со многими инсайдерскими фактами.
И ещё раз под конец: между VBA и VBScript общего намного меньше, чем вам кажется. По сути что-то общее есть толкьо на уровне названия и фасада, который виден пользователю. Изнутри это абсолютно разные продукты.
Я говорю о i386 и его плюшках — плюшках его защищённого режима. И не Интел облажался, а мировое сообщество, которое не стало всё это использовать.
Удобная для программистов вещь, но абсолютное зло с точки зрения изначальной идеологии защищённого режима — так называемая flat-модель организации памяти. В рамках одного процесса операционной системы абсолютно все данные «видны» любому коду в рамках процесса. Большинство данных в адресном пространстве процесса доступно для перезаписи абсолютно кому угодно (то есть какому угодно коду, оказавшемуся в рамках процесса, даже шелл-коду, который хакер заботливо загнал в переполнившийся буфер). Некоторые данные защищены от перезаписи на уровне защиты страниц, но это защита чисто номинальная, потому что снять её не составляет никакого труда.
Между тем защищённый режим x86 предполагает возможность сделать так, что каждый отдельно взятый кусок программы имеет доступ только к тем данным, с которыми ему дозволено работать. И не только данным, но и другому коду. То есть можно программу нарезать на маленькие куски, эдакие микромодули и каждый поместить в песочницу, в которой доступен минимально необходимый набор данных (и кода). Так, что комар не пролетит. Каждый буфер может иметь аппаратную защиту от доступа за его границу.
Но это потребовало бы совершенно иного программирования и других ЯП.
Наконец, он поставил под сомнение само понимание безопасности: критики фокусируются на безопасности памяти, оставляя без внимания многие другие места, где можно проколоться.
В точку! Стремление определенных людей любой ценой переписать все на якобы безопасный Раст напоминает утопическую идею вроде всемирного коммунизма или проекта Венера.
Тем временем, когда x86 со своим защищенным режимом (особенно 386+) предложила защиту на аппаратном уровне (которая поставила бы крест на атаках типа переполнения буфера, исполнения шелл-кода), никто толком не заценил технологию, не бросился имплементировать её и создавать новые ЯП под неё. В итоге развивать и оптимизировать эти плюшки Интел не стала, а в x86-64 они и вовсе попали под выпил.
Было. В фильме «Ка-Пекс».
Подождите-ка. Это делает не пользователь, а софт. И для разработчика софта в MSDN это все описывалось.
Какой-то крайне неудачный пример с оснасткой? Есть люди, у которых команды запуска разных оснасток не отлетают от зубов? По крайней мере devmgmt, diskmgmt, lusrmgr?
А рутубом владеет Газпром?
Что с вами не так, что вы сходу и без подсказок не поняли всю фишку, прелесть, суть и глубину производных? И не только с вами.
И это не подкол: реально хочется понять — вас каким-то не тем путём подводят к понятию производной. Тогда не понимать должен весь класс. Или это как с золотым/синим платьем?
Это преувеличение. Для этого нужно давление порядка сотен бар (чего априори не будет в разводке жилых и общественных зданий) и сопло надлежащей формы.
А что делать, если мне не сложно читать первую запись? Куда обратиться? А вот вторая запись, напротив, вызывает вопросы.
Во-втором примере я не вижу, куда спряталась информация о типе возврата функции, указатель на которую передаётся. Или функции operation пофигу: она ждёт указатель на функцию, принимающую два инта, а что она там возвращает ей глубоко наплевать? И как в этой нотации записать не указатель на функцию, а указатель на указатель на функцию, или указатель на указатель на указатель на функцию?
Я бы огорчился но понял, если бы они вообще запретили инлайн асм в С++. Но почему запрещён имено x64-асм, а другие не запрещены я даже понять не могу.
В смысле, среды? Какие вам среды нужны?
Писать проект на двух или более языках всегда было возможно, и эта возможность всегда упиралась в линкер, а не IDE или один из ЯП. Если линкер способен слинковать объектные файлы, порождённые разными компиляторов разных ЯП — милости просим.
И чтобы это происходило легко и безболезненно, мировому сообществу нужно было тратить больше усилий на стандартизацию ABI, на стандартизацию способа декорирования/замангливания имён, а не на привнесение в язык тупейшего синтаксического сахара, чем они заняты в последнее время.
Что за субстанция в голове у людей, которые вот так искренне считают...
fn funcname() -> rettype
Вместо
rettype funcname()
И эти люди смеют заикаться о громоздкости... Что касается архаичного, якобы, внешнего вида, то это чистой воды NIH-синдром и юношеское революционерство, желание стать Страуструпом 21-го века и дистанцироваться от предыдущих поколений.
Продактом вы стали за 9 месяцев до своего рождения. А на работе вы стали продакт-менеджером или кем-то вроде того.
Ей богу, от этого неуместного опускания слов уже кровь из глаз. То продакт, то диджитал...
Поставить винду — это простейшая задача. А вот бут-сектор диска и раздела починить, наладить дулбут, посидеть с дизассемблером над кодом загрузчика — вот это задача уже не простая.
Серьёзно?
Сравнивать концепцию, которая буквально вчера появилась в процессорах, с концепцией, которой уже сорок лет?
«Ваша» memory protection keys по сравнению с сегментами защищённого режима:
Page-level, а не byte-level защита. А вот сегенты защищённого режима могли (могут) иметь как страничную, так и байтовую гранулярность.
Работает только в 64-битном режиме (не проверял)
Ограничение на максимальное число ключей защиты, жестко заданное на уровне архитектуры процессора. Всего 16 ключей защиты на любой процесс. Шестнадцать, Карл! Это значит, можно создать 16 независимо защищаемых буферов или разделить все защищаемые страницы на 16 подмножеств.
Принципиально никак не защищает от ошибок переполнения буфера — если индекс/смещение адресуемого элемента больше величины буфера, мы получаем такое же исключение, как просто при доступе в «запрещённую для чтения» страницу, но если индекс/смещение на удачу достаточно большое, то можно чисто случайно попасть пальцем в следующий доступный и разрешённый для нас буфер и операция чтения/записи пройдёт вообще без сучка и без задоринки. То есть это технически решение такого же уровня надёжности, как в обычном x86 без этой новой технологии просто после буфера создать полосу из guard-страниц и надеяться, что когда кто-то по ошибке вылезет за пределы буфера, он наткнётся на guard-страницу и будет отловлен. Но если он перепрыгнет guard-gap, то никто тревогу не забьёт.
Вообще никак не распространяется на instruction fetchинг у процессора. То есть по прежнему в рамках одного процесса кто угодно может вызывать кого угодно. Любой код может сделать call или jmp в аюсолютно любое место адресного пространства, если базовые аттрибуты защиты страниц это позволяют.
По прежнему не позволяет реорганизовать написание программ и архитектуру приложения так, что приложение дробится на множества маленьких микро-песочниц, где прорыв безопасности и установление полного хаоса в одной из них никак не распространяется на соседние. Оно и не удивительно: это решение в духе «пришей кобыле хвост» — оно и не должно было бы революционным и не должно было бы требовать иных ЯП и иных архитектурных подходов.
Требует явного написания дополнительного кода программистом для того, чтобы получить какие-то бенефиты от новоявленной технологии.
Новости сто лет в обед, и вдруг пошли комменты как из рога изобилия.
Конечно можно не переводить: достаточно исправить баги. В ином случае процесс перевода можно наплодить намного больше новых багов — можно подумать кроме use-after-free в мире не бывает никаких других багов...
VBScript это не расширение VBA, это совершенно другой продукт, который разделяет с VBA ту же торговую марку и очень похожий по синтаксису но несколько иной язык.
Что касается словаря, регулярок и прочего — это не часть VBScript-а, это реализованные в отдельной ActiveX DLL библиотеки классы, которыми вы с лёкостью можете пользовать точно так же и из VBA, и из VB6, и из C++, и из Си, и из PHP собранным с модулем-расширением, дающим поддержку COM в PHP.
Добавлено позже:
Точнее класс для регулярок таки часть VBScript, а вот словарь нет. Что не мешает пользоваться классом для регулярок из под VBA (или откуда угодно ещё) так же, как вы пользуетесь классом для словаря из VBScript (и так же, как им можно пользоваться откуда угодно ещё).
Что за пургу вы несёте, не побоюсь этого слова? Тут ниже я распинался расписывать аргументацию об отличие VBA от VBS, но судя по таким заявлением, у вас знаний о технологии на уровне «слышал звон».
Абсолютное ахинею вы написали.
Модули это просто способ сгруппировать процедуры и переменные по организаицонному принципу, и сделать некий скоуп, чтобы внутри него можно было сделать Public сущности, видимые внешнему миру и Private сущности, которые доступны только внутри модуля.
Всё. Время жизни модульных переменных соответствует времени жизни проекта.
Классы же — это натурально классы как в любых других языках программирования. Их можно инстанциировать, то есть порождать экземпляры класса. У каждого класса будет своя копия всех его
переменныхполей/членов. Можно создать 10, а можно создать 1000 экземпляров одного класса. У разных классов будут разные значения полей, разные внутренние состояния. А модули это просто модули. Нельзя создать экземпляр модуля или несколько экземпляров модуля.У классов, а точнее экземпляров классов есть время жизни, основанное на подсчёте ссылок. Объекты (экземпляры классов) уничтожаются, когда счётчик ссылок достигает значения 0. О модулей нет никаких счётчиков ссылок и никакого уничтожения.
Экземпляры классов «адресуются» по ссылками. Может быть один объект, но 10 разных ссылок на него из разных мест. Ссылки на объекты можно передавать в другие DLL (написанные на других языках). Благодаря OLE ссылки на объекты можно передавать в другие процессы или даже на другие компьюреры — обращения к членам таких объектов по таким ссылкам будут работать через RPC-механизмы.
Ссылку на COM-класс написанный на VB или VBA можно передать в любой другой язык, поддерживающий технологию COM (явно или неявно, как C или C++) и из любого другого языка дёргать методы или обращаться к полям. И наоборот, с объектом, реализованным на совершенно другом языке, можно работать в VB/VBA, если объект импементирован по правилам COM. Модули так не могут. Нет никаких ссылок на модулей или на экземпляры модулей, потому что не бывает экземпляров модулей.
Классы в VB/VBA могут поддерживать интерфейсы, то есть, в частности, могут поддерживать множество интерфейсов. И не обязательно это должны быть интерфейсы, определённые в том же VB/VBA-проекте, это могут быть совершенно сторонние COM-интерфейсы. Модули не могут поддерживать интерфейсы, потому что модули это не объектные сущности.
Классы в VB/VBA могут быть источниками событий, на которые другие объекты могут подписываться, причём подписка на события всегда может быть множественной: на одно событие одного объекта-источников может быть целая гора listener-ов. О модулей нет никаких событий, модули не могут генерировать события.
И после этого вы говорите, что классы это те модули? Алё, очнитесь.
Класс:
Какой-то код где-то:
И что тут общего с модулями? Как после этого сниппета можно утверждать, что классы и модули это одно и то же?
Сложно передать степень фейспалмовости, которое я получил от прочтения ваших убеждений. И такое чувство возникает, прямо между строк читается, будто вы сами обманываться рады.
Будем надеяться, что это искренние заблуждения.
Во-первых, вы вероятно считаете, что между VBA и VBScript совсем небольшая разница, а классический VB (например VB6), который компилируемый, который в EXE-файлы компилируется, который x86-машинный код даёт на выходе стоит где-то в стороне.
Это в корне неверно!
На самом деле, всё наоборот. VB и VBA это практически одно и то же. Образно выражаясь, их генетических код сход на 99%, а в реальности оба продукта собраны из одних и тех же исходников, но с разными ключами условной компиляции.
А вот VBScript это совершенно другой проект, у него абсолютно своя кодовая база, он разрабатывался (по видимоу) другой командой, и единственное, что его роднит с VB и VBA это то, что маркетологам в Microsoft захотелось, чтобы новый скриптовый язык что-то роднило с уже раскрученным брендом.
VBScript это реально скриптовый язык. Он интерпретируется в момент запуска. Он абсолютно безтиповый. У него ОБЩЕЕ ядро с JScript (майкрософтовская имплементация JavaScript).
VB и VBA это совершенно иная история. Во-первых, это уникальный продукт, в котором код хоть и отображается в виде привычного кода, но под капотом среды перестаёт существовать в виде текста уже в момент написания — сразу после того, как программист перевёл каретку на другую, условно говоря, строку. В этот момент код подвергается синтаксическому разбору, по нему строится синтаксическое дерево, оно анализируется, по нему строятся другие бинарные структуры, отражающие семантику написанного. Текстуальное представление кода при этом вообще отбрасывается — когда IDE хочет отрисовать цветной код на экране или отдать его в буфер обмена, она воссоздаёт исходный код ровно для этой цели. Уже это делает VB/VBA языками, которые не имеют ничего общего с интерпретируемыми языками.
В отличие от интерпретируемых языков, которые разбираются и анализируются по мере исполнения программы, здесь разбор кода происходит даже не в момент запуска, а в момент набора кода!
Далее из высокоуровневых древовидных и графовидных структур, которые IDE использует для хранения кода внутри себя, нужные процедуры по принципу JIT компилируются в P-код — так называет байт-код виртуальной машины VB/VBA.
Результаты выполнения, если процедура не менялась, между перезапусками «проекта» не перекомпилируются.
VB же вдобавок умеет компилировать не в P-код, а в Native-код, то есть в машинный код x86-процессоров.
Если вы отбросите своё пренебрежительное отношение и реально захотите разобраться, то вам стоит прочитать несколько статей и несколько моих комментов, в которых я немного раскрыл тайны внутреннего мира VB.
Статьи:
Почему меня называют «отцом Visual Basic'а»
Перевод статьи Алана Купера о том, как он придумал технологию под названием Ruby (не путать с языком программирования Ruby), и как потом она стала частью VB (но не VBA)
§ 10. Ruby + EB = Visual Basic
Статья о том, как появился на свет VB как результат слияния двух технологий
(опционально) § 12. Сколько строк кода и файлов в исходниках самого VB?
Thunder... рождение Visual Basic
Перевод статьи одного из разработчиков VB о том, как они создавали Thunder, который позже стал VB со многими инсайдерскими фактами.
Комментарии:
https://habr.com/ru/articles/582566/comments/#comment_23578554
https://habr.com/ru/articles/582566/comments/#comment_23589108 (продолжение)
И ещё раз под конец: между VBA и VBScript общего намного меньше, чем вам кажется. По сути что-то общее есть толкьо на уровне названия и фасада, который виден пользователю. Изнутри это абсолютно разные продукты.
Давайте тогда прежде чем я буду приводить пруфы, вы приведёте чёткое и однозначное определение скриптового языка и его отличий от не-скриптового.
Подождите, я не говорю об IA-64 aka Itanium.
Я говорю о i386 и его плюшках — плюшках его защищённого режима. И не Интел облажался, а мировое сообщество, которое не стало всё это использовать.
Удобная для программистов вещь, но абсолютное зло с точки зрения изначальной идеологии защищённого режима — так называемая flat-модель организации памяти. В рамках одного процесса операционной системы абсолютно все данные «видны» любому коду в рамках процесса. Большинство данных в адресном пространстве процесса доступно для перезаписи абсолютно кому угодно (то есть какому угодно коду, оказавшемуся в рамках процесса, даже шелл-коду, который хакер заботливо загнал в переполнившийся буфер). Некоторые данные защищены от перезаписи на уровне защиты страниц, но это защита чисто номинальная, потому что снять её не составляет никакого труда.
Между тем защищённый режим x86 предполагает возможность сделать так, что каждый отдельно взятый кусок программы имеет доступ только к тем данным, с которыми ему дозволено работать. И не только данным, но и другому коду. То есть можно программу нарезать на маленькие куски, эдакие микромодули и каждый поместить в песочницу, в которой доступен минимально необходимый набор данных (и кода). Так, что комар не пролетит. Каждый буфер может иметь аппаратную защиту от доступа за его границу.
Но это потребовало бы совершенно иного программирования и других ЯП.
В точку! Стремление определенных людей любой ценой переписать все на якобы безопасный Раст напоминает утопическую идею вроде всемирного коммунизма или проекта Венера.
Тем временем, когда x86 со своим защищенным режимом (особенно 386+) предложила защиту на аппаратном уровне (которая поставила бы крест на атаках типа переполнения буфера, исполнения шелл-кода), никто толком не заценил технологию, не бросился имплементировать её и создавать новые ЯП под неё. В итоге развивать и оптимизировать эти плюшки Интел не стала, а в x86-64 они и вовсе попали под выпил.