LINUX.ORG.RU

C++ : Loki, Boost....что дальше. Каковы перспективные направления в развитии.


0

0

Всем привет!

Меня интересует конкретный вопрос (а никак не флэйм).
Вот сейчас, с появлением Loki и Boost, мне уже сложно себе
представить, что можно придумать что-то новое в области
красивой, кроссплатформенной реализации паттернов проектирования
и популярных приёмов программирования.
Кажется, что уже всё придумано и до принятия нового стандарта C++ в
2009 можно расслабиться и не иметь себе мозги.

Может кто-нибудь знает, над чем сейчас бьются лучшие умы в области
C++ (Александреску, Саттер, Майерс, Страуструп и другие), что 
вынесено на повестку дня сегодня?

Речь идёт не об узкоспециализированном проектировании кортежного типа,
а об общих вопросах, волнующих прикладных программистов.

А может уже исчерпаны возможности C++, как конструктора, из которого
можно делать практически всё (и как показал Mr. Александреску очень 
красиво). И не увидит свет в ближайшем будующем библиотеки, по мощи
сравнимой с Loki?

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

Вообщем, что по вашему мнению сейчас наиболее актуально в контексте
программирования и проектирования с использованием C++?


P.S.
1) Зарание прошу всех флэймеров, коих на ЛОРе всегда было очень много,
не вмешиваться в обсуждение вопроса.
2) Также прошу сторонников других языков программирования воздержаться
от предложений забить на C++ и перейти на их любимый язык.

Всем спасибо!
anonymous

Даже сложно представить, функциональное программирвание сделали, хоть и через Ж, на ооп фактически забили, как часть ФП. Какое есть ещё программирование? О! Аспектно-ориентированное, в жабе оно уже есть, а вот в плюсах особо не видел(может плохо смотрел).

anonymous
()
Ответ на: комментарий от anonymous

localhost loki # g++ test1.cpp -I /usr/include/FerrisLoki/
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h: In instantiation of &#8216;Loki::GenScatterHierarchy<Loki::Typelist<int, Loki::Typelist<int, Loki::NullType> >, Loki::TupleUnit>&#8217;:
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h:121: instantiated from &#8216;Loki::Tuple<Loki::Typelist<int, Loki::Typelist<int, Loki::NullType> > >&#8217;
test1.cpp:8: instantiated from here
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h:62: warning: direct base &#8216;Loki::GenScatterHierarchy<int, Loki::TupleUnit>&#8217; inaccessible in &#8216;Loki::GenScatterHierarchy<Loki::Typelist<int, Loki::Typelist<int, Loki::NullType> >, Loki::TupleUnit>&#8217; due to ambiguity
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h: In static member function &#8216;static typename Loki::Select<Loki::FieldHelper<H, 0u>::isConst, const typename Loki::Select<Loki::FieldHelper<H, 0u>::isTuple, typename H::TList::Head, typename H::Rebind<typename H::TList::Head>::Result>::Result, typename Loki::Select<Loki::FieldHelper<H, 0u>::isTuple, typename H::TList::Head, typename H::Rebind<typename H::TList::Head>::Result>::Result>::Result& Loki::FieldHelper<H, 0u>::Do(H&) [with H = Loki::Tuple<Loki::Typelist<int, Loki::Typelist<int, Loki::NullType> > >]&#8217;:
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h:205: instantiated from &#8216;typename Loki::FieldHelper<H, i>::ResultType& Loki::Field(H&) [with int i = 0, H = main()::Point2D]&#8217;
test1.cpp:9: instantiated from here
/usr/include/FerrisLoki/Reference/HierarchyGenerators.h:156: error: &#8216;Loki::GenScatterHierarchy<int, Loki::TupleUnit>&#8217; is an ambiguous base of &#8216;Loki::Tuple<Loki::Typelist<int, Loki::Typelist<int, Loki::NullType> > >&#8217;
localhost loki # cat test1.cpp
#include <Typelist.h>
#include <Tuple.h>
#include <HierarchyGenerators.h>
#include <iostream>
int main(void){
using namespace Loki;
typedef Tuple< TYPELIST_2(int, int) > Point2D;
Point2D pt;// = new Point3D();
Field<0>(pt) = 0;
Field<1>(pt) = 99;
int i = static_cast<int>(Field<1>(pt));
std::cout <<i ;
return 0;
}

localhost loki #

Где лопата:((( Пример один в один из "Современное проектирование на с++"

anonymous
()

>А может уже исчерпаны возможности C++, как конструктора, из которого можно делать практически всё (и как показал Mr. Александреску очень красиво). И не увидит свет в ближайшем будующем библиотеки, по мощи сравнимой с Loki?

boost::mpl boost::lambda

anonymous
()

да и вообще loki хороша в обучении лишь, в реале все равно что то придется переделывать

anonymous
()
Ответ на: комментарий от anonymous

код инклудников надо смотреть, у Александреску кажется были приколы с тем, что когда определяешь шаблоны с наследованием, то он пишет так
template <typename A>
struct B: public A{
 ...
 func_from_A();
...
};

а надо

template <typename A>
struct B: public A{
 ...
 A::func_from_A();
...
};

также были вроде приколы с конструкторами типа
template <typename C>
struct B: public A < C > {
 ...
 B(): A() {}
...
};

надо так
template <typename C>
struct B: public A < C > {
 ...
 B(): A < C > () {}
...
};

ну и еще какие-то мелочи, студия (даже последняя 2005я) это всё хавает без проблем, а вот gcc обламывается.

Reset ★★★★★
()

>Меня интересует конкретный вопрос (а никак не флэйм). Вот сейчас, с появлением Loki и Boost, мне уже сложно себе представить, что можно придумать что-то новое в области красивой, кроссплатформенной реализации паттернов проектирования и популярных приёмов программирования.

Странное утверждение. Глядя на boost, boost::spirit я всегда думал, что это наглядный пример того, что С++ давно исчерпал свои возможности и нужно что-то новое (а здесь вобщемто простые вещи выливаются в неоправданный геморрой)

anonymous
()
Ответ на: комментарий от anonymous

+1. boost это тот монстр который показывает, что расширение языка средствами шаблонов очень ограничено.

Bob1
()
Ответ на: комментарий от aton

супер!!! язык, для которого нормального компилятора под все популярные платформы нет...........

anonymous
()
Ответ на: комментарий от Bob1

> расширение языка средствами шаблонов очень ограничено. Бред, шаблоны позволяют писать обобщенный и одновременно надежный код + метапрограммы

aton
()

вы нам лучше расскажите чего бы вам хотелось например.

AnToXa
()
Ответ на: комментарий от aton

Зато код на шаблонах замучаешься отлаживать. И реализация языка шаблонов в компиляторах тормозная.

Хотя нужно признать, что шаблоны - одна из наиболее полезных черт С++. Да и классы в С++ нужно расматривать не столько в контексте ООП, сколько в контексте метапрограммирования на шаблонах (template metaprogramming).

Плохо, что такими мощными они стали, видимо, по случайности - шаблоны (в связи с метапрограммированием) не похожи на хорошо спроектированную возможность языка. Нормальная поддержка ФП и defmacro дала бы С++ гораздо более мощные и понятные средства метапрограммирования.

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

> код на шаблонах

Имеются ввдиду в первую очередь метапрограммы.

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

> Зато код на шаблонах замучаешься отлаживать
Все зависит от глубины понимания языка + всегда можно написать
конкретный тип, и только после отладки сделать его обобщенным

> наиболее полезных черт С++
Наиболее полезная черта С++ это статическая типизация

> шаблоны (в связи с метапрограммированием) не похожи на хорошо спроектированную возможность языка

Просто надо научится их готовить

> Нормальная поддержка ФП и defmacro дала бы С++ гораздо более мощные и понятные средства метапрограммирования

Нормальная это удобная для Вас?

aton
()
Ответ на: комментарий от aton

>Нормальная это удобная для Вас?

поддержку ФП в С++ сложно назвать нормальной в любом мыслемом смысле

anonymous
()
Ответ на: комментарий от aton

> Наиболее полезная черта С++ это статическая типизация
При динамической шаблоны не нужны.

> Просто надо научится их готовить
Страуструп в Design and Evolution of the C++ Language писал, что шаблоны
изначально вводились в язык для поддержки полиморфных типов данных.
Средством метапрограммирования они стали уже позже. Точнее было
обнаружено, что их можно использовать в качестве средства
метапрограммирования.

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

> Нормальная это удобная для Вас?
Нормальная - это без костылей типа boost::lambda. boost::lambda, boost::functional и иже с ними - это костыли, обусловленные
отсутвием в языке функций как объектов первого порядк и замыканием
функций в контексте определения.

См. http://www.haskell.org/yale/papers/icsr98/index.html

ЗЫ: по поводу defmacro я так понимаю, возражений нет?

Begemoth ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.