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

A>В коммитете много толковых людей. Посмотри предложения, которые коммитет обсуждает.

Обсуждать можно и на форуме RSDN. А вот решения принимать... это же надо ответственность на себя брать. А это многим слабо.

IT wrote:
> Здравствуйте, alexeiz, Вы писали:
>
>> В коммитете много толковых людей. Посмотри предложения, которые
>> коммитет обсуждает.
>
> Обсуждать можно и на форуме RSDN. А вот решения принимать... это же
> надо ответственность на себя брать. А это многим слабо.

Обсуждения на rsdn часто имеют форму флэйма.

Ты думаешь, ты "предложишь", а кто-то за тебя решение примет? Нет, друг.
Хочешь чего-то в C++, сам и проталкивай. На таких людях, кто хочет и может
проталкивать предложения, и держится C++. Внести что-либо в стандарт C++ —
это реальная работа. А тем, кому только пофлэймить нужно, им и флэймовского
форума достаточно.

Denis2005 wrote:
> Здравствуйте, alexeiz, Вы писали:
>
>> RTTI не имеет нормального решения на уровне библиотеки.
>
> Согласен!
>
>> Delegates имеют.
>
> Несогласен. Только примитивные реализации, которыми собственно
> честной народ и занимается с очень давних пор.

Ты еще многого не знаешь.

> Делегат это не просто указатель на объект + указатель на метод
> (кстати, Влад где-то об этом много говорил).

Нашел кого слушать. Всё, что Влад говорил, это частное мнение одного
человека, далёкого от C++ к тому-же.

>
>> В этом и заключается разница. Основной принцип комитета по
>> стандартизации заключается в том, чтобы включать в язык то, что
>> действительно там необходимо.
>
> Так ли мне необходимо в языке ключевое слово mutable?
>
>>> Причем более менее "человечную" реализацию
>>> (http://www.rsdn.ru/article/cpp/delegates.xml

Автор(ы): Александр Шаргин
Дата: 19.03.2003
Делегаты в CLR удобны, типобезопасны и эффективны. Последнее время на форумах RSDN часто поднимается вопрос о том, можно ли реализовать делегаты с аналогичными свойствами, оставаясь в рамках "чистого" C++. Оказывается, это вполне возможно. В этой статье я покажу, как это сделать.

) удалось осуществить
>>> лишь с появлением продвинутых компиляторов.
>
>> Я бы не назвал это человечной реализацией. Также спорно
>> утверждение, что VC++7.0 — это продвинутый компилятор.
>
> Чем неустраивает?

Много чем.

> Ну если на то пошло, то вообще я предпочитаю Comeau и GCC, а прямых
> утверждений насчет "VC++7.0 — это продвинутый компилятор" с моей
> стороны небыло.

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

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

libsigc++ существовал испокон веков. Если ты черпаешь знания только из
этого форума, то тогда понятно, почему ты приходишь к таким выводам.

>
>>> P.S. На мой взгляд "Страуструп и Ко" далеко не всегда правы в своих
>>> рассуждениях, а сообщество приверженцев C++ просто напросто
>>> закрывает глаза на их просчеты, и всячески пытается доказать, что
>>> так и должно быть.
>
>> Не нужно делать из Страуструпа диктатора в мире C++. Стандарт
>> разрабатывает комитет по стандартизации. Страуструп всего лишь один
>> из его членов. В коммитете много толковых людей. Посмотри
>> предложения, которые коммитет обсуждает. Страуструп является
>> соавтором разве что нескольких из них.
>
> Специально поясню, что под "Ко" имелся в виду комитет.

А кто такой этот коммитет? Это простые люди, как мы с тобой. Отличаются
они только тем, что желают потратить время и энергию на развитие C++.

PS. Я думал, ты хочешь получить честный ответ, почему того или иного нет в
C++. Из твоих реплик видно, что ты, оказывается, хочешь поспорить,
пофлэймить, значит. ...And flame thou shalt receive!

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

A>Ты думаешь, ты "предложишь", а кто-то за тебя решение примет? Нет, друг.
A>Хочешь чего-то в C++, сам и проталкивай. На таких людях, кто хочет и может
A>проталкивать предложения, и держится C++. Внести что-либо в стандарт C++ —
A>это реальная работа. А тем, кому только пофлэймить нужно, им и флэймовского
A>форума достаточно.

Это плохая отмазка. Естественно я не буду ничего никуда проталкивать. Хотя бы просто потому что понимаю бессмысленность этого занятия.
Судя по "количеству" фич, появившихся в C++ за последнее время — это вообще никому не удалось.

IT wrote:
> Здравствуйте, alexeiz, Вы писали:
>
>> Ты думаешь, ты "предложишь", а кто-то за тебя решение примет? Нет,
>> друг. Хочешь чего-то в C++, сам и проталкивай. На таких людях, кто
>> хочет и может проталкивать предложения, и держится C++. Внести
>> что-либо в стандарт C++ — это реальная работа. А тем, кому только
>> пофлэймить нужно, им и флэймовского форума достаточно.
>
> Это плохая отмазка. Естественно я не буду ничего никуда проталкивать.
> Хотя бы просто потому что понимаю бессмысленность этого занятия. Судя
> по "количеству" фич, появившихся в C++ за последнее время — это
> вообще никому не удалось.

Это не отмазка. Это — how things work. "Предложить" каждый может.
"понимаю бессмысленность этого занятия" — вот это настоящая отмазка.

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

A>Это не отмазка. Это — how things work. "Предложить" каждый может.
A>"понимаю бессмысленность этого занятия" — вот это настоящая отмазка.

Ты лично предлагал?

IT wrote:
> Здравствуйте, alexeiz, Вы писали:
>
>> Это не отмазка. Это — how things work. "Предложить" каждый может.
>> "понимаю бессмысленность этого занятия" — вот это настоящая отмазка.
>
> Ты лично предлагал?

Это что, попытка шапками забросать? До сих пор именно ты здесь являешься
тем, кто плачется, о том как это бессмысленно.

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

>> Ты лично предлагал?

A>Это что, попытка шапками забросать? До сих пор именно ты здесь являешься тем, кто плачется, о том как это бессмысленно.

Это попытка вывести демагога на чистую воду. Видишь как ты быстро сдался?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>например, попробуй-ка модифицировать контейнер, по которому "идешь" с помощью foreach)...

Невозможность модификации контейнера это не ограничение foreach, а ограничение итераторов стандартных контейнеров.

IT wrote:
> Здравствуйте, alexeiz, Вы писали:
>
>>> Ты лично предлагал?
>
>> Это что, попытка шапками забросать? До сих пор именно ты здесь
>> являешься тем, кто плачется, о том как это бессмысленно.
>
> Это попытка вывести демагога на чистую воду. Видишь как ты быстро
> сдался?

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

AndrewVK,

> ПК> например, попробуй-ка модифицировать контейнер, по которому "идешь" с помощью foreach)...
>
> Невозможность модификации контейнера это не ограничение foreach, а ограничение итераторов стандартных контейнеров.

Ну и что? Речь шла о том, что foreach подходит не везде. Это был один из примеров. Собственно, суть сводится к тому, что алгоритмов, связанных с обходом контейнера много, и foreach — один из них, далеко не всегда наиболее подходящий. Остальные алгоритмы столь же удобно использовать не представляется возможным.

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

>> Делегат это не просто указатель на объект + указатель на метод
>> (кстати, Влад где-то об этом много говорил).

A>Нашел кого слушать. Всё, что Влад говорил, это частное мнение одного
A>человека, далёкого от C++ к тому-же.

Он меня со спецификацией спутал.

Здравствуйте, Павел Кузнецов, Вы писали:

>> Невозможность модификации контейнера это не ограничение foreach, а ограничение итераторов стандартных контейнеров.

ПК>Ну и что? Речь шла о том, что foreach подходит не везде. Это был один из примеров. Собственно, суть сводится к тому, что алгоритмов, связанных с обходом контейнера много, и foreach — один из них, далеко не всегда наиболее подходящий.

Следи за губами — foreach это не алгоритм. Алгоритм находится внутри итератора. При наличии итератора, котjрый умеет определенным образом обрабатывать удаления? удалять внутри foreach можно.

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

AVK>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>например, попробуй-ка модифицировать контейнер, по которому "идешь" с помощью foreach)...

AVK>Невозможность модификации контейнера это не ограничение foreach, а ограничение итераторов стандартных контейнеров.

Сделали же итераторы с чеовечексим лицом и для форыча
http://www.gotdotnet.com/community/usersamples/details.aspx?sampleguid=44999d9f-4713-4516-a5e9-60d680b86f0f

Здравствуйте, Юнусов Булат, Вы писали:

ЮБ>Здравствуйте, AndrewVK, Вы писали:

AVK>>Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>>например, попробуй-ка модифицировать контейнер, по которому "идешь" с помощью foreach)...

AVK>>Невозможность модификации контейнера это не ограничение foreach, а ограничение итераторов стандартных контейнеров.

ЮБ>Сделали же итераторы с чеовечексим лицом и для форыча
ЮБ>http://www.gotdotnet.com/community/usersamples/details.aspx?sampleguid=44999d9f-4713-4516-a5e9-60d680b86f0f

Какая-то не серьёзная подела. Я бы её в своём проекте использовать не стал.

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

A>Ты еще многого не знаешь.

Можно привести ход мыслей приводящий в конечном счете к такому выводу?

>>> В этом и заключается разница. Основной принцип комитета по
>>> стандартизации заключается в том, чтобы включать в язык то, что
>>> действительно там необходимо.
>>
>> Так ли мне необходимо в языке ключевое слово mutable?

Внятных ответов пока небыло...
К вопросу добавляем необходимость ключевого слова volatile.

>>> Я бы не назвал это человечной реализацией. Также спорно
>>> утверждение, что VC++7.0 — это продвинутый компилятор.
>>
>> Чем неустраивает?

A>Много чем.

Благодарю за полный и исчерпывающий ответ.

A>libsigc++ существовал испокон веков. Если ты черпаешь знания только из
A>этого форума, то тогда понятно, почему ты приходишь к таким выводам.

По подробней... испокон веков — это XX век?
Често признаюсь, что этот компилятор в руках не держал, но я его даже не нахожу в этом списке:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/bind_.html.
Черпаю знания в основном из личного опыта, но не буду лукавить, кое-чего подчеркул из этого форума.

A>PS. Я думал, ты хочешь получить честный ответ, почему того или иного нет в
A>C++. Из твоих реплик видно, что ты, оказывается, хочешь поспорить,
A>пофлэймить, значит. ...And flame thou shalt receive!

Чего я не получил, так это не одного т.с. честного ответа из ваших сообщений.

Denis2005,

>>> Так ли мне необходимо в языке ключевое слово mutable?
D>Внятных ответов пока небыло...

Некоторые классы нужно реализовать так, чтобы их объекты хранили счётчики обращений или ссылок к себе. Объекты могут быть константными и неконстантными, а счётчик должен меняться всегда. Вот здесь и mutable.

D>К вопросу добавляем необходимость ключевого слова volatile.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК> Я, например, последнее время "болею" идеей, как бы можно было бы ввести в язык такую "фичу", чтоб прямо в терминах языка можно было бы for и while прозрачно выразить, оставив в языке только if и goto. Это, собственно, не для for и while нужно, а для того, чтоб алгоритмы, подобные тому, что в STL, были бы в языке first class citizens. А в C#, напротив, foreach в язык "воткнули". Вот такая вот разница.

Хе-хе . Если "язык" — это С++, то все довольно просто. Поехали:
1) Разрешаем в языке т.н. замыкания. Это подразумевает возможность определения функций внутри функций — в локальном контексте, причем из внутренней функции видны переменные, которые определены во внешней.
2) Разрешаем лямда-выражения. Таким образом, что в частности любые операторные скобочки {} определяют безымянную функцию вида void(), а параметры туда будут передаваться неявно, связываясь с локальным контекстом (см пункт 1).
3) Теперь, разрешаем отделять аргументы функций точкой с запятой. Тип такого выражения — функция, употребление {} необходимо только чтобы разрешать противоречия (см пункт 2). Если скобки {} опущены, то тело функции состоит из одного выражения до первой ";".
4) Самое сложное. Надо добавить возможность функции брать в качестве аргумента выражение (функцию) после скобок. Так, чтобы была возможность определить for, например, таким образом.

void for( void i_init(); void i_cond(); void i_iterate() ) arg( void i_body() )
{


}

5) Золотой ключик у нас почти в кармане. Осталось добавить возможность определить if. Он у нас будет полиморфный.

void if( bool i_cond() ) arg( void i_then() ) else arg( void i_else() )
{
}

void if( bool i_cond() ) arg( void i_then() )
{
}

Собственно, все. Не желаете сделать препроцессор?

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

G>2) Разрешаем лямда-выражения. Таким образом, что в частности любые операторные скобочки {} определяют безымянную функцию вида void(), а параметры туда будут передаваться неявно, связываясь с локальным контекстом (см пункт 1).

Багу нашел. Для фигурных скобок есть исключение. Если функция void(), которая определяется посредством {}, не является аргументом другой функции, то она инлайнится в то место, где она определена.

Вот теперь все в порядке, работать будет. Надеюсь, что эти расширения, придуманные сейчас мной, или что-то подобное никогда не станет частью языка С++, программирование на которм уже сейчас напоминает игру в драконий покер из книг Асприна.

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

G>

G>void for( void i_init(); void i_cond(); void i_iterate() ) arg( void i_body() )
G>{

G>}
G>

В нашу спецификацию закрался еще один баг. Проблемы с областью видимости. Вводим правило, что из определений функций-аргументов после скобок должен быть виден локальный контекст функций-аргументов, перечисленых внутри скобок. Чтобы контроллировать область видимости, вводим модификатор open. Таким образом, для цикла for это будет выглядеть так:

void for( open void i_init(); void i_cond(); void i_iterate() ) arg( void i_body() )
{

}

Страшно?