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

Mormishka, для этого необходимо создать Solution в который добавить два Project: один - C#, а второй - C++/CLI.
Затем в проекте на С++ необходимо создать класс реализующий методы реализующую вычислительную часть.
В проекте на C# при этом нужно добавить Reference на проект С++ и после этого, где это необходимо можно создавать классы написанные на С++ и вызывать их методы реализующие вычислительную часть.

P.S. На самом деле я не знаю ответа на вопрос, но философия .NET такова и это должно работать не только для связки C# + C++/CLI, но и для всех других возможных (например: VB + F#)...

Спасибо, попробую.

Рано - сначала попробуй, а то вдруг я чего не того насоветовал   ...

Никто также не мешает вам написать на c++ dll библиотеку. А потом при помощи P/Invoke использовать ее в .NET программах.
И маленький пример.

Это сообщение отредактировал(а) Fortnox - 11.3.2011, 20:54

Присоединённый файл ( Кол-во скачиваний: 6 )
 Solution1.7z 3,37 Kb

или написать на C++ сделав COM класс, который и использовать через interop-ы

Gluttton, я чего то не очень уловил смысла твоего совета. Я так понимаю ТС хочет что-то побыстрее посчитать. И чем по-твоему будет отличаться производительность C# и С++/CLI? Всё в итоге будет переведено в IL и запущено поверх CLR. У языков однотипная модель исполнения, производительность будет почти равная. И не факт, кстати, что С++/CLI будет быстрее.

Тут нужны чистые нативные незагаженные  плюсики. И IPC в каком-либо виде (вышеупомянутый COM, например). Но я бы пошёл другим путём.

Если есть нужда в суровом number crunching'е, надо делать unix-way:

• Консольная прилада на плюсиках (альтернативно - Фортран), принимающая на вход data.inp и возвращающая на выходе data.out. 
• GUI прилада. На C#*. Умеющая генерировать data.inp, парсить data.out и что-то там рисовать-отображать. Опционально умеющая запускать консольную приладу.

Получится максимально портабельно и расширяемо. На взрослое будующее. Мало ли захотим посчитать на каком-нить *nix-кластере.

А COM - жёсткая привязка к платформе. Долой!  

*) Пока пусть будет на C#. Потом повзраслеем, поймём, что такое vendor locking, увидим Mono ... Я просто оставлю это здесь.  

Это сообщение отредактировал(а) kemiisto - 11.3.2011, 23:23

kemiisto, отличный пост, но я думаю, что он больше ТС чем мне ;) .
Хотя я мне есть, что из него почерпнуть, но просто я не обременен требованиями производительности.


Да чего уж там - давай сразу на Asm'e (это пожалуй тоже больше ТС чем тебе).


Что там с ним не так?

Не, асм тут непричём. Можно, конечно, и из C# повыжимать. Кешировать объекты (повторно использовать), поставив GC на голодный паёк. И многое в таком роде. Но смысла мало. К тому же под С++ и Fortran есть куча дооптимизированных до безумия библиотек для number crunching'а. А вот асм тут как раз никаким боком.

Кстати, на CLR от MS есть забавные ограничения. Например, невозможность создать массив, занимающий больше 2ГБ. А теперь посчитай сколько это будет будет элементов, какого-нибудь серьёзного типа данных. Например, плавабщих чисел с quadruple precision. Семечки.

Даже на x64, кстати, это ограничение. В Mono, вроде, нет. Насколько я помню. Так что серьёзный number crunching я бы рекомендовал запиливать на С++, Fortran. Ada можно ещё.


Сейчас основная претензия (если говорить о GUI) - ненативный интерфейс на второй по популярности десктоп-платформе. Набирающей популярность к тому же.

kemiisto, 
Сначало у меня была программа на С++ консольная, я хотел, чтоб она записывала файл в двоичном виде. а читать на шарпе. Так вот на шарпе я не смог прочитать файлы записанные на С++.
http://forum.vingrad.ru/topic-322999.html

Mormishka, а зачем писать в двоичный формат? Пишите в текстовый. Плюс получите возможность в будующем быструю автоматизацию запилить на каком-нибудь скриптовом языке.

Кемисто, ты ведь не представляешь как работает C++ CLI

A5uKa, у тебя проблемы с клавиатурой

                     ?

A5uKa, тупишь чолэ? Я ж тебя и спрашиваю



что тут в конце предложения? Точка? Знак вопроса? Знак восклицания?

Теперь понятно?

В чужом глазу сучок видишь..



Это сообщение отредактировал(а) KelTron - 14.3.2011, 13:54

KelTron, ой ё маё. Народ!!! Опомнитесь вы, ёп! Посмотрите на хронологию постов, вашу мать!

Я НАПИСАЛ СВОЙ ПОСТ С ПРЕДЛОЖЕНИЕМ БЕЗ ЗНАКА ПРЕПИНАНИЯ, ЧТОБ АСУКА ЗАДУМАЛАСЬ. НО ОН(А|О) НЕ ПОНЯЛ(А|О).

Эту планету спасут только массовые растрелы.  

В чужом глазу... Да ну вас...

да ...

Кемисто, ты ведь не представляешь как работает C++ CLI ?

Нет. Я писал сообщение на общих основаниях. Что-то не так?

Мне просто кажется, что оно компилируется не так, как ты предположил.

Ты тоже не знаешь?  Беседа обещает быть содержательной.

Собственно, я утверждал лишь, что

Оно ж CLI. И неважно что С++. Хоть Brainfuck. Там по спецификации Common Language Infrastructure (CLI), исходный код  должен компилится в Common Intermediate Language (CIL). Иначе это уже не С++/CLI.

А дальше - просто. Я не думаю, что в процессе копиляции в CIL С++ компилятор может задействовать какие-то хитрые оптимизации, которых не может задействовать C# компилятор. Я, скорее, склонен даже думать наоборот. Либо там оптимизаций будет по минимуму, либо больше для C#. Всё-таки ключевый язык платформы, куда более активно развиваемый и поддерживаемый.

А когда этот почти одинаковый CIL-код будет запущен Virtual Execution System (VES) разницы не будет.

Как то так. Мммм?

Да ну не верится, что оно всё конвертирует в CLR.

Ведь зачем-то она за собой тянет все плюсовые библиотеки, как минимум она делает invoke всех этих библиотек.

В C++ CLI есть такой ref (ссылочный) класс 
http://www.williamspublishing.com/PDF/978-...1279-4/part.pdf

Как я понимаю лишь эта часть портируется в IL, а остальная инфокается, но могу ошибиться.

Таки да. C++/CLI compilers produce mixed-mode assemblies by default. Ошибался.  

Тут, например.

Всё равно, ИМХО, глупость. Опять-таки vendor locking. Mono не поддерживает. Что естественно из-за озвученной выше генерации mixed-mode assemblies.

И vendor ориентированно , так же. 

Ты не замечаешь этих плюсов ?

Очень много данных, тогда весить будет много.

Каких "этих"? Возможность в идешечке добавить референс? Не смеши. .NET канет в лету лет через 5-6. MS меняет платформы как перчатки. Расскажи про "эти" плюсы тем, кто лет 10 назад "повёлся" на плюсы COM. Сейчас - сплошные минусы.

Писать на С++/CLI вычислительную задачу под одну платформу - верх идиотизма. К тому же выделение считалки в отдельное консольное имеет и другие преимущества. Я писал, повторяться не буду.

Вы, батенька, пессимист!

да нет, оптимизм это и здравое мнение. 
вот сам сижу, пишу маленькую халтурку себе с помощью C# и думаю - "боже мой,  это ужасный синтаксис, совершенно не понятное управление памятью, простая компиляция которая скрывает многие параметры производительности". и это ужасно. Миллионы и миллионы людей ошиблись как и я. и мне их так же жалко, и и себя, ведь через 2-3 года надо переучиваться опять на какую - то диковинную штуку. Это ужасно и страшно.

А я скажу, что тут сочетается win api C++ , а это ещё долго не умрёт и самая передавая на текущий момент библиотека под Win, что определяет вполне правильный подход. Возможность увязать всё это с другими языками и технологиями, огромным числом их делает этот подход лучше любого другого.

А вот про Nokia Qt ещё вопрос. Nokia телефоны как извесно перешли на Win. И почему-то приложения там тоже писаные под Win , а не на хвалёной Qt.

Много-ли сейчас написано на Qt, кроме teamviewer-а и KDE ?

Кроссплатформенность нужна далеко не всегда. С этим надеюсь спора не будет, 
и в тех случаях жизнь не кончается на Qt, меня больше привлекают вот эти вещи 
http://stackoverflow.com/questions/470468/...ming-frameworks

Добавлено через 5 минут и 59 секунд

2-3 года назад так же говорили

Добавлено через 6 минут и 36 секунд
да и естественно прийдётся учить что-то новое, это часть профессии.

Mormishka, подумай, а так ли правильно обмениваться между управляемым и неуправляемым кодом большим количеством данных ?
И всё же, я б посоветовал посмотреть на Unix-way, который тебе предложил kemiisto

но можно попробовать обойтись без файлов, а передавать данные через стандартный ввод/вывод. Не знаю как в венде, а в linux'е передача данных из одной программы в другую через стандартный ввод/вывод оптимизирована донельзя (вплоть до использования shared-memory).
Вот только не спрашивай меня, как на шарпе читать из stdout консольной программы. Я этого не знаю. А форум на 99,9(9)% знает 

Пьёшь на работе? Я не понял ничего. Во-первых, каким образом факт написания на С++, а не на С++/CLI отменяет возможность доступа к Win API? Во-вторых, зачем нужен этот доступ в числодробилке? В-третьих, если ты считаешь, Win API лучшей библиотекой, у меня для тебя плохие новости. Начнём с того, что это не библиотека. Лучшая - я даже комментировать не буду.

Если под лучшей библиотекой имелся ввиду .NET Framework, то логики вообще никакой. И опять-таки это не библиотека.


Nokia приобрела Qt с одной целью - ускорить портирование на свои мобильные девайсы. На десктопе к Qt всё было хорошо. И будет.


Во-перых, много. Во-вторых, "кроме KDE" - спасибо, поржал. Ой, и кто бы говорил. Много ли написано на .NET? Haskell? F#?

Вот прямо сейчас. У меня стоит VLC Media Player, Avogadro, GaussView, KchmViewer, DjView Viewer. А что у меня написано на .NET? Эммм... Ничего? Нет, вру! 3RVX же. Но тупит жутко. Идём на сайт автора, читаем:

Вот, собственно, и всё, на что способен .NET.



Ты точно со мной разговариваешь?


И так и случилось. WPF, WCF и прочая ересь. Просто, не стали переименовывать .NET Framework, чтоб не испугать массы.


Во-первых, это чушь. Во-вторых, ты уже третий десяток лет, я так понимаю, в профессии, чтобы такие выводы делать? Поговори со старшими, узнай. А правда в том, что это не часть никакой профессии. Даже Спольски про это писал. Это навязанное мнение. Ты всегда должен быть позади и догонять. Марионетка. Фи быть так(им|ой)!  

Устанавливаю Skype.  

Ну не только WinAPI ))) Так же другие сишные библиотеки. Тут  я имею ввиду именно библиотеки ( windows.h и т д ) , уйма системных вещей написана на си, в том числе с плюсами.
Да, имеля ввиду .NET, да, не библиотека, но именно на нём на мой взгляд сейчас модно писать различного рода интерфейсы, формы, web...

На Haskell и F# написано действительно мало ) А вот про .NET ты так зря. Уйма коммерческого софта на продажу написана на .NET, это не для кого не секрет и число подобного софта растёт достаточно бысто. Да и серьёзных разработак достаточно много. Если смотреть не в сторону утилит, месседжеров и видеоплееров, а скажем современные игрушки, MSSQL и т д и т п.

Я так и не понял. Где здесь аргумент за С++/CLI?


Ключевые слова выделены. Должен ли я говорить, что мода приходит и уходит?


А на Qt прям мало.  Зайди на сайт, посмотри.

borisbn, 
Так я и имею ввиду unix-way. Создаю консольное приложение С++, которое принимает in.* выдает out.*. Этот процесс вычисления может и по 12 часов занимать.
 А под дот нет мне просто нужно смотреть данные out,графики и прочее.