CINs labview старомодны? - PullRequest
       29

CINs labview старомодны?

3 голосов
/ 04 ноября 2008

Я пишу приложение, используя labview, и мне нужно использовать внешний код. Я читал, что использование CIN является старомодным и «неправильным» для использования. Это правильно? Должен ли я использовать общие библиотеки вместо этого?

Каковы преимущества / недостатки обоих методов?

Ответы [ 2 ]

5 голосов
/ 05 ноября 2008

У меня нет личного опыта написания внешнего кода, который будет вызывать LabVIEW, но из базы знаний NI : «Когда предоставляется выбор, DLL - это выбор».

Преимущества, которые они перечисляют, включают:

  • Многие процессы могут совместно использовать одну копию DLL в памяти
  • Многие приложения могут совместно использовать одну копию DLL на диске
  • Изменение функций в DLL не требует перекомпиляции вызывающего приложения
  • Для создания CIN поддерживаются только определенные (устаревшие?) Среды разработки.

Потенциальные недостатки DLL:

  • Первые два пункта в списке выше; -)
  • При сборке приложения из LabVIEW
  • Код CIN может быть независимым от платформы, в то время как библиотеки DLL / разделяемые библиотеки могут нуждаться в переписывании для каждой платформы.

Я почти уверен, что каждый раз, когда я видел это обсуждение в течение нескольких лет после списков и форумов LabVIEW, совет был один и тот же: CIN устарели, используйте DLL - просто осознайте потенциальные проблемы, которые они могут вызвать.

1 голос
/ 05 ноября 2008

Спасибо nekomatic за ваш ответ. Если кому-то еще это интересно, я нашел в глубине интернета статью , которая объясняет преимущества и недостатки обоих методов. Оказывается, CINS раньше имели преимущества перед общими dll до labview 8.20, но теперь они устарели.

FTA: У CIN ​​больше нет единственного преимущества перед использованием узла библиотеки вызовов, но есть несколько недостатков

...