Быстрая программа C++, C# GUI, возможный? [закрытый]

На мой взгляд, ваше решение хорошее:

1. Несмотря на то, что C # быстр, он никогда не сможет конкурировать с хорошо написанным неуправляемым C / C ++,

   Еще одна вещь, на которую вы, возможно, захотите посмотреть, - это проект с открытым исходным кодом под названием SWIG . SWIG берет ваш код C / C ++ и создает из него сборку .NET. Я сам использовал его в своем проекте с открытым исходным кодом TM ++ . См. Здесь дополнительную информацию о SWIG http://www.swig.org/ .

Для приложений в реальном времени: я рекомендую C ++, вы будете более гибкими в управлении памятью, быстрее и даже мультиплатформеннее, в зависимости от того, какой фреймворк используется ...!

Что касается фреймворка и графического интерфейса, я рекомендую вам взглянуть на Qt . Qt - отличный фреймворк для разработки программного обеспечения на C ++.

Думаю, это решение вашей проблемы!

Первое, что вам нужно сделать, это проверить свое предположение . Каковы ваши ограничения производительности? На каком оборудовании вы собираетесь разместить приложение? Напишите небольшую программу на C #, которая решает основную проблему и измеряет, насколько быстро она выполняется.

Только имея факты, вы можете принять решение о том, использовать ли C / C ++ вместо управляемого решения.

Наряду с другими, кто прокомментировал, я подозреваю, что C # / управляемое решение подойдет, особенно если вы используете .NET Parallel Extensions .

Если вы в конечном итоге перейдете на C / C ++ route, то есть два варианта повторного взаимодействия, а именно pInvoke и COM-взаимодействие . Я не верю, что существует чистый способ доступа к неуправляемым классам C ++ непосредственно из .NET; с этой целью,

Моя компания делает что-то очень похожее, но с камерами CCD вместо камер с линейной разверткой. Мы используем C # для графического интерфейса, сетевого взаимодействия, высокоуровневой «сантехники» и C ++ / CLI для низкоуровневых алгоритмов. Работает неплохо. Вы никогда не сможете написать настоящую систему реального времени с гарантированным максимальным временем отклика в Windows, но, по моему опыту, сборщик мусора будет здесь наименьшей из ваших проблем. Во-первых, сборщик мусора запускается только тогда, когда вы выделяете память; как и malloc / new в C / C ++, и им нужно время, тоже (подумайте о фрагментации памяти). Судя по измерениям, которые мы сделали, полный сборщик мусора занимает 10-50 мс и не обязательно останавливает другие потоки в течение этого времени (если, я думаю, они не попытаются выделить управляемую память), что для нас нормально. Но я не уверен, что эти числа могут быть обобщены для любого типа приложения, вам, вероятно, следует провести собственное профилирование, чтобы быть уверенным.

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

Второй вопрос заключался в том, следует ли вам использовать C ++ или C # для актуальные алгоритмы. Лично, Я чувствую себя более комфортно в C ++, когда пишу сложные алгоритмы обработки изображений. Я думаю, что язык лучше подходит для этой задачи, и для C / C ++ существует гораздо больше библиотек обработки чисел, чем для C #. Но это может быть вопрос личных предпочтений. С точки зрения производительности C ++ имеет то преимущество, что инлайнер C ++ лучше, чем инлайнер .NET JIT (т. Е. Он может встраивать больше ваших небольших вызовов функций).

Если вы решите использовать C ++, я бы посоветовал с использованием C ++ / CLI: таким образом вы можете писать классы C ++, которые скомпилированы в управляемый код. Оптимизатор C ++ оптимизирует их, только последний этап компиляции машинного кода будет выполняться .NET JIT. Большим преимуществом является то, что вы можете напрямую обращаться к своим .NET-классам из C ++ / CLI, и вы можете легко создавать управляемые классы в C ++ / CLI, к которым можно получить доступ из C #. Ты не Не нужно писать код оболочки по обе стороны забора. (C ++ / CLI немного неуклюж, потому что он содержит языковые конструкции для управляемого и для неуправляемого программирования, но если вы уже знакомы с неуправляемым C ++ и C #, у вас, вероятно, не возникнет проблем с его пониманием.)

Для C ++ вы используете C ++ / CLI, что на самом деле не так уж и плохо. Это намного лучше, чем старые управляемые расширения.

Прокомментировать производительность. Это действительно зависит от обстоятельств. Сколько будет между вашим кодом C ++ и вашим кодом C #? Будет ли у вас фоновый поток, собирающий данные на C ++ и периодически отправляющий их в код C #? Если вы собираетесь взаимодействовать с устройством, будет ли оно использовать последовательный порт, USB или какой-нибудь API, который вам предоставили?

Я согласен с Митчем на 100%.

Если после исследования его ресурсов вы все еще чувствуете, что вам нужно использовать какой-то неуправляемый код, вы можете написать «бизнес-уровень» на C ++ (или, в данном случае, действительно функциональный уровень) и написать свой пользовательский интерфейс на C #. Используйте COM-взаимодействие для вызова из C # / управляемого кода в ваш неуправляемый код.

Опять же, я считаю, что вам не нужно этого делать.

I've done it with C++.NET

Since both C++.NET and C# are managed I don't see why it could not be done. The point is how you will do it.

My scanner had up to 3000 lines / sec but the key strategy was to display blocks of 32 lines at a time. I didn't have hard real time requirements so I could be a little behind sometimes. If real time is very important to you, you should consider switching platform.

There is a real time windows solution called "InTime OS" but its really painful to use.

Another approach you can have is to separate the hard real time into a separate dll or library and have the C# show what it can at it's own speed. Really, the user will never be able to tell if your interface has 2000 fps or 500 fps

Выбранный вами язык не сильно повлияет на производительность (скажем, вы можете повлиять на скорость на 5/10%). Что будет иметь значение, так это алгоритмы, которые вы будете использовать, то, как вы будете обрабатывать данные, профилировать приложение и т. Д. (Производительность может измениться в 10 раз).

Почему именно windows? У него ужасная производительность памяти и худшая сеть по сравнению с любым из существующих unix. Специализированный захват линейного датчика подразумевает, что вам нужно устройство для обработки необработанного ввода. Сначала подумайте об использовании правильной ОС, которая значительно снизит другие нагрузки, с которыми вам придется иметь дело (я очень хорошо знаком с технологиями линейного сканирования).