Мысли об обобщенном программировании, шаблонах и UML

[Kostia]

Да, легко. Библиотека не имеет функций работы с деревьями, что очень осложняет жизнь. Хотя, на основе деков это можно бы было зделать. Ан, - нет. Мозгов не хватило, наверное, у разработчиков.

В STL с такой точки зрения вообще ничего нет. Поэтому и существуют loki, boost и пр. Хотя отсутствие такой базовой структуры как деревья, действительно досадно.
Но те классы что имеются выполнены вполне сносно и работают достаточно быстро. Конечно если знать как они работаю и какими возможностями обладают, иначе ругаться на них можно хоть каждый день без выходных, что они медленные и их писали криворукие, как многие и любят.
______________
Кстати, а как с деревьями в C#?

[Smitt&Wesson]

Сообщение от Kostia

В STL с такой точки зрения вообще ничего нет. Поэтому и существуют loki, boost и пр. Хотя отсутствие такой базовой структуры как деревья, действительно досадно.
Но те классы что имеются выполнены вполне сносно и работают достаточно быстро. Конечно если знать как они работаю и какими возможностями обладают, иначе ругаться на них можно хоть каждый день без выходных, что они медленные и их писали криворукие, как многие и любят.
______________
Кстати, а как с деревьями в C#?

Её писали не криворукие. Просто (видимо, в те времена) деревья были не актуальны. Ну, осталась эта библиотека, как рудименарный отросток. И с этим поделать ничего нельзя, увы.

[Kostia]

Её писали не криворукие. Просто (видимо, в те времена) деревья были не актуальны. Ну, осталась эта библиотека, как рудименарный отросток. И с этим поделать ничего нельзя, увы.

А с ней ничего делать не надо, она потихоньку расширяется.

Будет ли С++1y?
Почти наверняка, даже несмотря на то, что комитет засиделся с С++11. Я часто слышу мнение о том, что для сокращения срока стандартизации, комитет должен начать работать над C++1y сразу же после утверждения С++11. Десятилетний интервал между стандартами – это слишком длительный период времени для текущего темпа развития технологии, поэтому некоторые предлагают трехлетний интервал. Лично я склоняюсь, что пятилетний интервал является более реалистичным. Так что, ждем C++16?

Слава богу "растет" альтернатива ^^, я про D.

[Smitt&Wesson]

А с ней ничего делать не надо, она потихоньку расширяется.

Ой, ой, ой. Уже лет двадцать, в ней ничего нового нет. И с чего Вы взяли что она "расширяется"?
Примерчик, если можно.

[Kostia]

Примерчик, если можно.

С++11
Введение такой штуки как переменное кол-во шаблоных параметров, породила такой тип как tuple.

template<typename... _Elements> 
    class tuple : public _Tuple_impl<0, _Elements...>

Пользоваться им так:

std::tuple<std::string,double,int> elems("xxx",3.141,5);
std::cout << std::get<0>(elems);

Ради интереса реализовал простой класс функтора:

template <class ResultType, class ... Args>
class FunctorImpl
{
private:
public:
    virtual ~FunctorImpl(){}
    virtual ResultType operator()(const Args&... args) = 0;
};

template <class ResultType, class PointerToObj, class PointerToFunc, class ... Args>
class FunctorHandlerC: public FunctorImpl<ResultType, Args ...>
{
private:
    PointerToObj obj;
    PointerToFunc fn;
public:
    FunctorHandlerC(PointerToObj pObj, PointerToFunc pFn): obj(pObj), fn(pFn){}

    ResultType operator()(const Args&... args)
    {
        return (obj->*fn)(args ...);
    }
};

template <class ResultType, class PointerToFunc, class ... Args>
class FunctorHandlerF: public FunctorImpl<ResultType, Args ...>
{
private:
    PointerToFunc fn;
public:
    FunctorHandlerF(PointerToFunc pFn): fn(pFn){}

    ResultType operator()(const Args&... args)
    {
        return fn(args ...);
    }
};

template <class ResultType = void, class ... Args>
class Functor
{
    typedef FunctorImpl<ResultType, Args ...> Impl;
    auto_ptr<Impl> pImpl;
public:
    template <class PointerToObj, class PointerToFunc>
    Functor(PointerToObj _dest, PointerToFunc _fn) : pImpl(new FunctorHandlerC<ResultType, PointerToObj, PointerToFunc, Args ...>(_dest, _fn)){}
    template <class PointerToFunc>
    Functor(PointerToFunc _fn) : pImpl(new FunctorHandlerF<ResultType, PointerToFunc, Args ...>(_fn)){}
    ResultType operator()(const Args&... args)
    {
        return (*pImpl)(args ...);
    }
};

Пользуюсь я этим так:

glw->setDisplay(new Functor<void>(this, &GAMEEngine::Display));

Хотя и можно было обойтись и лямбда выражениями. Суть этой записи таковы, если класс GLWindow, который создает окно и нициализирует OpenGL для каждой оси своими методами, есть класс GAMEEngine, который передает свои мотоды классу GLWindow в качестве обработчиков событий.
Ну и подписать таких методов к одному GLWindow может куча классов, а GLWindow просто вызывает их по очереди. Все просто. Так события перемещения курсора, нажатия клавиш и изменения состояния окна расползаются по все системе. GLWindow есть singleton.
Чет понесло ))

Я уже упоминал о async для асинхронного вызова функций. То бишь параллелизм.
Достаточно мощная библиотека random.
mersenne_twister_engine
Да много чего еще, см тут, все что с пометкой c++11.
Обязательно нужно упомянуть о появлении регулярных выражений в стандартной библиотеке.

[Utkin]

И какую же стратегию поведения они используют? И могу ли я ее поменять?

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

google code и source forge еще существуют.

Сколько крупных коммерческих фирм их используют?

Scheme ужасен, это два.

Нарветесь на холивар. Ок, как говорили в одном фильме - какие Ваши доказательства ?

Источник?

Источник Хаскелл. У-у-у, как все запущено...

Не оно:

Не оно .

Не встречал еще ни одного нормально работающего mono приложения!

Потому что и не искали. Элементарно примеры есть в википедии http://ru.wikipedia.org/wiki/Mono Писать что-то о чем имеете весьма смутное представление - осуждаю.

scheme я назвал ужасным только по личной неприязни к синтаксису:

Это от отсутствия желания понимать язык.

Я просто не представляю как можно писать что-то серьезное на этом языке. Это же получится здоровенная портянка кода.

Это уже от откровенного раздолбайства. Конечно нельзя же определить функцию for. Извините, но счас буду ругаться на такую совершенно тупую отмазку. Вы же всегда на с++ используете китайский и индусский код и не пользуетесь методами и функциями... Да и define Вам явно не знаком.

Почему так все пробиваются по этому scheme. Может мне кто глаза раскроет?

Я - внезапно открываем Racket (пока сайт), берем нужную библиотеку и все.

Кстати, а как с деревьями в C#?

Печально.

Слава богу "растет" альтернатива ^^, я про D.

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

С++11

Я может повторюсь - но Вы с таким восторгом решаете проблемы которых просто нет в том же Шеме... .

ЗЫ. Кстати, Вы должны быть в курсе, что Вами любимый D использует так непонятую Вами сборку мусора.

[Kostia]

Источник Хаскелл. У-у-у, как все запущено...

Вы ничего не путаете, существуют разные концепции обобщенного программирования.
Подход Массерв и Степанов (C++)
Подход Ричарда Бёрдома и Ламберта Меертенсна (Haskell)

Цитирую wiki:

Альтернативный подход к определению обобщённого программирования, который можно назвать обобщённым программированием типов данных (англ. datatype generic programming), был предложен Ричардом Бёрдом и Ламбертом Меертенсом. В нём структуры типов данных являются параметрами обобщённых программ. Для этого в язык программирования вводится новый уровень абстракции, а именно параметризация по отношению к классам алгебр с переменной сигнатурой. Хотя теории обоих подходов не зависят от языка программирования, подход Массера-Степанова, делающий упор на анализ концепций, сделал C++ своей основной платформой, тогда как обобщённое программирование типов данных используют почти исключительно Haskell и его варианты.

ЗЫ. Кстати, Вы должны быть в курсе, что Вами любимый D использует так непонятую Вами сборку мусора.

К счастью я знаю! И с чего вы взяли что она мне не непонятна? Я говорю что его наличие или отсутствие не считаю за большой плюс или минус(наверное меня так научили, что я на этом еще ни разу не споткнулся), а вот к примеру встроенные средства для "параллельного" программирования считаю большим плюсом. Все это исключительно мое мнение.

Я может повторюсь - но Вы с таким восторгом решаете проблемы которых просто нет в том же Шеме...

У него своих проблем хватает. Тем более в c++11 многих старых проблем поубавилось и тот код что я привел выше можно обобщить и расширить(это не касается c++11, там все это уже есть) до введения значений по умолчанию и сцеплений функций. Конечно C++ проигрывает в этом плане чисто функциональным языкам.

Нарветесь на холивар. Ок, как говорили в одном фильме - какие Ваши доказательства ?

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

Это уже от откровенного раздолбайства. Конечно нельзя же определить функцию for. Извините, но счас буду ругаться на такую совершенно тупую отмазку. Вы же всегда на с++ используете китайский и индусский код и не пользуетесь методами и функциями... Да и define Вам явно не знаком.

Макросы, вы издеваетесь? o_O
За все время программирования я использовал #define только в таком контексте:

#ifdef __gnu_linux__
    #include <X11/X.h>
    #include <X11/Xlib.h>
    #include <GL/glx.h>
#elif _WIN32 || __WIN32__
    #include <windows.h>
#endif

____________________________
Правда тут я наверно точно сплоховал.

Я - внезапно открываем Racket (пока сайт), берем нужную библиотеку и все.

Вы бы мне не набор библиотек показали, а реально работающие программы. Которую я могу скачать, запустить и оценить. Т.к. я могу кучу ссылок на библиотеки для др. языков дать. И я более чем уверен что размеры кода в серьезном проекта на том же scheme, даже с учетом минимального написания велосипедов, будет такой же как и на многих других распространенных языках.
А те примеры которые я нашел для построения фракталов и пр. как вы выражаетесь студенческие задачки. Впрочем я не отрицаю что сложная логика(разные математические задачи, задачи требующие рекурсии и многие др.) на scheme будет написана гораздо более компактно нежели чем на C и многих других языках, т.к. это исходит из самой идеологии языка, но вот читать код на scheme мне лично было очень сложно, хотя тот же руби читался практически сразу после прочтения документации.
С++ считаю уже практически умершим, только если не выпустят полностью перестроенный C++2.0, но уже есть D.

[pu4koff]

Сообщение от Kostia

У него своих проблем хватает. Тем более в c++11 многих старых проблем поубавилось и тот код что я привел выше можно обобщить и расширить(это не касается c++11, там все это уже есть) до введения значений по умолчанию и сцеплений функций. Конечно C++ проигрывает в этом плане чисто функциональным языкам.

Как раз старые проблемы в плюсах толком и не решают. Добавляют новые не самые полезные фичи, а нужного так и нет. Я бы уже не трогал этот язык, а развивал пусть тот же D или еще что получше.
А если по теме: оказывается и подходов в обобщенном программировании несколько, т.е. опять повторное использование не получается в разных проектах. Всё в этом программировании не слава богу.

[Kostia]

Как раз старые проблемы в плюсах толком и не решают. Добавляют новые не самые полезные фичи, а нужного так и нет. Я бы уже не трогал этот язык, а развивал пусть тот же D или еще что получше.

Да, тут я согласен.
Но на самом деле проблема не в языке, а в комитете по его стандартизации! Существует отличный пример когда отдавали технологию в конкретные руки и эта технология обретала новую жизнь. Я про OpenGL. Вышел OpenGL 3.3 в котором полностью отрезали весь хлам тянувшийся с 90х годов.

А если по теме: оказывается и подходов в обобщенном программировании несколько, т.е. опять повторное использование не получается в разных проектах. Всё в этом программировании не слава богу.

В том то и проблема.
Если взять тот же UML, он не привязан к конкретному языку, но он является расширяемым и куча разных редакторов UML и генераторов кода понаплодили всякого.

[pu4koff]

Сообщение от Kostia

Да, тут я согласен.
Но на самом деле проблема не в языке, а в комитете по его стандартизации! Существует отличный пример когда отдавали технологию в конкретные руки и эта технология обретала новую жизнь. Я про OpenGL. Вышел OpenGL 3.3 в котором полностью отрезали весь хлам тянувшийся с 90х годов.

Даже страуструп с этим коммитетом не дружит, поэтому на плюсы я бы забил.

Сообщение от Kostia

В том то и проблема.
Если взять тот же UML, он не привязан к конкретному языку, но он является расширяемым и куча разных редакторов UML и генераторов кода понаплодили всякого.

В случае с UML всё правильно. Это универсальный язык для проектирования и тут нужна гибкость, посему всё должно быть свободно. Привязывать UML к конкретным языкам - это уже не UML и не для проектирования, а для разработки.
Популярные современные языки дают плохую почву для повторного использования кода, распределенного создания библиотек и т.д. и т.п. Посему, на имеющихся технологиях я бы не брался за попытки все эти, сумбурно описанные в теме, мысли воплощать в жизнь. Нужно разрабатывать отдельный язык с отдельной философией.