А что делать, если мне не сложно читать первую запись? Куда обратиться? А вот вторая запись, напротив, вызывает вопросы.
Во-втором примере я не вижу, куда спряталась информация о типе возврата функции, указатель на которую передаётся. Или функции 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 они и вовсе попали под выпил.
Давайте изучим. Я живу в Казахстане. Казахстан относится к СНГ. Наблюдаю грёбаную рекламу на YouTube по сто раз в каждый грёбаный день.
Похоже, вы просчитались... но где? Может Казахстан уже не входит в СНГ? Может я нахожусь не в Казахстане, а в Тридевятом царстве?
Да и, собственно, может включить логику? Реклама для YT является основным двигателем их бизнеса. С какой стати YT должны отказываться от своего хлеба на значительной территории земного шара из-за проделок всего лишь какой-то одной страны-участницы?
Что за глупость? Потому что первая буква у СНГ и СВО совпадает, или по какой ещё причине гугл должен не показывать узбекистанцу или гражданину груши рекламу, которую всегда показывал?
Если что, я с железками вожусь эпизодически, а в основном делаю софт - на VS 2008, винда у меня семерка, а офис вообще 2000. :)
VS 6.0, XP, Office 2003. Нам будет, о чём поговорить ;-)
А так-то, и чугунный утюг, в который засыпались угли - тоже нагревательный прибор, но мне почему-то кажется, что Вы предпочтете гладить электрическим. :)
Ну так у него качественное отличие. У чугунного с углями нет стабилизации температуры. Справедливости ради, должен сказать, что многим людям тяжеленные утюги нравится использовать больше, нежели супер-лёгкие (и дозировать давление рукой).
Они очень большие, тяжелые, а внутри - полупустые.
А почему тяжесть (и размер) это плохо? Тяжесть это однозначно плохо, только если инструмент походный и его нужно постоянно носить с собой. Станция же инструмент стационарный, и тяжесть ему только на пользу. Меня вот жутко бесит, что мой осциллограф слишком лёгкий — при попытке нажать на кнопки или кнобы вместо собственно нажатия происходит уползание осциллографа назад. Хоть утяжелители ставь.
Размер корпуса по глубине продиктован тем, что часть корпуса (и раньше, и сейчас) занимает силовой трансформатор, а другую часть раньше (до fan-версий) занимала диафрагмальная помпа. Размер же корпуса по ширине и высоте обусловлен передней панелью, и я бы не хотел, чтобы передняя панель становилась меньше, потому что не хочется прицеливать по маленьким элементам управления и разглядывать что-то на очень маленьких индикаторах.
Мне нравится квадратный параллелепипедный дизайн Lukey 852 — её можно ставить впритык к другому оборудованию и у тебя не появляется дурацких карманов и промежуткой между оборудованием. Верхняя часть корпуса плоская, а не полукруглая — можно снять ручку для переноса и поставить что-то сверху (я у себя именно так и сделал).
Отдельно хочется сказать, что если бы станция была кратно легче, то с учётом того, что на корпусе станции есть держатель для фена, то при попытке положить фен в держатель с размаху — станция бы имела тенденцию к опрокидыванию.
Кроме того, цельнометаллический корпус — это тоже хорошо. Во-первых, если не получится случайно проплавить паяльником или феном. Во-вторых, это клетка фарадея. Мне бы не хотелось, если бы при ремонте/отладки какой-то аппаратуры, способной генерировать весьма мощные помехи (например это может быть электрошокер, сварочный аппарат, эппарат для электроэрозионной обработки) мозги станции словили помеху и в лучшем случае зависли, а в худшем сошли с ума.
но Вы ж зачем-то упомянули цену, а стоят они сейчас 8-10 тысяч.
Затем, что комментатор несколькими уровнями выше назвал станцию за 65 366 рублей не дорогой. Возможно, ему стоит прочитать статью про пузыри, раз в его мире 65k это «недорого». На что и была приведена в качестве примера станция, которая на порядок дешевле, но не на порядок хуже.
Я не мониторил цены на Luckey 852 на текущий момент, в своё время я купил её за 3500 рублей. По сравнению с этой ценой 65K это даже не в 10, а в 20 раз дешевле. Но в 20 ли раз хуже, особенно учитывая, что фена там нет?
В любом случае, 65K не выглядит как «дёшево» — в некоторых регионах СНГ это 3 месячных зарплаты.
Далее, о законах физики: паяльники серии 900 убоги прежде всего потому, что имеют воздушный зазор между жалом и нагревателем/датчиком
А о каком зазоре речь? Радиальном или аксиальном? Аксиальный — это баг производителя, люди давно знают, как его фиксить. Что касается радиального, то зазоры и, как следствие, люфты, это общая практика для любой техники, работающей в широком диапазоне температур. Иначе бы жало заклинило на нагревателе и его было бы невозможно поменять. Учитывая тонкие длинные носики у жал, я бы не так категорично заявлял, что температурное сопротивление нагреватель-жало доминирует над сопротивлением тонкого носика и пятном контакта между носиком и каплей припоя.
Кроме того, почему убогой называется именно 900-ая серия? Так в принципе были устроены все жала всех паяльников и станций. У меня есть японский Goot PX-201. Там несовместимое с Люкеем жало, но оно принципиально такое же. Goot тоже убогая фирма с убогими изделиями?
Из-за этого их для более-менее комфортной пайки приходится перегревать до 300-400
Ну не знаю, SMD мелочь не отягощённую земляными полигонами (а особенно без thermal reliefs) я паяю, выставляя 270-280 градусов. Что-то более массивное — ставлю 330. Для тяжёлых условий можно организовать помощь в виде подогрева феном. Или нижним предподогревом, у кого есть.
Эффект от подогревания региона платы, в котором осуществляется пайка, до хотя бы половины рабочей температуры, намного лучше и выраженнее, чем от самой чуткой петли обратной связи по температуре, накрученной на очень мощный нагреватель. Потому что тепловое сопротивление пятна контакта жало-припой, соизмеримое с тепловым сопротивлением, через которой тепло утекает в более холодные регионы, не победить ничем (то есть не победить характеристиками паяльника, но легко победить устранением холодных регионов, куда тепло может интенсивно утекать).
поэтому ими обычно паяют в две руки: в одной - паяльник, в другой - припой
Припои с flux core внутри, то есть практически все припои так и должны паяться. В ином случае, если набрать на жало каплю и ждать полчаса, весь флюс в любом случае успевает испариться и это равносильно пайки вообще без флюса.
Придумываешь ключ, который полностью описывает кейс, назначаешь значение из базовой палитры — готово. Такой способ декларативен, но когда используешь токены каждый день, появляется ряд неудобств
Это цепи Маркова что ли сгенерировали этот поток слов?
Это преувеличение. Для этого нужно давление порядка сотен бар (чего априори не будет в разводке жилых и общественных зданий) и сопло надлежащей формы.
А что делать, если мне не сложно читать первую запись? Куда обратиться? А вот вторая запись, напротив, вызывает вопросы.
Во-втором примере я не вижу, куда спряталась информация о типе возврата функции, указатель на которую передаётся. Или функции 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 они и вовсе попали под выпил.
Давайте изучим. Я живу в Казахстане. Казахстан относится к СНГ. Наблюдаю грёбаную рекламу на YouTube по сто раз в каждый грёбаный день.
Похоже, вы просчитались... но где? Может Казахстан уже не входит в СНГ? Может я нахожусь не в Казахстане, а в Тридевятом царстве?
Да и, собственно, может включить логику? Реклама для YT является основным двигателем их бизнеса. С какой стати YT должны отказываться от своего хлеба на значительной территории земного шара из-за проделок всего лишь какой-то одной страны-участницы?
Что за глупость? Потому что первая буква у СНГ и СВО совпадает, или по какой ещё причине гугл должен не показывать узбекистанцу или гражданину груши рекламу, которую всегда показывал?
ОН НЕ СКРИПТОВЫЙ!
VS 6.0, XP, Office 2003. Нам будет, о чём поговорить ;-)
Ну так у него качественное отличие. У чугунного с углями нет стабилизации температуры. Справедливости ради, должен сказать, что многим людям тяжеленные утюги нравится использовать больше, нежели супер-лёгкие (и дозировать давление рукой).
А почему тяжесть (и размер) это плохо? Тяжесть это однозначно плохо, только если инструмент походный и его нужно постоянно носить с собой. Станция же инструмент стационарный, и тяжесть ему только на пользу. Меня вот жутко бесит, что мой осциллограф слишком лёгкий — при попытке нажать на кнопки или кнобы вместо собственно нажатия происходит уползание осциллографа назад. Хоть утяжелители ставь.
Размер корпуса по глубине продиктован тем, что часть корпуса (и раньше, и сейчас) занимает силовой трансформатор, а другую часть раньше (до fan-версий) занимала диафрагмальная помпа. Размер же корпуса по ширине и высоте обусловлен передней панелью, и я бы не хотел, чтобы передняя панель становилась меньше, потому что не хочется прицеливать по маленьким элементам управления и разглядывать что-то на очень маленьких индикаторах.
Мне нравится
квадратныйпараллелепипедный дизайн Lukey 852 — её можно ставить впритык к другому оборудованию и у тебя не появляется дурацких карманов и промежуткой между оборудованием. Верхняя часть корпуса плоская, а не полукруглая — можно снять ручку для переноса и поставить что-то сверху (я у себя именно так и сделал).Отдельно хочется сказать, что если бы станция была кратно легче, то с учётом того, что на корпусе станции есть держатель для фена, то при попытке положить фен в держатель с размаху — станция бы имела тенденцию к опрокидыванию.
Кроме того, цельнометаллический корпус — это тоже хорошо. Во-первых, если не получится случайно проплавить паяльником или феном. Во-вторых, это клетка фарадея. Мне бы не хотелось, если бы при ремонте/отладки какой-то аппаратуры, способной генерировать весьма мощные помехи (например это может быть электрошокер, сварочный аппарат, эппарат для электроэрозионной обработки) мозги станции словили помеху и в лучшем случае зависли, а в худшем сошли с ума.
Затем, что комментатор несколькими уровнями выше назвал станцию за 65 366 рублей не дорогой. Возможно, ему стоит прочитать статью про пузыри, раз в его мире 65k это «недорого». На что и была приведена в качестве примера станция, которая на порядок дешевле, но не на порядок хуже.
Я не мониторил цены на Luckey 852 на текущий момент, в своё время я купил её за 3500 рублей. По сравнению с этой ценой 65K это даже не в 10, а в 20 раз дешевле. Но в 20 ли раз хуже, особенно учитывая, что фена там нет?
В любом случае, 65K не выглядит как «дёшево» — в некоторых регионах СНГ это 3 месячных зарплаты.
А о каком зазоре речь? Радиальном или аксиальном? Аксиальный — это баг производителя, люди давно знают, как его фиксить. Что касается радиального, то зазоры и, как следствие, люфты, это общая практика для любой техники, работающей в широком диапазоне температур. Иначе бы жало заклинило на нагревателе и его было бы невозможно поменять. Учитывая тонкие длинные носики у жал, я бы не так категорично заявлял, что температурное сопротивление нагреватель-жало доминирует над сопротивлением тонкого носика и пятном контакта между носиком и каплей припоя.
Кроме того, почему убогой называется именно 900-ая серия? Так в принципе были устроены все жала всех паяльников и станций. У меня есть японский Goot PX-201. Там несовместимое с Люкеем жало, но оно принципиально такое же. Goot тоже убогая фирма с убогими изделиями?
Ну не знаю, SMD мелочь не отягощённую земляными полигонами (а особенно без thermal reliefs) я паяю, выставляя 270-280 градусов. Что-то более массивное — ставлю 330. Для тяжёлых условий можно организовать помощь в виде подогрева феном. Или нижним предподогревом, у кого есть.
Эффект от подогревания региона платы, в котором осуществляется пайка, до хотя бы половины рабочей температуры, намного лучше и выраженнее, чем от самой чуткой петли обратной связи по температуре, накрученной на очень мощный нагреватель. Потому что тепловое сопротивление пятна контакта жало-припой, соизмеримое с тепловым сопротивлением, через которой тепло утекает в более холодные регионы, не победить ничем (то есть не победить характеристиками паяльника, но легко победить устранением холодных регионов, куда тепло может интенсивно утекать).
Припои с flux core внутри, то есть практически все припои так и должны паяться. В ином случае, если набрать на жало каплю и ждать полчаса, весь флюс в любом случае успевает испариться и это равносильно пайки вообще без флюса.
Это цепи Маркова что ли сгенерировали этот поток слов?