О бедных классах замолвите...
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
О бедных классах замолвите...
И снова тяжкие думы на тему "класс или не класс".
Ситуация:
Есть некий (мой) модуль с интерфейсом и богатым внутренним миром. И в этом мире активно живут разные классы (и акторы). Маленький скромный модуль. Пусть он будет модуль А.
И в модуле А у одного из классов есть саб, который из файла извлекает техническую информацию. пусть он будет Finfo
Появляется большой проект (большой бос - ББ), который начинает эксплуатировать этого простого скромного работягу, встраивая к себе в subpanel и заодно увёл в рабство его детей, а точнее, пока только одного единственного Finfo.
Итого.
Есть А (библиотека с набором классов) и саб однго из классов Finfo.
Есть ББ - большая программа, которая встраивает А И заодно в своих функциях использует Finfo.
В исходниках всё нормально работает, но начинаем компилировать и появляются проблемы. Дошли до простого теста: компилируем минимально рабочий кусок ББ, который использует Finfo, проблема та же.
Если удалить вызов Finfo тест компилируется успешно.
вопрос: что с этим делать?
Поиск даёт в основном три рецепта:
- включить дебаг (самый бесполезный, об этом ниже)
- отключиться от всех typedef и сократить всё по минимуму - не помогло
- очистить кэш компилятора - не помогло
- принудительно добавить в сборку библиотеку - не помогло.
дебаг включаем, компилируется успешно, но программа получается ломанной.
Подключаемся к ней дебагером, и в исходниках видим "всё пропало" в прямом смысле: ни одного саба нет, все как бы потеряны.
Получается, что нельзя использовать сабы класса (не приватные) вне класса при некоторых обстоятельствах?
Ситуация усугубилась после экспорта.
Сначала для проверки концепции в ББ встраивали оригинал А, после успешного теста решили сделать клон А (АА), потому что надо будет немного ковырять АА. И вот после этго всё сломалось. Клон делал автоматом через "сохранить как..."
Вызовы перепроверили три раза. Для надёжности даже на этой машине удалили полностью папку А, так что ББ вызывает только АА, в исходниках всё работает, а в сборке ломается.
Есть идеи или рецепты лечения?
Ситуация:
Есть некий (мой) модуль с интерфейсом и богатым внутренним миром. И в этом мире активно живут разные классы (и акторы). Маленький скромный модуль. Пусть он будет модуль А.
И в модуле А у одного из классов есть саб, который из файла извлекает техническую информацию. пусть он будет Finfo
Появляется большой проект (большой бос - ББ), который начинает эксплуатировать этого простого скромного работягу, встраивая к себе в subpanel и заодно увёл в рабство его детей, а точнее, пока только одного единственного Finfo.
Итого.
Есть А (библиотека с набором классов) и саб однго из классов Finfo.
Есть ББ - большая программа, которая встраивает А И заодно в своих функциях использует Finfo.
В исходниках всё нормально работает, но начинаем компилировать и появляются проблемы. Дошли до простого теста: компилируем минимально рабочий кусок ББ, который использует Finfo, проблема та же.
Если удалить вызов Finfo тест компилируется успешно.
вопрос: что с этим делать?
Поиск даёт в основном три рецепта:
- включить дебаг (самый бесполезный, об этом ниже)
- отключиться от всех typedef и сократить всё по минимуму - не помогло
- очистить кэш компилятора - не помогло
- принудительно добавить в сборку библиотеку - не помогло.
дебаг включаем, компилируется успешно, но программа получается ломанной.
Подключаемся к ней дебагером, и в исходниках видим "всё пропало" в прямом смысле: ни одного саба нет, все как бы потеряны.
Получается, что нельзя использовать сабы класса (не приватные) вне класса при некоторых обстоятельствах?
Ситуация усугубилась после экспорта.
Сначала для проверки концепции в ББ встраивали оригинал А, после успешного теста решили сделать клон А (АА), потому что надо будет немного ковырять АА. И вот после этго всё сломалось. Клон делал автоматом через "сохранить как..."
Вызовы перепроверили три раза. Для надёжности даже на этой машине удалили полностью папку А, так что ББ вызывает только АА, в исходниках всё работает, а в сборке ломается.
Есть идеи или рецепты лечения?
-
IvanLis
- guru
- Сообщения: 5462
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 86 раз
Re: О бедных классах замолвите...
Недавно сталкивался с аналогичной проблемой и пришел примерно к такому же выводу .
Сделал Sub и поместил его внутрь Класса, потом вдруг понадобилось выполнить аналогичную функцию в другом классе, я дернул эту Sub туда, сразу проблемы не видно, а потом ушло пару часов на ее локализацию.
Переделывал следующим образом, как правило Класс мы собираем внутрь Библиотеки (***.lvlib)...
Я вынес все Sub из класса и собрал их в отдельной (виртуальной) папке Библиотеки за пределами Класса, а рядом (в той же Библиотеке) разместил Класс.
Так заработало нормально.
Потом правда пришлось создавать в Классе для каждой функции метод и в него кидать Sub, немного лишних и необоснованных телодвижений
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: О бедных классах замолвите...
это я бы назвал "много лишних". Странно, что классы так себя ведут. И ещё более странно, что на форумах такой проблемы не встречал.
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: О бедных классах замолвите...
Не увидел в Вашем описание инициализацию child Finfo. Где-то должен появиться объект этого класса и родителя.
В темах channeling pattern и factory pattern, что-то похожее рассматривается.
Я делал рабочий пример из aggregation pattern. Везде классы размещены (инициализированы) на диаграмме.
Сбор детей в кучу
Вызов по одному через родителя
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: О бедных классах замолвите...
несмотря на то, что бедолагу нещадно эксплуатируют, он никому ничего не должен.
Это НЕ метод класса, это просто саб.
Например, в классе часто перевожу м<->мкм и чтобы каждый раз не вспоминать степень, делаю простой саб, который делает это.
Ему не нужен провод всего класса, он просто принимает на вход одно число, выдаёт другое.
Finfo примерно так же устроен. На входе имя файла (строка), на выходе - кластер параметров. К свойствам класса опять же привязки нет, так что и создавать объект нет надобности.
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: О бедных классах замолвите...
А Вы пробовали не удалять блок-диаграмму во время билда, как предложено в описании ошибки?
Так же, FInfo "тянет" за собой еще какие-то зависимости, кроме своего класса?
Странно, никогда такой проблемы не видел, хотя классы использую активно. Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс? Если нужно копировать - то лучше сделать Save As..., потом удалить клон из класса, перенести виайку в нужную папку, а потом добавить в новый класс при помощи Add Item.
Подобные проблемы случаются если есть путаница в Dependencies - виайки из одного проекта ссылаются на другой проект, а потом при создании exe одинаковые зависимости подтягиваются из разных мест, и получается ошибка. Ну, или компилятор не может найти нужные зависимости в рамках этого проекта.
Мы делили апельсин - много наших полегло...
-
IvanLis
- guru
- Сообщения: 5462
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 86 раз
Re: О бедных классах замолвите...
Повторить баг слету не вышло...
Но возникает именно в случае использования Sub из одного класса в другом.
Сейчас в голову пришло, что нужно было попробовать функцию реентерабельной сделать...
Бывает, что изначально не планируется использование Sub в другом классе.
Но чисто машинально, взял и перенес.
Копировать... как-то неправильно с точке зрения модульности кода , особенно если они постоянно модифицируются...
Я например напоролся на это, когда делал прогу для работы с различным железом и так получилось, что у двух железяк (классов), правило разбора посылки совпало. Вот я и дернул Sub из одного класса в другой.
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: О бедных классах замолвите...
пробовал, не помогло. "помогло" добилдить, но при запуске еxe сообщает, что он битый, а если залезть туда отладчиком, то все сабы "пропали".
Нет, он даже свой класс не тянет.
первое. и даже не оно.Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
Я вытаскивал данные из имени файла. В большом проекте понадобилось сделать то же самое. Вязи и вызвали оттуда эхтот саб, передав ему имя файла.
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: О бедных классах замолвите...
А вот тут уже как посмотреть - ведь используя виайку одного класса в другом мы как раз эту модулярность (на уровне классов) теряем, ведь второй класс уже не может "жить" без первого. Это нормально если первый класс - его "родитель", но если они "братья/сестры" - то лишняя зависимость...
На блок диаграмме есть функция с иконкой "M2Hz" - она тоже часть первого класса? Или она где-то в другом месте? С ней не может быть связана проблема?
Мы делили апельсин - много наших полегло...
-
IvanLis
- guru
- Сообщения: 5462
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 86 раз
Re: О бедных классах замолвите...
Ну...Kosist писал(а): ↑05 май 2020, 00:41А вот тут уже как посмотреть - ведь используя виайку одного класса в другом мы как раз эту модулярность (на уровне классов) теряем, ведь второй класс уже не может "жить" без первого. Это нормально если первый класс - его "родитель", но если они "братья/сестры" - то лишняя зависимость...
Видимо я выбрал правильный путь
Я вынес все Sub из класса и собрал их в отдельной (виртуальной) папке Библиотеки за пределами Класса, а рядом (в той же Библиотеке) разместил Класс.
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: О бедных классах замолвите...
Если этот Саб является членом класса, компилятор будет знать откуда его загружать только через класс. Если класс не инициализирован (нигде не поставлен OBJ на диаграмме и нет ссылки) компилятор его не загрузит.Artem.spb писал(а): ↑05 май 2020, 00:02 Нет, он даже свой класс не тянет.первое. и даже не оно.Вы имели ввиду что хотели вызвать виайку одного класса в методах другого, или скопировать виайку в другой класс?
Я вытаскивал данные из имени файла. В большом проекте понадобилось сделать то же самое. Вязи и вызвали оттуда эхтот саб, передав ему имя файла.
Простой SubVi попавший в класс это уже не простой SubVi, он обрастает разными зависимостями. При копировании этого SubVi через проводник Windows он работать не будет, а будет браться из класса (обросший зависимостями). Это как показатель что есть зависимости.
Получается, что во время разработки компилятор берет SubVi из загруженных в память. А при компиляции *.exe временные ссылки не действуют.
Если посмотреть View -> Browse Relationships -> Unopened Type Defs там должен быть Ваш класс, в который вошел FInfo.
Опять же зачем Вам FInfo как член класса и почему бы не принять прозвучавшее выше предложение вынести его в отдельную библиотеку?
Мое мнение о использовании классов (по возможности меньше) учитывает мнение Линуса Торвальдса о С++ "... Я смотрю на объект, и НИКОГДА не могу сказать, нужно ли мне в вызывающем контексте передавать в конструктор явно сделанную копию например строки или структуры, или оно внутри там само все скопирует. И таких сложных для использования и понимания моментов много." https://mfonin.livejournal.com/419857.html
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
-
- professor
- Сообщения: 3396
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 172 раза
- Контактная информация:
Re: О бедных классах замолвите...
потому что гладиолус.
Я эту функцию для "себя" писал, и сначала никаких разговоров про внедрение в другие проекты не было, а потом линия партии сделала резкий поворот.
И начали делать по-простому.
я и не прошу компилятор сделать временные.Получается, что во время разработки компилятор берет SubVi из загруженных в память. А при компиляции *.exe временные ссылки не действуют.
Я ставил галки "ужать всё по максимуму" именно для того, чтобы компилятор повыкидывал всё из класса (если уж хочет его оставить) и отправил в сборку только нужные функции.
Проблема возможно решается снятием чрезмерных галок. Т.е. не надо удалять всё лишнее. Но это пока не достоверно, потому что вызывающую сторону тоже поковыряли.
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация: