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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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