Когда следует закрывать указатели на объекты?

[Konstantin Sumenko]

От версии к версии положения менялись, до LV 7 все указатели на объекты должны были принудительно закрываться (close reference), иначе это приводило к мусору в памяти (из-за того, что при вызове указателя он каждый раз имел новое значение). Как обстоят дела в последних версиях? Очевидно, что при завершении программы глобально используемые указатели на объекты стоит закрывать. Как поступать с локально используемыми указателями, например я получаю/передаю массив указателей на элементы кластера controls[] каждый раз при вызове SubVI- стоит ли принудительно закрыть их по завершению SubVI? ИМХО, ответ нет, так как каждый раз при вызове указателей они имеют одни и те же значения в памяти (в рамках текущего приложения). А вот со ссылками на объекты ActiveX и .NET надо быть осторожнее.
Каковы ваши варианты?

[Eugen Graf]

Я бы сказал так. Если программа закрывается, то все референсы всё равно будут закрыты. А вот если в программе использовать подприборы, которые используют объекты, то референсы желательно закрывать если эти обьекты больше использоваться небудут. А что касается различий в версиях по этому поводу, то я не думаю что они большие.

[Konstantin Sumenko]

"Больше использоваться не будут" понятие растяжимое: больше использоваться не будут в рамках одной итерации SubVI, или вообще. Даже в примерах от ni леняться закрывать референсы на контролы.

[Eugen Graf]

"Больше использоваться не будут" понятие растяжимое: больше использоваться не будут в рамках одной итерации SubVI, или вообще. Даже в примерах от ni леняться закрывать референсы на контролы.

Я имею ввиду вообще. Если предпологается, что прибор в программе будет использоваться ещё раз, то лучше не закрывать референсы использующиеся в нём. Но это всё ИМХО. Может быть есть и другие мнения.

[Konstantin Sumenko]

Хотелось бы в этом разобраться. Ладно C#- там все понятно в рамках сборщика мусора и то есть исключения (я не говорю про выполнение небезопасного кода).

P.S: перевел свою последнюю программу на LVOOP (модификация: LVOOP по ссылке), пока впечатления крайне положительные.

Вообще, кто детально вкапывался в строение NI Run-Time: как устроено выделение памяти под объекты и ее высвобождение?

[Eugen Graf]

Ну я бы сказал с LVOOP это напрямую не свазано. В принципе вообще хотелось бы разобраться с этим.

Поздравляю с переходом на LVOOP

[mzu2006]

Очевидно, что при завершении программы глобально используемые указатели на объекты стоит закрывать.

Они закроются сами, LV сборщик мусора их подберёт.

Как поступать с локально используемыми указателями,

каждый раз при вызове указателей они имеют одни и те же значения в памяти

что значит, что обект доступен нам по ссылке.

ni леняться закрывать референсы на контролы

IMHO, их и не надо закрывать. Потому что нам дали ссылку на оригинальный объект а не копию.

Я считаю, что всё, что было открыто вручную (open), должно быть закрыто вручную, когда отпадает необходимость в данной ссылке. К сожалению, в LV сложно реализовать концепцию подсчёта указателей, master pointers, facets etc ...

до LV 7 все указатели на объекты должны были принудительно закрываться

На очереди LV <7 считала сама количество "ссылок", таки да.

модификация: LVOOP по ссылке

Можно поподробнее? Это GOOP?

вкапывался в строение NI Run-Time: как устроено выделение памяти под объекты и ее высвобождение?

LVOOP - это просто кластер + информация о типе. Т.е. так же, как и на обычный кластер
GOOP - это хитрая ссылка на очередь (сейчас под рукой нет примера, поправьте меня, если не прав)

[Konstantin Sumenko]

По завершению рограммы я вручную высвобождаю очереди и удаляю ссылки на сторонние объекты (.NET, called VI's).
Да, GOOP, это ссылка на очередь (очереди), соотвественно один и тот же объект доступен в разных потоках, предусмотрен Data locking, единственное что я еще не использовал- наследование, сейчас этим занимаюсь.