Приложение с графическим интерфейсом, критичное для производительности (Windows, Linux)

Во-первых, я бы потратил некоторое время на опробование нескольких преобразователи VB.NET в C#. Вы в основном портируете синтаксис, и нет причин делать это вручную, если вам это не нужно. Конечно, вам, возможно, придется очистить то, что выходит из конвертера, но это намного лучше, чем ручное преобразование.

Теперь, что касается ваших вопросов:

1) имеет ли смысл делать графический интерфейс в winforms, но дорогой материал в родном, неуправляемом C/C++?

Еще нет. Подождите, пока вы не сделаете преобразование, а затем узнайте, где вы на самом деле тратите свое время. Нет причин смешивать C/C++ с C#, пока вы не обнаружите, что это необходимо. Вы можете обнаружить, что достаточно перейти на небезопасный C#. Даже это может быть ненужным. Возможно, вам просто нужно оптимизировать алгоритмы. Узнайте, в чем заключаются ваши узкие места, и затем решите, как их исправить.

2) какие-либо рекомендации по хорошему набору кросс-платформенных окон, который подойдет для сценария, описанного выше?

Я бы наверняка обратил внимание на mono. Это действительно лучшее, что вы можете сделать, если собираетесь использовать C#. В значительной степени это либо моно, либо другая переписка на другом языке, когда / если вы переходите на Linux.

1) Преждевременная оптимизация — это зло. Реализуйте свои «дорогие вещи» на C# и посмотрите, нужно ли вам их реорганизовать. Или, по крайней мере, настройте тест, который позволит вам это определить.

2) Йоух. Кроссплатформенный интерфейс. Я бы не стал мириться с "может". Прибейте ласки вниз; как вы можете принимать дизайнерские решения, не зная, что вы проектируете? Если вы выберете чистую реализацию .NET, будут ли они жаловаться, если вам придется (как минимум) реорганизовать ее для работы в Mono? Если вы создадите его на Java, будут ли они раздражены тем, что он выглядит чертовски уродливо, и пользователи жалуются, что не могут найти свой .exe-файл среди всех этих .jars?

1) Не обязательно. Я думаю, было бы правильнее сказать, что, вероятно, стоит писать свой бэкенд-код на C++, независимо от последствий для производительности. Несмотря на то, что вы не можете связать свое начальство с переключением платформы, с вашей стороны было бы благоразумно подготовиться к такому случаю, поскольку типы управления часто меняют свое мнение без веской причины (или предупреждения); даже если они решат не переходить сейчас, это не значит, что они не решат перейти через шесть месяцев. Написание вашей логики на C++ сейчас, зная, что это возможно, хотя и более сложно, может значительно облегчить вашу жизнь позже.

2) Не совсем. Существуют «решения», такие как wxWindows и GTK#, но часто они глючат, или их трудно заставить работать должным образом, или им не хватает чего-то важного на той или иной платформе. Они также обычно блокируют вас в пользовательском интерфейсе с наименьшим общим знаменателем (т. е. общие элементы управления работают нормально, но вы можете забыть о том, чтобы когда-либо делать что-то интересное — например, WPF — с ним). Пользовательские интерфейсы легко писать, поэтому я думаю, что если вы пишете свою логику на чем-то переносимом, то собрать вместе несколько пользовательских интерфейсов для конкретной платформы будет тривиальной задачей.

Что касается первого вопроса, действительно трудно сказать, будет ли это иметь смысл, поскольку это, вероятно, будет зависеть от того, какую производительность вы должны получить. Лично я не видел каких-либо замедлений системы из-за графического интерфейса в правильно спроектированных графических интерфейсах с использованием WinForms, поэтому я не понимаю, почему это должно вызывать какие-либо проблемы, и, по всей вероятности, это облегчит вашу жизнь в отношении графического интерфейса. .

Что касается вашего второго вопроса, если вы собираетесь в какой-то момент перейти на другую платформу - вы хотите взглянуть на библиотеки, которые были реализованы в Mono (http://www.mono-project.com/Main_Page), это также должно покрывать большинство ваших потребностей в отношении межплатформенного управления окнами, поскольку оно поддерживает WinForms и ГТК#.

Нет, нет смысла делать "дорогие вещи" на C/C++. Потенциальные (и, скорее всего, незначительные) улучшения производительности никогда, никогда не перевешивают вашу производительность, будучи жалкой, больной шуткой по сравнению с C#. Действительно. Это даже не близко.

Прочтите это (и все сообщения, на которые есть ссылки в нем): http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Возможно, вы захотите изучить использование Mono. Это версия .NET с открытым исходным кодом, которая работает на многих платформах... Linux, Mac, Solaris, Windows и т. д.

Теперь о кодировании ваших дорогих вещей на C/C++. Вот статья, которая очень хорошо объясняет различия между производительностью C/C++ и C#< /а>.

И снова, позвольте мне подчеркнуть, материал C++ очень дорогой. Имеет ли смысл делать то, о чем я говорил выше? (Формы .NET скрывают тяжелый C++)

Как отмечалось ранее, лично я не замечал замедления работы всей системы из-за WinForms в приложениях, написанных как на VB.NET, так и на C#. Однако, если приложение действительно требовательно к производительности, вы можете заметить небольшое замедление, если вы написали все на C# из-за того, что оно скомпилировано в CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/ ). Таким образом, написание графического интерфейса на таком языке, как C#, скорее всего, немного упростит эту часть разработки, что даст вам больше времени для работы над критическими частями кода. Единственная уловка-22 здесь может заметить некоторые замедления из-за вызовов кода C/C++ из кода C#; однако это маловероятно.

1) имеет ли смысл делать графический интерфейс в winforms, но дорогой материал в родном, неуправляемом C/C++?

Скорее всего нет. Если вы не взаимодействуете со множеством других родных C dll и т. д., C#, скорее всего, будет на 5% медленнее или на 5% быстрее, чем C++ (std::string действительно убьет вас, если вы повторно использую его)

2) какие-либо рекомендации по хорошему набору кросс-платформенных окон, который подойдет для сценария, описанного выше?

Если это просто какие-то простые формы с кнопками, mono, скорее всего, сможет запускать их без изменений. В наши дни поддержка .NET WinForms довольно хороша. Тем не менее, это некрасиво :-)

Возможно, я неправильно понимаю проблему, но если это система мониторинга сети, почему она не написана как «выделенная» служба Windows?

VB.NET не должен быть намного медленнее, чем C#. Я не уверен на 100%, есть ли какие-либо большие различия в сгенерированном IL-коде, но единственное преимущество (и оправданная причина переписать его на C#), о котором я мог подумать (за исключением того, что C# имеет более приятный синтаксис и некоторые другие вкусности ) — это использование небезопасного блока кода, который может немного ускорить процесс.

Материал c/c++ может оказаться хорошей идеей, но прямо сейчас YAGNI. То же самое и с линуксом. Не обращайте на него внимания, он вам не понадобится, пока он вам не понадобится. Делайте это простым. Юнит-тест к черту, как вы говорите. Получите работающий код и разработайте дизайн оттуда.

Некоторое время назад у меня была аналогичная дилемма, когда я пытался найти лучший способ разработки инструмента H/W тестирования на базе ПК (что, очевидно, означает «с параметрами пользовательского интерфейса»), который взаимодействует со встроенным оборудованием (через интерфейс PCMCIA).

Узким местом было то, что тестирование должно выполняться с максимальным отклонением 10 мс от предполагаемого времени, указанного тестировщиком.

Например: если тестер создает следующую тестовую последовательность:

1. Remotely activate the H/W
2. Wait for 50ms delay.
3. Read an H/W information.

задержка, указанная в шаге 2, не должна превышать 60 мс.

Я выбрал приложение C++ WIN32 в качестве серверной части и VC++ 2005 Winform (платформа .NET) для разработки пользовательского интерфейса. Подробная информация о том, как связать эти два компонента, доступна в msdn
Я разделил систему следующим образом:
В VC++ .NET:

1. UI to have complete information about the H/W (read via back-end application) and to control the H/W on demand. (Buttons, combo-box etc.. etc..)
2. UI to run time critical test sequences (as mentioned in the above example).
3. Gathering these information and building a stream (File-stream) in a Time-linear format (i.e, in the precise order of steps in which it has to be performed).
4. Triggering and hand-shaking mechanism (by redirecting standard input and standard output) with WIN32 back-end application. The common resources will be the File-streams.

В С++ WIN32:

1. Interpreting the Input File-Stream.
2. Interaction with H/W.
3. Gathering information from H/W and putting it in its Output File-Stream.
4. Indication of test completion to UI (via redirected standard output).

Вся система запущена и работает. Кажется, он довольно стабилен. (Без упомянутого выше отклонения по времени).
Обратите внимание, что тестовый ПК, который мы используем, предназначен исключительно для целей аппаратного тестирования (на нем был запущен только пользовательский интерфейс, без автоматических обновлений, сканирования на вирусы и т. д. и т. д.).

gtk-sharp — довольно хороший кроссплатформенный инструментарий.

Gtk# — это набор инструментов графического пользовательского интерфейса для моно и .Net. Проект связывает набор инструментов gtk+ и различные библиотеки GNOME, позволяя разрабатывать полностью собственные графические приложения Gnome с использованием сред разработки Mono и .Net.