Здесь: http://www.artima.com/cppsource/cpp0x.html

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здесь: http://www.artima.com/cppsource/cpp0x.html

Спасибо, интересно.
Наконец то дождались auto (хотя ждать то в принципе еще долго )

template typedef тоже хорошая вещь.

список инициализации для user-defined container "кульная вещь" (хотя на самом деле нафиг не нужна),
теперь (лет через пять) легче станет писать тестовые программки.

возможность писать после template угловые скобки без пробела конечно клёва, но я уж с пробелом привык писать.

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здесь: http://www.artima.com/cppsource/cpp0x.html

auto — насущнейшая неоходимость.
template typedef — удобно, но можно обойтись.

всё остальное — популизм, ненужный, причём не бесплатный, а через ещё большее усложнение языка.
голосование — http://www.livejournal.com/users/aruslan/42425.html?thread=116921#t116921
моё IMHO — http://www.livejournal.com/users/aruslan/42425.html?thread=116921#t116921

Здравствуйте, _Winnie, Вы писали:

_W>моё IMHO — http://www.livejournal.com/users/aruslan/42425.html?thread=116921#t116921

Концепты. Абсолютно бесмысленная штука.
Какая разница, где компилятор укажет на ошибку, прямо в боевом коде или в концепте? А как он будет проверять incomplete-типы?
А чем плох if (0) { проверить, что можно скопировать/вызвать метод ++/разыменовать } для ранней диагностики?

С этим не согласен. С++ -- это статически типизированный язык и концепты позволяют сделать шаблонный duck typing более строгим и формализованным. Причем, преимущества концептов в том, что они указываются в спецификации, т.е. глядя на прототип функции можно понять, какие аргументы она требует. А от if(0){} концепты выгодно отличаются тем, что могут использоваться повторно. И, как я понимаю, Страуструп предполагает, что в стандартной библиотеке и в библиотеках типа boost будет находиться множество уже готовых концептов, которые можно будет использовать не изобретая собственные.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, _Winnie, Вы писали:

_W>>моё IMHO — http://www.livejournal.com/users/aruslan/42425.html?thread=116921#t116921
E>

E>А чем плох if (0) { проверить, что можно скопировать/вызвать метод ++/разыменовать } для ранней диагностики?

E>С этим не согласен. С++ -- это статически типизированный язык и концепты позволяют сделать шаблонный duck typing более строгим и формализованным. Причем, преимущества концептов в том, что они указываются в спецификации, т.е. глядя на прототип функции можно понять, какие аргументы она требует.
Ну, можно посмотреть и в какое-нибудь другое место, главное договориться где.
>А от if(0){} концепты выгодно отличаются тем, что могут использоваться повторно.
А что мешат использовать их повторно?

template <class T> void can_behave_as_random_iterator()
{
    if (0)
    {
        T *x = NULL;
        T y, z = *x;
        ++y; ++y; y = z; --z; z--; *z; z[2]; x+1; z-1;
        *x = *z;
    }
}

>И, как я понимаю, Страуструп предполагает, что в стандартной библиотеке и в библиотеках типа boost будет находиться множество уже готовых концептов, которые можно будет использовать не изобретая собственные.
Да. В стандартной библиотеке. А не в core языка.

PS. Если концепт STL вдруг вздумает проверять вот этот пункт —

17.4.3.6 Other functions
2 In particular, the effects are undefined in the following cases:
— if an incomplete type (3.9) is used as a template argument when instantiating a template component.

то мне придётся придумывать, как отковырять эти концепты из либы.

(так как люблю фокусы в стиле)
struct Tree
{
  std::map<std::string, Tree> childs;
};


struct Incomplete;

struct Wrapper
{
  std::auto_ptr<Incomplete> m_pImpl;
  ~Wrapper();  
};

Здравствуйте, _Winnie, Вы писали:

_W>Ну, можно посмотреть и в какое-нибудь другое место, главное договориться где.

Ну дык при объявлении прототипа функции, в h-файле.

>>А от if(0){} концепты выгодно отличаются тем, что могут использоваться повторно.
_W>А что мешат использовать их повторно?

_W>

_W>template <class T> void can_behave_as_random_iterator()
_W>{
...
_W>}
_W>

И где мне использовать can_behave_as_random_iterator()? Внутри моего кода? Так это я и сейчас могу делать. Красота концептов именно в использовании их в декларациях, а не в реализации.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, _Winnie, Вы писали:

_W>>Ну, можно посмотреть и в какое-нибудь другое место, главное договориться где.

E>Ну дык при объявлении прототипа функции, в h-файле.
E>И где мне использовать can_behave_as_random_iterator()? Внутри моего кода? Так это я и сейчас могу делать. Красота концептов именно в использовании их в декларациях, а не в реализации.

Красота? А функциональность?

Поскольку они нужны для шаблонов, а почти все шаблоны живут в .h файлах, то можно их помещать для шаблонных функций прямо первой строчкой, а для шаблонных классов — в деструктор.

Чесслово. Лучше бы озаботились стандартной библиотекой сокетов, интерфейсу к базам данных, GUI, асинхронным IO, нормальной файловой системой и тд.

А для core language — это как минимум compile-time reflection, а как максимум — возможность засунуть любой свой язык внутрь С++, описав его правила, без всяких var, ch_p

//boost::lambda
var(i) + cref(j) 

//boost::spirit
ch_p('a') >> 'b' >> 'c' >> 'd'

_Winnie wrote:
> Чесслово. Лучше бы озаботились стандартной библиотекой сокетов,
> интерфейсу к базам данных, GUI, асинхронным IO, нормальной файловой
> системой и тд.
AIO+Sockets и FS скоро будут в Boost'е (идет review), потом их подадут в
TR2.

> А для core language — это как минимум compile-time reflection, а как
> максимум — возможность засунуть любой свой язык внутрь С++, описав его
> правила, без всяких var, ch_p
Угу Как хотелось бы иметь нормальный метакод...

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здесь: http://www.artima.com/cppsource/cpp0x.html
Тогда еще это:
[ulr=http://public.research.att.com/~bs/rules.pdf]Bjarne Strousrup: The Design Of C++0x in CUJ May 2005[/url].

Здравствуйте, Cyberax, Вы писали:

C>AIO+Sockets и FS скоро будут в Boost'е (идет review), потом их подадут в
C>TR2.

Интересно а как осущесвляется этот самый AIO без встроенных threads?
Т.е. tr2 должен иметь treads еще от boost.

no way in C++.

Здравствуйте, _Winnie, Вы писали:


_W>Чесслово. Лучше бы озаботились стандартной библиотекой сокетов, интерфейсу к базам данных, GUI, асинхронным IO, нормальной файловой системой и тд.

Это из другой оперы мне кажется. Библиотеки это не язык.

Здравствуйте, _Winnie, Вы писали:

E>>И где мне использовать can_behave_as_random_iterator()? Внутри моего кода? Так это я и сейчас могу делать. Красота концептов именно в использовании их в декларациях, а не в реализации.

_W>Красота? А функциональность?

Функциональность та же самая.

_W>Поскольку они нужны для шаблонов, а почти все шаблоны живут в .h файлах, то можно их помещать для шаблонных функций прямо первой строчкой,

Вот не нравится мне смотреть в код, а не на интерфейс. Если я вижу:

template< class T >
void some_useful_func( const T & a, const T & b )
when can_behave_as_random_iterator< T >;

то сразу понимаю, что к чему. Не нужно даже в код заглядывать. А еще инструменты вроде doxygen смогут такую информацию в документацию закидывать.

_W>а для шаблонных классов — в деструктор.

А вот нужны ли concept-ы для шаблонных классов -- это для меня вопрос. Весь шаблонный класс может накладывать на параметр шаблона массу ограничений, но реально потребуются только те, которые используются в вызываемых из класса методах. Если я использую из std::vector только push_back() и size() в каком-то случае, то мне не важно, какие требования std::vector будет накладывать на T в остальных своих методах (за исключением конструктора и деструктора std::vector).

_W>Чесслово. Лучше бы озаботились стандартной библиотекой сокетов, интерфейсу к базам данных, GUI, асинхронным IO, нормальной файловой системой и тд.

А здесь прогресса нужно уже не от Страуструпа требовать. А пытаться консолидироваться вокруг того, что уже есть. Например, многое из того, что ты перечислил, есть в ACE и не очень здраво, имхо, переписывать все это в Boost заново только ради Boost-style.

Базы данных... Взять хотя бы OTL за основу.

Стандартный GUI -- это вообще утопия. Даже в Java этих стандартов уже поменялось: AWT, Swing. Теперь еще SWT (или что там в Eclipse используют).

Только на это все денег у комитета нет. И не будет.

_W>А для core language — это как минимум compile-time reflection, а как максимум — возможность засунуть любой свой язык внутрь С++, описав его правила, без всяких var, ch_p

Может лучше не нужно из C++ еще и язык для метапрограммирования делать?
Вот C -- прост как автомат Калашникова. И посмотрите -- Apache на C, Subversion на C, Linux (*BSD) -- на C, куча софта в Unix-ах на C написана. И нормально все. Потому что извращаться негде.

Имхо, совершенно напрасно существует ярлык "написан на C с классами". Вот ACE написан на "C с классами". Блин, ну реально крутая штука. Попробуй еще так написать. И вместо того, чтобы делать на C++ монстров с compile-time вычислениями, десятиэтажными шаблонами, примитивными попытками сделать существующими средствами что-то а-ля лямбда или замыканий, лучше писать проще, но на нескольких языках сразу (включая скриптовые и функциональные). С привлечением DSL и кодогенерации.

Lisp вон изначально крутой и расширяемый. Только софт на нем написанный искать нужно днем с огнем. Неужели мы из C++ такого же монстра хотим сделать?

Здравствуйте, c-smile, Вы писали:

C>>AIO+Sockets и FS скоро будут в Boost'е (идет review), потом их подадут в
C>>TR2.
CS>Интересно а как осущесвляется этот самый AIO без встроенных threads?
А зачем они для асинхронного ввода/вывода нужны? Смотри http://asio.sf.net

CS>Т.е. tr2 должен иметь treads еще от boost.
CS>no way in C++.
Boost.Threads тоже пойдет в TR2.

Здравствуйте, 0xDEADBEEF, Вы писали:

DEA>Здесь: http://www.artima.com/cppsource/cpp0x.html
В статье ведь потенциальная утечка памяти?

vector<Shape*> v = {
    new Circle(p1,20),
    new Triangle(p1,p2,p3),
    new Rectangle(p3,30,20)
};

draw_all(v);

list<shared_ptr<Shape*>> v2 = {
    new Circle(p1,20),
    new Triangle(p1,p2,p3),
    new Rectangle(p3,30,20)
};

draw_all(v2);

Т.е. все эти generalized initializer lists опять лишь для примеров как <iostream>??
И novices как писали небезопасный код так и будут... Зато красиво блин

Здравствуйте, Pavel Chikulaev:

Отвечу сам себе.

DEA>>Здесь: http://www.artima.com/cppsource/cpp0x.html
PC>В статье ведь потенциальная утечка памяти?
Не обязательно, но скорее всего

Подробно:
Все зависит от того какой sequence constructor определен для класса.

Если std::vector<T>::vector(T const * first, T const * last), то потенциальная утечка памяти,
если у std::vector<T> появится частичная специализация для указателей, возможно добавление sequence constructor'а

template<typename T>
struct vector<T *>
{
//...
   vector (std::auto_ptr<T> const * first, std::auto_ptr<T> const * second);
//...
};

тогда соответственно утечки не будет. Но к сожалению, в такую специализацию верится с трудом.

Подробнее о sequence constructor'ах тут.

Интересный момент:
C++03:

T a = getT1();
T b = getT2();
T c = getT3();
//some calculations on a, b, c

std::vector<T> v;
v.push_back(a);
v.push_back(c);
v.push_back(b);

С++0x:

T a = getT1();
T b = getT2();
T c = getT3();

//some calculations on a, b, c

std::vector<T> v = { a, c, b };

В С++03 одно копирование на добавление элемента в вектор,
в C++0х — два, причем sequence constructor не сможет поддерживать move construction .
Т.к. указатели на ссылки (а также &&) никто разрешать не будет.
Хотя в некоторых случаях компилятор сможет удалить лишние копирования, но не всегда.
Например тут сможет:

T a[3];
std::vector<T> v = { a[0], a[1], a[2] };

В примере с a, b, c можно избежать копирования, если они расположены друг за другом в порядке a, c, b.
Если список один из элементов по середине initializer list'а — ссылка, копирования не избежать.

Вот такой он красивый и эффективный этот С++0х.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, c-smile, Вы писали:

C>>>AIO+Sockets и FS скоро будут в Boost'е (идет review), потом их подадут в
C>>>TR2.
CS>>Интересно а как осущесвляется этот самый AIO без встроенных threads?
C>А зачем они для асинхронного ввода/вывода нужны? Смотри http://asio.sf.net

Для асинхронного нужны — без них никак. А вот для синхронного как раз не требуются.

См. например:
http://asio.sourceforge.net/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp


CS>>Т.е. tr2 должен иметь treads еще от boost.
CS>>no way in C++.
C>Boost.Threads тоже пойдет в TR2.

А дальше чего будет?

Pavel Chikulaev wrote:
> DEA>Здесь: http://www.artima.com/cppsource/cpp0x.html
> В статье ведь потенциальная утечка памяти?
Там написано, что будет опциональный GC

> Т.е. все эти generalized initializer lists опять лишь для примеров как
> <iostream>??
Ага. Причем как и для iostreams'ов построят крутую, красивую и
совершенно неюзабельную систему...

> И novices как писали небезопасный код так и будут... Зато красиво блин
"Повбiвав бы" (с) анекдот.

--
С уважением,
Alex Besogonov (alexy@izh.com)

c-smile wrote:
> CS>>Интересно а как осущесвляется этот самый AIO без встроенных threads?
> C>А зачем они для асинхронного ввода/вывода нужны? Смотри http://asio.sf.net
> Для асинхронного нужны — без них никак.
Уверены? Посмотрите паттерн Proactor —
http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf

Он поддерживает многотредовость, но не требует ее.

> См. например:
> http://asio.sourceforge.net/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp
То что там есть поддержка тредов — не значит, что без них работать нельзя.

> CS>>Т.е. tr2 должен иметь treads еще от boost.
> CS>>no way in C++.
> C>Boost.Threads тоже пойдет в TR2.
> А дальше чего будет?
После TR2 будет обсуждение и включение в Стандарт.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

PC>> В статье ведь потенциальная утечка памяти?
C>Там написано, что будет опциональный GC
Ок. Опционально потенциальная утечка памяти

Кстати с этим опциональным GC будет очень интересная ситуация — уже есть existing practice в виде C++/CLI, но в таком виде как он в C++/CLI его добавлять нельзя — в основном из-за ограничений, наложенных самим CLI (например hydebysig, другой lookup и.т.д.). И перед коммитетом будет стоять трудная задача — или добавить то, что уже продумали, но будет абсолютно не логично для С++ users, или самим что-то придумывать, что не будет совместимо с C++/CLI, и тогда C++0x скорее всего лишь будет еще одним стандартным диалектом языка C++, который Microsoft по-любому не будет поддерживать...
Да и вообще этот GC не сильно нужен в таком языке как C++, ИМХО это просчет Bjarne Stroustrup.
З.Ы. А нам-то всего лишь надо move semantics, auto и concepts... и threads
З.З.Ы. Как C++ был too "expert friendly", так им и останется. (Не знаю радоваться и огорчаться по этому поводу).

Pavel Chikulaev wrote:
> PC>> В статье ведь потенциальная утечка памяти?
> C>Там написано, что будет опциональный GC
> Ок. Опционально потенциальная утечка памяти
Согласен.

> Кстати с этим опциональным GC будет очень интересная ситуация — уже есть
> existing practice в виде C++/CLI
Я думаю, за основу возьмут консервативную сборку мусора. Точная сборка
тянет за собой слишком много всего.

> но в таком виде как он в C++/CLI его добавлять нельзя — в основном
> из-за ограничений, наложенных самим CLI (например hydebysig, другой
> lookup и.т.д.)
На самом деле, если рассматривать байт-код CLR просто как целевую
платформу для компиляции, то можно сравнительно нормально реализовать
всю семантику С++. Проблемы начинаются при попытке сделать С++
безопасным и интероперабельным с остальным .NET

Я как-то прикидывал ради интереса что нужно добавить в С++ для поддержки
точной сборки — получалось не сильно много всего.

> стоять трудная задача — или добавить то, что уже продумали, но будет
> абсолютно не логично для С++ users, или самим что-то придумывать, что не
> будет совместимо с C++/CLI, и тогда C++0x скорее всего лишь будет еще
> одним стандартным диалектом языка C++, который Microsoft по-любому не
> будет поддерживать...
У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".

> Да и вообще этот GC не сильно нужен в таком языке как C++, ИМХО это
> просчет Bjarne Stroustrup.
GC бывает все же нужен в задачах по обработке сложных структур данных,
где сложно выделить политики владения (например, в достаточно сложных
компиляторах).

> З.Ы. А нам-то всего лишь надо move semantics, auto и concepts... и threads
Еще бы reflection (compile-time) хотелось бы. И метакод, работающий на
уровне методов (а не только типов).

--
С уважением,
Alex Besogonov (alexy@izh.com)