Рассуждения на тему: X++ компилируемый или интерпретируемый язык?

[sukhanchik]

******* Выделено отсюда DAX40 #if.never в LedgerBondServer_RU ********

Цитата:

Сообщение от DSPIC

Да, увидел, но только после перезапуска клиента (40sp2).

Хм... А я увидел сразу.... Та же самая версия - 4.0 SP2. Безо всяких там перезапусков.

Цитата:

Сообщение от DSPIC

Цитата:

Сообщение от sukhanchik

При попытке удаления и создания метода - вызов saveLast() все равно "разрешается" в любом методе - что приводит к выводу - что этот метод в откомпилированном коде сохраняется при самом объекте (метод saveLast и только он был скопирован с родителя, но не был удален при отвязке родителя).

Это скорее догадка, чем вывод.

Да, скорее догадка, но факт остается фактом.

Цитата:

Сообщение от DSPIC

Проверить не получилось, в UtilElements методы базового класса не добавляются. Возможно они привязываются в откомпилированном коде, но при этом компилятор X++ уверенно прыгает в исходник базового класса (Lookup definition). Но и это можно объяснить...

Не... исходный код никто и не трогает. Я просто провожу параллель со сборкой exe-шника. При сборке из командной строки - в exe-шник копируются куча библиотек, причем можно задать - копировать их, либо использовать только ссылки (в последнем случае exe-шник не запустится без наличия библиотек).
Если взглянуть - сколько всего "пихается" в простой exe-шник на С++ Builder в простой программе Hello world... - то невольно подумаешь - что тут тоже самое. Ведь братья дамгарды не писали с нуля свой компилятор - они (насколько мне рассказывали) - взяли некие заготовки - ведь почему X++ так удивительно похож на Java и С++, а не на бейсик, паскаль, фортран и т.д.

Для отладчика добавляется специальная отладочная информация (и это тоже одна из опций компилятора) - поэтому на нее нельзя ориентироваться. Кстати - перед финальной сборкой exe-шника эту отладочную информацию обязательно удаляют (выполняют сборку без указания спецключика) для того, чтобы не давать легкую возможность дизассемблировать + уменьшить размер файла.

Цитата:

Сообщение от DSPIC

Если я правильно понял, то каждый откомпилированный метод хранит код родителя+свой код. Точнее сказать UtilElements хранит. А Вы к этому как пришли? Это общий механизм компиляторов? По крайней мере, UtilElements.source содержит код 1:1 как в AOT.

Как я уже описал выше - я пришел к выводу на основе работы C++-ного компилятора еще в досе. Плюс пообщался на эту тему еще со своими приятелями (разработчиками в аксапте, которые видели исходные сишные коды ax32.exe) - которые независимо от меня пришли к такому же мнению. А т.к. 2 абсолютно независимых человека пришли к одинаковым выводам - я обрел некоторую уверенность в своей гипотезе.

Тем более, что внешние симптомы не позволяют в ней сомневаться.

Цитата:

Сообщение от DSPIC

Я таки залез в \Classes\xRefUpdate. Оказывается, не в перекрёстных ссылках дело, а в банальном

Dictionary::aodFlush();

А вот это вот здравая мысль. Аксапта (4-ка) сбрасывает все напрограммированные изменения в axapd.aoi. И только после рестарта АОСа - видно как изменились размеры aod-шников. Хотя я сам видел такой эффект, что после выхода всех пользователей из приложения - приложение копируейтся со всеми изменениями и без рестарта АОСа. Но изменение aod-шников происходит только после рестарта аоса (посмотрите размер и дату изменения файлов)
В данном случае - происходит видимо какая-то перечитка (возможно из axapd.aoi перечитывается UtilElements - не знаю) , после чего все становится в норме.

Цитата:

Сообщение от DSPIC

Т.е. для автора темы: попробуйте просто обновить AOD (Tools->DevelopmnetTools->ApplicationObjects->Refresh AOD), затем откомпилировать класс.

sukhanchik, не знаю, как это решение ложится на описанный Вами механизм хранения откомпилированного кода.
По большому счету, это всё не так уж важно: как оно там хранится, и как это всё можно объяснить - это более низкий уровень. Главное, что есть проблема (будем надеяться, что её пофиксят) и найдено простое решение. Глобальная компиляция - это пушкой по воробьям.

Не думаю, что ее пофиксят. Мне кажется - это больше фича... Тем более - что я к примеру за весь свой стаж с этой проблемой ни разу не сталкивался.
Плюс - предлагаемая методология ведения разработки исключает как правило эти грабли.

Ошибка может проявляться только ведь на разработческой. Разработческую нужно регулярно глобально компилить с построением перекрестных ссылок (например, ночью). Плюс - разработческое приложение - периодически обновляется приложением с рабочей (тестовой). Во время обновления аос естественно останавливается.

Поэтому - думаю, что на это просто надо обратить внимание при разработке. Но не более.

Глобальная компиляция - вещь полезная и не сильно долгая. Поэтому ее полезно периодически запускать.