О бедных классах замолвите...

Создание приложений, библиотек, инсталляторов
Ответить
Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

О бедных классах замолвите...

Сообщение Artem.spb »

И снова тяжкие думы на тему "класс или не класс".

Ситуация:
Есть некий (мой) модуль с интерфейсом и богатым внутренним миром. И в этом мире активно живут разные классы (и акторы). Маленький скромный модуль. Пусть он будет модуль А.
И в модуле А у одного из классов есть саб, который из файла извлекает техническую информацию. пусть он будет Finfo

Появляется большой проект (большой бос - ББ), который начинает эксплуатировать этого простого скромного работягу, встраивая к себе в subpanel и заодно увёл в рабство его детей, а точнее, пока только одного единственного Finfo.

Итого.
Есть А (библиотека с набором классов) и саб однго из классов Finfo.
Есть ББ - большая программа, которая встраивает А И заодно в своих функциях использует Finfo.
В исходниках всё нормально работает, но начинаем компилировать и появляются проблемы.
Снимок.PNG
Дошли до простого теста: компилируем минимально рабочий кусок ББ, который использует Finfo, проблема та же.
Если удалить вызов Finfo тест компилируется успешно.

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

дебаг включаем, компилируется успешно, но программа получается ломанной.
Подключаемся к ней дебагером, и в исходниках видим "всё пропало" в прямом смысле: ни одного саба нет, все как бы потеряны.

Получается, что нельзя использовать сабы класса (не приватные) вне класса при некоторых обстоятельствах?
Ситуация усугубилась после экспорта.
Сначала для проверки концепции в ББ встраивали оригинал А, после успешного теста решили сделать клон А (АА), потому что надо будет немного ковырять АА. И вот после этго всё сломалось. Клон делал автоматом через "сохранить как..."
Вызовы перепроверили три раза. Для надёжности даже на этой машине удалили полностью папку А, так что ББ вызывает только АА, в исходниках всё работает, а в сборке ломается.

Есть идеи или рецепты лечения?

Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
professor
professor
Сообщения: 4922
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Репутация: 0
Версия LabVIEW: 2015, 2016
Откуда: СССР

Re: О бедных классах замолвите...

Сообщение IvanLis »

Artem.spb писал(а):
30 апр 2020, 14:36
Получается, что нельзя использовать сабы класса (не приватные) вне класса
Недавно сталкивался с аналогичной проблемой и пришел примерно к такому же выводу :wink: .
Сделал Sub и поместил его внутрь Класса, потом вдруг понадобилось выполнить аналогичную функцию в другом классе, я дернул эту Sub туда, сразу проблемы не видно, а потом ушло пару часов на ее локализацию.

Переделывал следующим образом, как правило Класс мы собираем внутрь Библиотеки (***.lvlib)...
Я вынес все Sub из класса и собрал их в отдельной (виртуальной) папке Библиотеки за пределами Класса, а рядом (в той же Библиотеке) разместил Класс.

Так заработало нормально.
Потом правда пришлось создавать в Классе для каждой функции метод и в него кидать Sub, немного лишних и необоснованных телодвижений :dntknw:

Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Artem.spb »

IvanLis писал(а):
30 апр 2020, 15:52
, немного лишних и необоснованных телодвижений :dntknw:
это я бы назвал "много лишних". Странно, что классы так себя ведут. И ещё более странно, что на форумах такой проблемы не встречал.

ujin
junior
junior
Сообщения: 68
Зарегистрирован: 28 июл 2019, 13:16
Репутация: 0
Версия LabVIEW: 19
Контактная информация:

Re: О бедных классах замолвите...

Сообщение ujin »

Artem.spb писал(а):
30 апр 2020, 14:36
Появляется большой проект (большой бос - ББ), который начинает эксплуатировать этого простого скромного работягу, встраивая к себе в subpanel и заодно увёл в рабство его детей, а точнее, пока только одного единственного Finfo.
Есть идеи или рецепты лечения?
Не увидел в Вашем описание инициализацию child Finfo. Где-то должен появиться объект этого класса и родителя.
В темах channeling pattern и factory pattern, что-то похожее рассматривается.
Я делал рабочий пример из aggregation pattern. Везде классы размещены (инициализированы) на диаграмме.
Сбор детей в кучу
child.png

Вызов по одному через родителя
call child.png

Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Artem.spb »

ujin писал(а):
04 май 2020, 09:18
Не увидел в Вашем описание инициализацию child Finfo. Где-то должен появиться объект этого класса и родителя.
несмотря на то, что бедолагу нещадно эксплуатируют, он никому ничего не должен.
Это НЕ метод класса, это просто саб.
Например, в классе часто перевожу м<->мкм и чтобы каждый раз не вспоминать степень, делаю простой саб, который делает это.
Ему не нужен провод всего класса, он просто принимает на вход одно число, выдаёт другое.

Finfo примерно так же устроен. На входе имя файла (строка), на выходе - кластер параметров. К свойствам класса опять же привязки нет, так что и создавать объект нет надобности.

Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1067
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Репутация: 0
Версия LabVIEW: 2013-2017
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Kosist »

Artem.spb писал(а):
30 апр 2020, 14:36
Снимок.PNG
А Вы пробовали не удалять блок-диаграмму во время билда, как предложено в описании ошибки?
Так же, FInfo "тянет" за собой еще какие-то зависимости, кроме своего класса?
IvanLis писал(а):
30 апр 2020, 15:52
Artem.spb писал(а):
30 апр 2020, 14:36
Получается, что нельзя использовать сабы класса (не приватные) вне класса
Недавно сталкивался с аналогичной проблемой и пришел примерно к такому же выводу :wink: .
Странно, никогда такой проблемы не видел, хотя классы использую активно. Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс? Если нужно копировать - то лучше сделать Save As..., потом удалить клон из класса, перенести виайку в нужную папку, а потом добавить в новый класс при помощи Add Item.
Подобные проблемы случаются если есть путаница в Dependencies - виайки из одного проекта ссылаются на другой проект, а потом при создании exe одинаковые зависимости подтягиваются из разных мест, и получается ошибка. Ну, или компилятор не может найти нужные зависимости в рамках этого проекта.
Мы делили апельсин - много наших полегло...

Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
professor
professor
Сообщения: 4922
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Репутация: 0
Версия LabVIEW: 2015, 2016
Откуда: СССР

Re: О бедных классах замолвите...

Сообщение IvanLis »

Kosist писал(а):
04 май 2020, 14:42
Странно, никогда такой проблемы не видел, хотя классы использую активно. Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
Повторить баг слету не вышло...
Но возникает именно в случае использования Sub из одного класса в другом.
Сейчас в голову пришло, что нужно было попробовать функцию реентерабельной сделать...
Снимок экрана от 2020-05-04 21-00-09.png
Project2015.7z
(47.38 КБ) 4 скачивания
Kosist писал(а):
04 май 2020, 14:42
Странно, никогда такой проблемы не видел, хотя классы использую активно. Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
Бывает, что изначально не планируется использование Sub в другом классе.
Но чисто машинально, взял и перенес.
Копировать... как-то неправильно с точке зрения модульности кода :crazy: , особенно если они постоянно модифицируются...
Я например напоролся на это, когда делал прогу для работы с различным железом и так получилось, что у двух железяк (классов), правило разбора посылки совпало. Вот я и дернул Sub из одного класса в другой.

Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Artem.spb »

Kosist писал(а):
04 май 2020, 14:42
А Вы пробовали не удалять блок-диаграмму во время билда, как предложено в описании ошибки?
пробовал, не помогло. "помогло" добилдить, но при запуске еxe сообщает, что он битый, а если залезть туда отладчиком, то все сабы "пропали".
Kosist писал(а):
04 май 2020, 14:42
Так же, FInfo "тянет" за собой еще какие-то зависимости, кроме своего класса?
Нет, он даже свой класс не тянет.
Снимок.PNG
Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
первое. и даже не оно.
Я вытаскивал данные из имени файла. В большом проекте понадобилось сделать то же самое. Вязи и вызвали оттуда эхтот саб, передав ему имя файла.

Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1067
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Репутация: 0
Версия LabVIEW: 2013-2017
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Kosist »

IvanLis писал(а):
04 май 2020, 21:14
Копировать... как-то неправильно с точке зрения модульности кода :crazy: , особенно если они постоянно модифицируются...
А вот тут уже как посмотреть - ведь используя виайку одного класса в другом мы как раз эту модулярность (на уровне классов) теряем, ведь второй класс уже не может "жить" без первого. Это нормально если первый класс - его "родитель", но если они "братья/сестры" - то лишняя зависимость...
Artem.spb писал(а):
05 май 2020, 00:02
Я вытаскивал данные из имени файла. В большом проекте понадобилось сделать то же самое. Вязи и вызвали оттуда эхтот саб, передав ему имя файла.
На блок диаграмме есть функция с иконкой "M2Hz" - она тоже часть первого класса? Или она где-то в другом месте? С ней не может быть связана проблема?
Мы делили апельсин - много наших полегло...

Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
professor
professor
Сообщения: 4922
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Репутация: 0
Версия LabVIEW: 2015, 2016
Откуда: СССР

Re: О бедных классах замолвите...

Сообщение IvanLis »

Kosist писал(а):
05 май 2020, 00:41
А вот тут уже как посмотреть - ведь используя виайку одного класса в другом мы как раз эту модулярность (на уровне классов) теряем, ведь второй класс уже не может "жить" без первого. Это нормально если первый класс - его "родитель", но если они "братья/сестры" - то лишняя зависимость...
Ну...
Видимо я выбрал правильный путь :wink:
Я вынес все Sub из класса и собрал их в отдельной (виртуальной) папке Библиотеки за пределами Класса, а рядом (в той же Библиотеке) разместил Класс.

ujin
junior
junior
Сообщения: 68
Зарегистрирован: 28 июл 2019, 13:16
Репутация: 0
Версия LabVIEW: 19
Контактная информация:

Re: О бедных классах замолвите...

Сообщение ujin »

Artem.spb писал(а):
05 май 2020, 00:02
Нет, он даже свой класс не тянет.
Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
первое. и даже не оно.
Я вытаскивал данные из имени файла. В большом проекте понадобилось сделать то же самое. Вязи и вызвали оттуда эхтот саб, передав ему имя файла.
Если этот Саб является членом класса, компилятор будет знать откуда его загружать только через класс. Если класс не инициализирован (нигде не поставлен OBJ на диаграмме и нет ссылки) компилятор его не загрузит.
Простой SubVi попавший в класс это уже не простой SubVi, он обрастает разными зависимостями. При копировании этого SubVi через проводник Windows он работать не будет, а будет браться из класса (обросший зависимостями). Это как показатель что есть зависимости.
Получается, что во время разработки компилятор берет SubVi из загруженных в память. А при компиляции *.exe временные ссылки не действуют.
Если посмотреть View -> Browse Relationships -> Unopened Type Defs там должен быть Ваш класс, в который вошел FInfo.
Опять же зачем Вам FInfo как член класса и почему бы не принять прозвучавшее выше предложение вынести его в отдельную библиотеку?
Мое мнение о использовании классов (по возможности меньше) учитывает мнение Линуса Торвальдса о С++ "... Я смотрю на объект, и НИКОГДА не могу сказать, нужно ли мне в вызывающем контексте передавать в конструктор явно сделанную копию например строки или структуры, или оно внутри там само все скопирует. И таких сложных для использования и понимания моментов много." https://mfonin.livejournal.com/419857.html

Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Artem.spb »

Kosist писал(а):
05 май 2020, 00:41
На блок диаграмме есть функция с иконкой "M2Hz" - она тоже часть первого класса? Или она где-то в другом месте? С ней не может быть связана проблема?
живёт само по себе

Artem.spb

Activity Автор
expert
expert
Сообщения: 1874
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Репутация: 0
Версия LabVIEW: 12-18
Контактная информация:

Re: О бедных классах замолвите...

Сообщение Artem.spb »

ujin писал(а):
05 май 2020, 09:55
Опять же зачем Вам FInfo как член класса и почему бы не принять прозвучавшее выше предложение вынести его в отдельную библиотеку?
потому что гладиолус.
Я эту функцию для "себя" писал, и сначала никаких разговоров про внедрение в другие проекты не было, а потом линия партии сделала резкий поворот.
И начали делать по-простому.
Получается, что во время разработки компилятор берет SubVi из загруженных в память. А при компиляции *.exe временные ссылки не действуют.
я и не прошу компилятор сделать временные.
Я ставил галки "ужать всё по максимуму" именно для того, чтобы компилятор повыкидывал всё из класса (если уж хочет его оставить) и отправил в сборку только нужные функции.

Проблема возможно решается снятием чрезмерных галок. Т.е. не надо удалять всё лишнее. Но это пока не достоверно, потому что вызывающую сторону тоже поковыряли.

ujin
junior
junior
Сообщения: 68
Зарегистрирован: 28 июл 2019, 13:16
Репутация: 0
Версия LabVIEW: 19
Контактная информация:

Re: О бедных классах замолвите...

Сообщение ujin »

Artem.spb писал(а):
05 май 2020, 13:39
потому что гладиолус.
Согласен. Я слегка нарушил правила форума.

Ответить

Вернуться в «Создание приложений»