AF + typedef

Общие принципы, проектирование, модуляризация, темплейты и шаблоны
Ответить
Artem.spb

Activity Автор
professor
professor
Сообщения: 3393
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

AF + typedef

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

Не понимаю, что за глюк.
Делаю проект с несколькими AF.
И само собой есть typedef.
Так вот регулярно случается беда. Открываю td, добавляю элементы (ладно бы Убавлял или переименовывал), закрываю, сохраняю. Программа не работает,
Ищу проблемы, обнаруживаю, что некоторые td скатились до нулевого значения.
Что за беда? никогда такого не было, только на AF заметил.
td раскиданы по библиотекам, может, в этом проблема?
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: AF + typedef

Сообщение Kosist »

AF тут ни при чем - это просто набор либок для создания акторов.
Иногда LabVIEW просто делает reset значений кластера при его модификации; на NI форуме описаны подобные случаи... Поэтому NI рекомендует устанавливать значения по умолчанию в явном виде, при помощи Bundle (Bundle by Name). В таком случае ошибки точно не будет. Да и код читается легче - т.к. сразу видно, что заданы определенные значения, не нужно искать изменения в самом кластере.
Мы делили апельсин - много наших полегло...
Artem.spb

Activity Автор
professor
professor
Сообщения: 3393
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: AF + typedef

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

Это не кластер, это enum. Тип запроса. И в коде лежит константа с выбранным типом.
А при обновлении некоторые команды "сделай это" сваливаются на "не делай ничего". И приходится бегать по коду, искать, где произошло сваливание
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: AF + typedef

Сообщение Borjomy_1 »

Стесняюсь спросить AF - это что?
Artem.spb

Activity Автор
professor
professor
Сообщения: 3393
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: AF + typedef

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

Actor Framework
споры и дискуссии сразу под этим вопросом :)
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: AF + typedef

Сообщение Kosist »

Artem.spb писал(а):Это не кластер, это enum. Тип запроса. И в коде лежит константа с выбранным типом.
А при обновлении некоторые команды "сделай это" сваливаются на "не делай ничего". И приходится бегать по коду, искать, где произошло сваливание
Походу, это глюк тайпдефа - неважно, энум или кластер... Но ясной инфы на форуме не нашел...
Я уже давно для имен комманд использую строки, а не энумы... Но вот недавно работал на проекте, тоже использовал AF, была куча либок, классов, и т.д. - и также использовал энумы для некоторых объектов, проблем с их обновлением не было...
Мы делили апельсин - много наших полегло...
Artem.spb

Activity Автор
professor
professor
Сообщения: 3393
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: AF + typedef

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

Kosist писал(а):Я уже давно для имен комманд использую строки, а не энумы...
я вот считаю это дикарством.
Это примерно то же самое, почему Ni отказывается в классах методы оформлять через invoke node: потому что это будет текстовое программирование, а не графическое.
енум хорош тем что все пользователи сообщат мне, что не хватает кейса или чего-то подобного. И задать нужную команду гораздо проще, нет опасности ошибиться в одной букве. Каждому своё, но я не понимаю, ради чего отказываться от прелестей графического программирования.
Ну и меня опять закидают шапками, но строка занимает кучу байт, а енум всего пару.
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1236
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 30 раз
Контактная информация:

Re: AF + typedef

Сообщение Kosist »

Artem.spb писал(а): я вот считаю это дикарством.
О, холивар назревает ))
На вкус и цвет - фломастеры разные.
Во всем есть свои выгоды, и невыгоды. И выгоды енума на первый взгляд бесспорны.
Но:
- при большом количестве модулей использующих стейт машины на каждую из них нужен свой тайпдеф енум. При том, что много комманд будут повторяться;
- при переносе модуля на новый проект нужно править енум (если есть какие-то комманды, которые не требуются);
- невозможно создать универсальное API для обработки комманд - т.к. они будут "завязаны" на конкретный енум;
- ну, и иногда при правке енума обнуляются комманды :wink: .

Строки:
- единственный минус, что нужно знать список комманд, и не повторяться. Для "отлова" опечаток на стадии разработки достаточно дефолтного стейта в стейт машине, а список комманд видно при создании API для комманд. Также при помощи API виаек легко задается интерфейс для самой комманды (какие данные нужно отсылать с коммандой), и отслежываются конкретные места вызова комманды.
Правда, с енумом тоже можно делать API, но даже его шаблон для модулей не будет универсальным.

JKI использует string-based стейт машину, Delacor кажись тоже (хотя может и ошибаюсь). Также многие NI примеры, и референс-дизайны тоже содержат код со стейт машинами на основе строки.
В конце-концов, это дело вкуса - и оба методы имеют право на жизнь. Так как использование енума не дает
Artem.spb писал(а):прелестей графического программирования
т.к. это не есть чисто "фишка" :labview:; энумераторы есть и в других языках. Это удобно, да - но опять же, дело привычки и вкуса.
Мы делили апельсин - много наших полегло...
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: AF + typedef

Сообщение Borjomy_1 »

Поддерживаю Artem.spb, От строк вообще надо уходить. В LV безобразно устроена работа памяти при работе со строками. Будете смеяться, но это основной источник неконтролируемой утечки памяти.
С точки зрения качества программирования Enum использовать предпочтительнее. А если надо, то всегда можно выдернуть из контрола текстовый список значений.
Artem.spb

Activity Автор
professor
professor
Сообщения: 3393
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: AF + typedef

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

Так как использование енума не дает
прелестей графического программирования
т.к. это не есть чисто "фишка" :labview:; энумераторы есть и в других языках.
я не говорил, что enum - признак графичности. Признак графичности - нажал стрелку, получил весь список. И не надо вспоминать или в доках искать.

и да, Borjomy_1 прав
В LV безобразно устроена работа памяти при работе со строками. Будете смеяться, но это основонй источник неконтролируемой утечки памяти.
Ещё в древних трактатах 90х читал, что по возможности надо строки перегонять в массивы u8, и только потом делать с ними что хочется, особенно если это вставки/замены и пр.
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: AF + typedef

Сообщение dadreamer »

Kosist писал(а):В конце-концов, это дело вкуса - и оба методы имеют право на жизнь.
Я отчасти с этим согласен, однако SM со строковым селектором реально работает медленнее, чем с числовым. Это подтверждено уже давно и до сих пор справедливо вплоть до LV 2019. Есть вот такой бенчмарк: Performance of state machine with enum vs string? У меня получаются следующие результаты: enum (subroutine) - 0,930054; string (subroutine) - 1,17707; enum - 1,28307; string - 1,50509 (число итераций = 10 млн, дебаг отключен). Причина отставания строк от чисел (в данном случае) не в работе с памятью, а в побайтовом сравнении текущего значения с каждой командой/состоянием из списка SM. Очевидно, чем длиннее строки, тем больше времени потребуется на сравнение, особенно если оно не чувствительно к регистру. Работа с памятью на самом деле в LV не очень, но в этом виноваты в первую очередь внутренние функции LV, а не само представление типа данных (в самом деле, строка и массив U8 имеют одну и ту же структуру, просто с массивом можно работать in-place). В NXG эта ситуация должна заметно измениться, т.к. внутренние менеджеры переписаны с нуля. Тем не менее время от времени я тоже использую строку в качестве селектора SM, когда создаю простенькие программы с логикой, не критичной во времени. Это проще/быстрее, нежели задавать тайпдеф, а часто лень перевешивает затраты на оптимизацию; скажем, автоиндексация в циклах не всегда полезна, и лучше задавать число итераций явно, заранее выделять буфер и т.д. (об этом ещё Андрей писал в своих статьях), но подавляющее большинство использует автоиндексацию. Таких примеров много. В остальных случаях команду для SM лучше задавать числом. Ещё бы редактор элементов списка был поудобнее, но похоже не в этой "линейке" LV.
Ответить

Вернуться в «Модели программирования»