Mikle писал(а):Я считал, что такие вещи встраиваются прямо в код игры разработчиками, что это не какой-то универсальный инструмент.
Ну так вообще
любые вещи встраиваются рямо в код проекта разработчиками. Не так ли? И мой гипотетический кирпич пришлось бы встраивать в код проекта тоже.
Если ты имеешь в виду то, что построение цепочки вызовов может быть реализовано путём того, что при входе в каждую процедуру в эту цепочку добавляется элемент, соответствующий процедуре, а при выходе из процедуры удаляется — то да, можно в том числе и так. Но это ведь чрезвычайно муторный и недружелюбный к программисту способ, ведь он требует учитывать все точки выхода из процедура, ибо можно пропустить такую, и в цепочке останется неактуальный элемент. Хотя программисту C++ будет легче, ведь у неё есть объекты с автоматическим контролем времени жизни.
Но вместо того, чтобы составлять цепочку вызовов «прижизненно» и тратить на это какие-то ресурсы, можно пойти кардинально другим путём: составить цепочку только в момент возникновения проблем, проанализировав стек вызов и сопоставив адресам человеко-понятные имена функций/модулей.
The trick писал(а):Хакер, а вообще реально добавить поддержку раскрывающихся макросов по типу __FUNCTION__ в VB6?
Тут два аспекта, которые меня волнуют. Технический и идеологический.
Начнём с технического. Сделать это можно разными путями, и весь вопрос в том, на какие меры у нас есть условный мандат. Если у нас есть доступ к исходникам VBA6.DLL, это одна ситуация — тут у нас карт-бланш на все действия, но идеологическая проблема никуда не уходит. Если у нас есть добро на то, чтобы сделать задуманной путём глубокой модификации VBA6.DLL и последующего распространения модифицированной библиотеки — это другая ситуация. Если нам не дают добро модифицировать VBA6.DLL, а предлагается сделать Add-in, который должен уметь добавлять новый функционал к любому билду VB6 — это третья, самая неблагоприятная и самая худшая ситуация. Поскольку первая ситуация близка к неосуществимой, рассмотрим вторую и третью.
В рамках второго и третьего подхода опять же есть большая вилка вариантов того, как можно реализовать задуманной. Можно залезть очень глубоко и на очень глубоком уровне добавить поддержку этих волшебных констант. Можно не лезть глубоко, а добиваться желаемого путём подмены кода на время компиляции и возврата всего на место на время отображения. Второй подход проще, но и в нём есть целый ворох проблем: перестаёт работать преимущество JIT-компиляции (с каждой добавленной строкой инвалидируется всё, что относится к далее расположенным процедурам), не понятно, как быть с Watch Window, некорректно будет работать поддержка Quick Info и подсказок со значением при наведении. Лучше бы конечно дождаться моей статьи о PCR- и BSCR-представлении кода в цикл
VB Internals. Проще было бы объяснять.
Теперь об идеологической составляющей. Я считаю, что делать такого уровня нововведения в VB6 можно только тогда, когда ты можешь назвать себя лидером реформаторского движения в отношении VB. Если твоё нововведение может стать стандартом если не де-юре, то хотя бы де-факто. В децентрализованной тусовке VB-программистов получится так, что каждый начнёт клепать свои нововведения, несовместимые с чужими нововведениями, в итоге будет куча вариантов примерно одинаковых новшеств, взаимонесовместимых друг с другом. Это окончательно добьёт и так неважно поживающий VB.
Я также очень плохо отношусь к любым примочкам к VB, за счёт которых проекты и исходники становятся принципиально некомпилируемыми на чистом VB6 без примочек. Либо нужно как-то выпускать VB 6.1 (VB 6.5, VB, 6Ext — как назвать вопрос другого порядка) и заявлять, что новые проекты и исходники не будут обратно совместимыми со старыми IDE, либо нужно доработки с обратносовместимым подходом, чтобы код, написанный для VB с примочками не превращался в некомпилируемую катастрофу для IDE без примочек. Даже когда я 13 лет назад делал FNDLL, я придерживался этого принципа — если FNDLL не установлен, проект заточенный под FNDLL нормально и безболезненно компилировался, просто у него экспортируемых функций. И то, успешно скомпилированный таким образом бинарник можно было пост-обработь пост-обработчиком (мимикрирующим под линкер в штатной установке FNDLL), который добавит экспорты.
Другой идеологический аспект — это правильный для VB6 стиль. Уверен, что
__FUNCTION__ таким не является, хотя и понимаю, что это был скорее всего пример по аналогии с C/C++.
__FUNCTION__ не пройдёт хотя бы просто потому, что такой токен не пройдёт через парсер VB6, он синтаксически не совместим с правилами разбора VB-кода. Если брать что-то типа
FUNCTION, то рискуем получить коллизию с чужим кодом, где такая константа живёт на общих правах. Самое «трушное» с точки зрения VB было бы сделать
Debug.LineNumber и
Debug.ModuleName. Но это требует очень глубокого вмешательства.
