Открыл для себя C++/CLI

[Flex Ferrum]

Позволю себе немножко разбавлю темы с просьбой о помощи.

Некоторое количество лет назад, когда .NET Framework был еще версии 1.1, попробовал я пописать под него на MC++ (который Managed C++). Попробовал, и забросил, т. к. впечатления остались самые мерзкие. Ну не C++ это получился у Microsoft. Но, было это давно, и с тех пор реализация C++ под .NET Framework была существенно переработана. Настолько существенно, что новая версия вышла под обозначением C++/CLI. И вот, решил я попробовать - а что же это за реализация (а так, в основном при разработке под .NET пишу на шарпе). И... весьма порадовался. Т. к. такой вот код:

#include "stdafx.h"
#include <iostream>
#include <algorithm>

#include <boost/lambda/lambda.hpp>
#include <boost/array.hpp>

using namespace System;
using namespace boost::lambda;

int main(array<System::String ^> ^args)
{
	Console::WriteLine(L"Hello World");

	std::cout << "Hello world!!!" << std::endl;

	boost::array<int, 10> arr = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

	std::for_each(arr.begin(), arr.end(), std::cout << _1 << "\n");

	return 0;
}

компилируется "на ура", без каких либо возражений со стороны компилятора. И это просто супер! Насколько можно использовать managed-типы в качестве параметров шаблонов - еще не выяснял. Но уже то, что управляемый код прекрасно уживается с шаблонным, использующем STL, boost и прочее - огромнейший шаг вперед.

Comments

[mistificator]

надо будет опробовать)

[slackovod]

эмм... и что же такого хорошего в этом очередном ужасном поделии от М$? глядел - не разглядел. вывод - ненужно оно.

а буст это шаг к "нормальным" динамическим языкам(которым уже ппц сколько лет и которые по производительности минимум не хуже дотнета). так что если есть необходимость его использовать - надо задумываться о правильнсти выбора языка.

[jazzcat]

ИМХО, если работать с .NET - то на C#.

Managed C++ лично мне видится кривым костылём типа VB.NET

[mistificator]

соглашусь с jazzcat

[Flex Ferrum]

а буст это шаг к "нормальным" динамическим языкам(которым уже ппц сколько лет и которые по производительности минимум не хуже дотнета). так что если есть необходимость его использовать - надо задумываться о правильнсти выбора языка.

Т. е. если я в тексте программы на С++ или C# захочу попользовать лямбда-функции, то мне нужно задуматься о выборе питона или руби? Так что-ли? Да и буст, на самом деле, не ограничивается одними лямбдами, но это уже другая тема для беседы.

ИМХО, если работать с .NET - то на C#.
Managed C++ лично мне видится кривым костылём типа VB.NET

Если писать под .NET бизнес-приложения - то безусловно. И если вы мне покажете на С# аналог (именно аналог, по возможностям и функциональности) библиотеки boost::spirit - я с удовольствием решу поставленную передо мной задачку на C#. Да, ANTLR не предлагать.
И, как я заметил в первом посте, Managed C++ - действительно корявое поделие, полученное обрезанием от С++ всего лишнего, после наложения на него CLI. И именно по этому C++/CLI - это совершенно отличный от MC++ язык, т. к. полностью сочетает в себе возможности и С++ и CLI.

[slackovod]

Flex Ferrum почему сразу... лисп- и ml- семейства всегда к вашим услугам (-;
ФП на самом деле тоже не одной лямбдой едино

пысы
>>...так что если есть _необходимость_ его использовать - надо задумываться о правильнсти выбора языка.
>Т. е. если я в тексте программы на С++ или C# _захочу_ попользовать лямбда-функции...

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

[Flex Ferrum]

Flex Ferrum лисп- и ml- семейства к вашим услугам (-;

Кабы мне от языка требовалась исключительно поддержка парадигмы функционального программирования - наверное был бы выбран лисп.

[slackovod]

Flex Ferrum ... а меж тем common lisp ПЕРВЫЙ язык, в стандарт которого внесены элементы ООП (дадада, я про CLOS ака Common Lisp Object System). Окамль тоже хороший пример сожительства парадигм

[Flex Ferrum]

Flex Ferrum ... а меж тем common lisp ПЕРВЫЙ язык, в стандарт которого внесены элементы ООП (дадада, я про CLOS ака Common Lisp Object System). Окамль тоже хороший пример сожительства парадигм

Ну, если смотреть с этой точки зрения - и С++ тоже не плохой пример сожительства парадигм. По мимо традиционных, тут и функциональное программирование, и метапрограммирование Другой вопрос - какими средствами это достигается и какова степень применимости всего этого.

[slackovod]

Flex Ferrum не фанат костылей. а по ссылке именно оно.
также не могу понять всей таги к "единственному и неповторимому самому лучшему языку". ислизлишнее усложнение в угоду "универсальности" объективный довод против этого подхода

[Flex Ferrum]

Flex Ferrum не фанат костылей. а по ссылке именно оно. также не могу понять всей таги к "единственному и неповторимому самому лучшему языку". ислизлишнее усложнение в угоду "универсальности" объективный довод против этого подхода

С одной стороны - да. Костыли это плохо (в ряде случаев - очень плохо). Но, увы, в настоящее время применяемость того или иного инструмента определяется не только тем, поддерживает ли он или нет ту или иную парадигму, но и тем, какая у этого инструмента инфраструктура. Именно этим и определяется популярность той же Java или C#, т. к. они максимально отвечают требованию: "сел и поехал". Не смотря на то, что для конкретной задачи вполне могут существовать средства (языковые), более подходящие для ее решения. Отсюда, собственно, и приверженность, и тяга к "единственному и неповторимому". Понятно, что из академического интереса ту или иную задачу можно решить и другими средствами. Но когда есть вполне конкретные сроки и вполне конкретная стоимость - на первый план выходит наличие нужных библиотек, компонент, подходов и прочего, что позволит решить задачу максимально быстро. А когда к этому добавляется еще и требование последующей поддержки, то выбор средств становится и вовсе ограниченным.

[slackovod]

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

[Flex Ferrum]

возможность генерировать объектный файл, пригодный для линковки с остальной программой, не аналог?

А дальше то что? Объектник я получил, подцепил к остальному коду (речь, я так понимаю, идет о CLOS?). Что я могу дальше с ним делать? Могу я подергать функции из этого объектника? А в него передать свои функции/объекты могу? На каком уровне обеспечена биранрная совместимость? И не получится ли в итоге так, что выиграв бой я проиграю все сражение?

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

Ты знаешь, достаточно удобно. Особенно в шарпе (ибо реализована на уровне языка). В С++ юзабилити чуть хуже, но вполне сносно, и со своими задачами справляется. Сейчас ждем нового стандарта С++, где лямбды с замыканиями вводятся как часть языка, и слияния веток gcc, где эта возможность будет реализована - тогда можно будет оценить удобство и юзабилити в полноценном варианте.

[slackovod]

>И не получится ли в итоге так, что выиграв бой я проиграю все сражение?
в обертку запихать, нэ?

[Flex Ferrum]

в обертку запихать, нэ?

А смысл, если того же самого можно добиться без привлечения сторонних средств и создания оберток?

[slackovod]

прям того же? да и шаблон это достаточно рапространен(кучи всяких врапперо-адаптеро-декораторов), так что ничего особо сложного и нового быть в этом недолжно.