Здесь: 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)

Здравствуйте, Cyberax.

Давай перейдем к фактам:
Proposal: Transparent Garbage Collection for C++ (N1833).
Так скорее всего и будет в C++0x (с некоторыми незначительными измениями наверно).

Все-таки мне не очень понятно как будут подсчитываться gc roots, и какой overhead будет.
Стандарт как обычно скажет implementation-defined.

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

>> Ок. Опционально потенциальная утечка памяти
C>Согласен.
Смотрим по ссылке выше и видим — утечки по умолчанию нет
Еще не нравится в proposalе, что new T — может быть как garbage collected pointer, так и нет, также есть new(nogc) T, но нет new(gc) T. И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про malloc. И то, что finalizable надо регистрировать.

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

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

C>Я как-то прикидывал ради интереса что нужно добавить в С++ для поддержки
C>точной сборки — получалось не сильно много всего.
Для точной по-моему лучше чем как в C++/CLI не сделать... Т.е. ^ % pinning gcnew ref и.т.д.
Может от ref получиться отказаться.

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

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

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

Pavel Chikulaev wrote:
> Давай перейдем к фактам:
> Proposal: Transparent Garbage Collection for C++ (N1833)
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1833.pdf&gt;.
Transparent — это теперь новое название консервативного GC

В статье, кстати, есть тонкие моменты. Например, это выражение неверно:

There are no correctness restrictions on, for example, the life-time
of C++ references to garbage-collected memory.

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

> Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
> наверно).
Не впечатляет, честно говоря.

> Все-таки мне не очень понятно как будут подсчитываться gc roots, и какой
> overhead будет.
С этим все достаточно просто — сканируется стек, регистры, куча и
статические данные. Overhead можно посмотреть по Boehm GC — это
фактически уже близкая к идеальной реализация консервативного сборщика.

> И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
> (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
> malloc. И то, что finalizable надо регистрировать.
Это явно поправят.

> C>Я как-то прикидывал ради интереса что нужно добавить в С++ для поддержки
> C>точной сборки — получалось не сильно много всего.
> Для точной по-моему лучше чем как в C++/CLI не сделать... Т.е. ^ %
> pinning gcnew ref и.т.д.
Крыжечки и процентики не нужны — они заменяются специальными типами
умных указателей (как и pinning). При разыменовании указателя должна
возвращаться "умная ссылка"

> Может от ref получиться отказаться.
Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
"mapped", означающего, что для класса генерируется информация для GC (и
runtime-reflection'а).

Типа так:

mapped class SomeClazz
{
    gc_ptr<SomeClazz> next;
    weak_ptr<SomeClazz> some;
    phantom_ptr<SomeClazz> phantom;
    
    const char *str;
    std::vector<Something*> will_not_be_scanned;
};

Финализаторы вполне логично добавляются так:

mapped class SomeClazz : public virtual finalizable
{
...
};

Где finalizable задается примерно так:

class finalizable
{
    virtual void finalize(){delete this;};
};

Соответственно, код вызова финализации в GC можно представить так:

auto finish_him=dynamic_cast<gc_ptr<finalizable>>(obj);
if (finish_him) finish_him->finalize();

(в реальной жизни оптимизируется еще во время компиляции). При этом
сохраняется нормальная семантика деструкторов С++.

> C>У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".
> Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
> Впрочем это наверно от моего непонимания GC
Деструкторы в принципе не живут вместе с GC.

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

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

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

completion ports есть не на всех платформах т.е. generic
implementation должна включать потоки и синхронизационные
примитивы в generic исполнении для всех платформ.
Более того — потоки то есть не везде.

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

В общем случае нельзя.
"C++ VM" не включает в себя синхронизационные атомарные примитивы и потоки.
Соответсвенно только средствами C++ как платформы это решить нельзя.
И это хорошо.

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

Ага, ну значит никогда ибо сначала оно должно пройти в
boost, потом в tr2 а потом уже в финал. Не в этой жизни, короче.

c-smile wrote:
> C>Уверены? Посмотрите паттерн Proactor —
> C>http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf
> C>Он поддерживает многотредовость, но не требует ее.
> completion ports есть не на всех платформах
На остальных (реально имеющих значение) есть /dev/poll, kpoll и т.п.

> implementation должна включать потоки и синхронизационные
> примитивы в generic исполнении для всех платформ.
> Более того — потоки то есть не везде.
А там где нет — просто и не делать AIO.

> http://asio.sourceforge.net/boost-asio-proposal-0.3.6/boost/asio/detail/mutex.hpp
> C>То что там есть поддержка тредов — не значит, что без них работать нельзя.
> В общем случае нельзя.
> "C++ VM" не включает в себя синхронизационные атомарные примитивы и потоки.
Скоро будет. В виде стандартной библиотеки и немного более тщательнее
определенной модели памяти.

>> > C>Boost.Threads тоже пойдет в TR2.
>> > А дальше чего будет?
> C>После TR2 будет обсуждение и включение в Стандарт.
> Ага, ну значит никогда ибо сначала оно должно пройти в
> boost, потом в tr2 а потом уже в финал. Не в этой жизни, короче.
В Boost'е оно уже есть (сейчас последняя неделя review), в TR2 тоже явно
будет (в комитете понимают, что сетевая библиотека очень нужна).

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

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

C>Transparent — это теперь новое название консервативного GC
Partially conservative

>> Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>> наверно).
C>Не впечатляет, честно говоря.
Что именно не нравиться?

>> И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
>> (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
>> malloc. И то, что finalizable надо регистрировать.
C>Это явно поправят.
Что регистрировать надо или то, что меня не устраивает?

C>Крыжечки и процентики не нужны — они заменяются специальными типами
C>умных указателей (как и pinning). При разыменовании указателя должна
C>возвращаться "умная ссылка"
Еще один повод разрешить переопределять operator .

>> Может от ref получиться отказаться.
C>Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
C>"mapped", означающего, что для класса генерируется информация для GC (и
C>runtime-reflection'а).
Пусть native-speakers выбирут лучшее название

C>Финализаторы вполне логично добавляются так:
C>

C>mapped class SomeClazz : public virtual finalizable
C>{
C>...
C>};
C>

Лучше автоматически, а-ля ~T из С++/CLI.

>> C>У меня такое подозрение, что GC в С++ ждет судьба фичи "export template".
>> Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
>> Впрочем это наверно от моего непонимания GC
C>Деструкторы в принципе не живут вместе с GC.
Знаю Можно было бы автоматически генерировать finalize, убрав delete объектов,
и вызов деструкторов базовых классов и членов.

Pavel Chikulaev wrote:
> C>Transparent — это теперь новое название консервативного GC
> Partially conservative
Это примерно как "немного беременна"

>> > Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>> > наверно).
> C>Не впечатляет, честно говоря.
> Что именно не нравиться?
Не вижу смысла в этом.

>> > И то, что нет pragmы для такого поведения — по-умолчанию gc не нужен
>> > (new T), но когда явно напишу new(gc) T он сработает. Тоже самое про
>> > malloc. И то, что finalizable надо регистрировать.
> C>Это явно поправят.
> Что регистрировать надо или то, что меня не устраивает?
Семантику вызовов new.

> C>Крыжечки и процентики не нужны — они заменяются специальными типами
> C>умных указателей (как и pinning). При разыменовании указателя должна
> C>возвращаться "умная ссылка"
> Еще один повод разрешить переопределять operator .
Давно пора бы.

> C>Нет, ее лучше оставить. Хотя я бы предпочел что-нибудь типа атрибута
> C>"mapped", означающего, что для класса генерируется информация для GC (и
> C>runtime-reflection'а).
> Пусть native-speakers выбирут лучшее название
Согласен, хотя это непринципиально.

> C>mapped class SomeClazz : public virtual finalizable
> C>{
> C>...
> C>};
> C>
> Лучше автоматически, а-ля ~T из С++/CLI.
Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
оператором new или создан на стеке, при этом семантика деструкторов
остается та же. А вот финализация будет использоваться только совместно
с GC.

Более того, в моем дизайне для работы STL с GC фактически надо всего
лишь убрать из Стандарта пункт 20.1.5.4:

— The typedef members pointer, const_pointer, size_type, and
difference_type are required to be T*,T const*, size_t, and ptrdiff_t,
respectively.

Точнее, этот пункт надо изменить, чтобы можно было использовать умные
указатели.

>> > Сложно сказать. Плохо лишь то, что деструкторы вызываться не будут.
>> > Впрочем это наверно от моего непонимания GC
> C>Деструкторы в принципе не живут вместе с GC.
> Знаю Можно было бы автоматически генерировать finalize, убрав delete
> объектов, и вызов деструкторов базовых классов и членов.
Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.

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

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

?>> > Так скорее всего и будет в C++0x (с некоторыми незначительными измениями
>>> > наверно).
>> C>Не впечатляет, честно говоря.
>> Что именно не нравиться?
C>Не вижу смысла в этом.
Ну ты недавно лишь говорил, что GC иногда нужен...


>> C>Крыжечки и процентики не нужны — они заменяются специальными типами
>> C>умных указателей (как и pinning). При разыменовании указателя должна
>> C>возвращаться "умная ссылка"
>> Еще один повод разрешить переопределять operator .
C>Давно пора бы.
Эх. Ну почему его нет в C++98 (

>> C>mapped class SomeClazz : public virtual finalizable
>> C>{
>> C>...
>> C>};
>> C>
>> Лучше автоматически, а-ля ~T из С++/CLI.
C>Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
C>оператором new или создан на стеке, при этом семантика деструкторов
C>остается та же. А вот финализация будет использоваться только совместно
C>с GC.
Тоже самое. Если создание с помощью new — не использовать ~T,
с помощью new(gc) или лучше gcnew — тогда использовать ~T.

C>Более того, в моем дизайне для работы STL с GC фактически надо всего
C>лишь убрать из Стандарта пункт 20.1.5.4:
C>

C>— The typedef members pointer, const_pointer, size_type, and
C>difference_type are required to be T*,T const*, size_t, and ptrdiff_t,
C>respectively.

C>Точнее, этот пункт надо изменить, чтобы можно было использовать умные
C>указатели.
+1

>> C>Деструкторы в принципе не живут вместе с GC.
>> Знаю Можно было бы автоматически генерировать finalize, убрав delete
>> объектов, и вызов деструкторов базовых классов и членов.
C>Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
C>твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.
Помню
Лучше бы динамический тип менялся, хотя бы в C++0x...
Буду ломиться в comp.lang.c++.std, чтобы после вызова finalize,
перед вызовом finalize базового класса, сменить тип.
Хотя вряд-ли получится — finalize обычная виртуальная функция.

Pavel Chikulaev wrote:
>> > C>Не впечатляет, честно говоря.
>> > Что именно не нравиться?
> C>Не вижу смысла в этом.
> Ну ты недавно лишь говорил, что GC иногда нужен...
Нужен. Но вот консервативный GC не особо хочется — лучше уж как в GCC
или Boost.xpressive написать свой GC для частного случая.

>> > Еще один повод разрешить переопределять operator .
> C>Давно пора бы.
> Эх. Ну почему его нет в C++98 (
Пиши proposal

> C>Нет уж. В моем дизайне mapped-класс может быть распределен обычным не-gc
> C>оператором new или создан на стеке, при этом семантика деструкторов
> C>остается та же. А вот финализация будет использоваться только совместно
> C>с GC.
> Тоже самое. Если создание с помощью new — не использовать ~T,
> с помощью new(gc) или лучше gcnew — тогда использовать ~T.
Я пытался придумать дизайн, требующий минимальных изменений и не очень
неинтуитивный.

> C>Тоже не надо. Финализатор — это все же совсем другая сущность (вспомним
> C>твой пример с C++/CLI), так что лучше его не смешивать с деструкторами.
> Помню
> Лучше бы динамический тип менялся, хотя бы в C++0x...
> Буду ломиться в comp.lang.c++.std, чтобы после вызова finalize,
> перед вызовом finalize базового класса, сменить тип.
Просто тут мы дублируем механизм деструкторов. А нам такое не нужно

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