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



Это сообщение отредактировал(а) 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)% знает