Здравствуйте, rm822, Вы писали:

R>а и б — не рассматриваются в принципе
+100500
R>ц и д — как вариант. на девэкспрессе свет клином не сошелся, есть и другие
DeveloperExpress — это одна из лучших доп-библиотек для .NET.
Есть также и ComponentOne, но он ИМХО слабее.

R>>> — создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале
AG>>Зачем, если есть C#?
R>затем что подразумевается существование достаточно большой кодовой базы на с++, переписывание которой на шарп — маразм с экономической точки зрения
R>И ее как-то надо связать с UI на шарпе. Из вариантов DllImport|ComInterop|C++ CLI. Последний, на мой взгляд, самый здравый
Кодовая база на C++ — именно на нативном C++ (корая идёт через DllImport|ComInterop) — обладает огромным приимуществом:
— работает нативный код, корый выполняется значительно быстрее. Так, на моём старом месте работы мы делали приложение на .NET (C#),
которое производило Фурье анализ для примерно пятисот гармоник оцифрованного сигнала. Один цикл анализа на .NET (C#) занимал около 200 ms.
Его переписывание на нативный C++ (в отдельной DLL — затем делаем DllImport) обеспечило цикл длительностью 4 ms (НА ТОМ ЖЕ оборудовании)!!!

Последний вариант (C++ CLI) — это объединение недостатков двух подходов:
1) Код на оборудовании выполняется медленно, так как работает CLR среда .NET системы.
2) Быстроты написания кода программистом, чем так славится C#, также достичь не удаётся.

P.S. Лично мне нравится выжимать из оборудования всё, на что оно способно, посему (несмотра на опыт C# разработки) я выбираю C++

Здравствуйте, rm822, Вы писали:

R>а и б — не рассматриваются в принципе
+100500
R>ц и д — как вариант. на девэкспрессе свет клином не сошелся, есть и другие
DeveloperExpress — это одна из лучших доп-библиотек для .NET.
Есть также и ComponentOne, но он ИМХО слабее.

R>>> — создание API на C++ CLI для разработки гуя на шарпе — проще чем кажется в начале
AG>>Зачем, если есть C#?
R>затем что подразумевается существование достаточно большой кодовой базы на с++, переписывание которой на шарп — маразм с экономической точки зрения
R>И ее как-то надо связать с UI на шарпе. Из вариантов DllImport|ComInterop|C++ CLI. Последний, на мой взгляд, самый здравый
Кодовая база на C++ — именно на нативном C++ (корая идёт через DllImport|ComInterop) — обладает огромным приимуществом:
— работает нативный код, корый выполняется значительно быстрее. Так, на моём старом месте работы мы делали приложение на .NET (C#),
которое производило Фурье анализ для примерно пятисот гармоник оцифрованного сигнала. Один цикл анализа на .NET (C#) занимал около 200 ms.
Его переписывание на нативный C++ (в отдельной DLL — затем делаем DllImport) обеспечило цикл длительностью 4 ms (НА ТОМ ЖЕ оборудовании)!!!

Последний вариант (C++ CLI) — это объединение недостатков двух подходов:
1) Код на оборудовании выполняется медленно, так как работает CLR среда .NET системы.
2) Быстроты написания кода программистом, чем так славится C# (VB, Java), также достичь не удаётся (всё таки это C++).

P.S. Лично мне нравится выжимать из оборудования всё, на что оно способно, посему (несмотра на опыт C# разработки) я выбираю нативный C++